Consistent set of interfaces derived from a business object model

ABSTRACT

A business object model, which reflects data that used during a given business transaction, is utilized to generate interfaces This business object model facilitates commercial transactions by providing consistent interfaces that are suitable for use across industries, across businesses, and across different departments within a business during a business transaction.

I. CROSS-REFERENCE TO RELATED APPLICATIONS

The following identified U.S. patent applications are relied upon andare incorporated herein by reference in this application in theirentirety:

U.S. Patent Application No. 60/577,453, entitled “Interfaces Derivedfrom a Business Object Model Shared by the Heterogeneous Applications,”filed on Jun. 4, 2004.

U.S. Patent Application No. 60/581,252, entitled “Interfaces Derivedfrom a Business Object Model Shared by Heterogeneous Applications,”filed on Jun. 18, 2004.

U.S. Patent Application No. 60/582,949, entitled “Interfaces Derivedfrom a Business Object Model Shared by Heterogeneous Applications,”filed on Jun. 25, 2004.

U.S. Patent Application No. 60/656,598, entitled “Interfaces Derivedfrom a Business Object Model Shared by Heterogeneous Applications,”filed on Feb. 25, 2005.

U.S. patent application Ser. No. 11/145,464, entitled “Consistent Set OfInterfaces Derived From A Business Object Model,” filed on Jun. 3, 2005.

PCT Patent Application No. PCT/US05/19961, entitled “Consistent Set OfInterfaces Derived From A Business Object Model,” filed on Jun. 3, 2005.

U.S. patent application Ser. No. 11/155,368, entitled “Consistent Set OfInterfaces Derived From A Business Object Model,” filed on Jun. 17,2005.

PCT Patent Application No. PCT/US05/021481, entitled “Consistent Set OfInterfaces Derived From A Business Object Model,” filed on Jun. 17,2005.

U.S. patent application Ser. No. 11/166,065, entitled “Consistent Set OfInterfaces Derived From A Business Object Model,” filed on Jun. 24,2005.

PCT Patent Application No. PCT/US05/22137, entitled “Consistent Set OfInterfaces Derived From A Business Object Model,” filed on Jun. 24,2005.

U.S. Patent Application No. 60/729,480, entitled “Consistent Set OfInterfaces Derived From A Business Object Model,” filed on Oct. 21,2005.

PCT Patent Application No. PCT/US06/______, entitled “Consistent Set OfInterfaces Derived From A Business Object Model,” filed on Feb. 27,2006.

II. FIELD

The subject matter described herein relates generally to the generationand use of consistent interfaces derived from a business object model.More particularly, the subject matter described herein relates to thegeneration and use of consistent interfaces that are suitable for useacross industries, across businesses, and across different departmentswithin a business.

III. BACKGROUND

Transactions are common among businesses and between businessdepartments within a particular business. During any given transaction,these business entities exchange information. For example, during asales transaction, numerous business entities may be involved, such as asales entity that sells merchandise to a customer, a financialinstitution that handles the financial transaction, and a warehouse thatsends the merchandise to the customer. The end-to-end businesstransaction may require a significant amount of information to beexchanged between the various business entities involved. For example,the customer may send a request for the merchandise as well as some formof payment authorization for the merchandise to the sales entity, andthe sales entity may send the financial institution a request for atransfer of funds from the customer's account to the sales entity'saccount.

Exchanging information between different business entities is not asimple task. This is particularly true because the information used bydifferent business entities is usually tightly tied to the businessentity itself. Each business entity may have its own program forhandling its part of the transaction. These programs differ from eachother because they typically are created for different purposes andbecause each business entity may use semantics that differ from theother business entities. For example, one program may relate toaccounting, another program may relate to manufacturing, and a thirdprogram may relate to inventory control. Similarly, one program mayidentify merchandise using the name of the product while another programmay identify the same merchandise using its model number. Further, onebusiness entity may use U.S. dollars to represent its currency whileanother business entity may use Japanese Yen. A simple difference informatting, e.g., the use of upper-case lettering rather than lower-caseor title-case, makes the exchange of information between businesses adifficult task. Unless the individual businesses agree upon particularsemantics, human interaction typically is required to facilitatetransactions between these businesses. Because these “heterogeneous”programs are used by different companies or by different business areaswithin a given company, a need exists for a consistent way to exchangeinformation and perform a business transaction between the differentbusiness entities.

The United Nations established the United Nations Centre for TradeFacilitation and Electronic Business (“UN/CEFACT”) to improve worldwidecoordination for the exchange of information. The primary focus ofUN/CEFACT is to facilitate national and international transactions bysimplifying and harmonizing processes, procedures and information flowto contribute to the growth of global commerce. UN/CEFACT is still inits early stages of developing such a harmonized system. Additionalinformation regarding UN/CEFACT can be found at www.unece.org/cefact/.

Currently many standards exist, which offer a variety of interfaces usedto exchange business information. Most of these interfaces, however,apply to only one specific industry, and are not consistent between thedifferent standards. Moreover, a number of these interfaces are notconsistent within an individual standard. Thus, there is a need for theharmonization of interfaces across these standards and across variousindustries.

IV. SUMMARY

Methods and systems consistent with the subject matter described hereinfacilitate e-commerce by providing consistent interfaces that can beused during a business transaction. Such business entities may includedifferent companies within different industries. For example, onecompany may be in the chemical industry, while another company may be inthe automotive industry. The business entities also may includedifferent businesses within a given industry, or they may includedifferent departments within a given company.

The interfaces are consistent across different industries and acrossdifferent business units because they are generated using a singlebusiness object model. The business object model defines thebusiness-related concepts at a central location for a number of businesstransactions. In other words, the business object model reflects thedecisions made about modeling the business entities of the real worldacting in business transactions across industries and business areas.The business object model is defined by the business objects and theirrelationships to each other (overall net structure).

A business object is a capsule with an internal hierarchical structure,behavior offered by its operations, and integrity constraints. Businessobjects are semantically disjoint, i.e., the same business informationis represented once. The business object model contains all of theelements in the messages, user interfaces and engines for these businesstransactions. Each message represents a business document withstructured information. The user interfaces represent the informationthat the users deal with, such as analytics, reporting, maintaining orcontrolling. The engines provide services concerning a specific topic,such as pricing or tax.

Methods and systems consistent with the subject matter described hereingenerate interfaces from the business object model by assembling theelements that are required for a given transaction in a correspondinghierarchical manner. Because each interface is derived from the businessobject model, the interface is consistent with the business object modeland with the other interfaces that are derived from the business objectmodel. Moreover, the consistency of the interfaces is also maintained atall hierarchical levels. By using consistent interfaces, each businessentity can easily exchange information with another business entitywithout the need for human interaction, thus facilitating businesstransactions.

Methods and systems consistent with the subject matter described hereinprovide a consistent set of interfaces that are suitable for use withmore than one industry. This consistency is reflected at a structurallevel as well as through the semantic meaning of the elements in theinterfaces.

Methods and systems consistent with the subject matter described hereinprovide an object model and, from this object model, derive two or moreinterfaces that are consistent.

Methods and systems consistent with the subject matter described hereinprovide a consistent set of interfaces suitable for use with a businessscenario that spans across the components within a company. Thesecomponents, or business entities, may be heterogeneous.

Additionally, methods and systems consistent with the subject matterdescribed herein provide a consistent set of interfaces suitable for usewith different businesses.

An electronic message to request cancellation of an accounting can begenerated by a first application that executes in a landscape ofcomputer systems providing message-based services. Transmission of themessage to a second application can be initiated in order to requestcancellation of the accounting. Responding to a request to cancel anaccounting can include receiving a message including an accountingcancellation package and initiating cancellation of an accounting ofposting information. An accounting cancellation package can contain anaccounting cancellation entity and a business transaction documentreference package, where the accounting cancellation entity identifies afirst document that characterizes cancellation of an accounting andidentifies a type of a second document characterizing postinginformation previously sent and to be canceled, and the businesstransaction document reference package contains a reference entityidentifying the second document.

In some variations, the posting information can include postinginformation previously sent for an invoice or credit memo, and therequest for cancellation of an accounting can include a request forcancellation of an accounting of an invoice. The posting information caninclude posting information previously sent with respect to a movementof goods, and the request for cancellation of an accounting can includea request for cancellation of an accounting of a movement of goods. Theaccounting cancellation package can further contain a note entitycharacterizing a reason for the cancellation, and a date entitycharacterizing a date on which the cancellation is to be entered.

An electronic message to request a bank account statement can begenerated by a first application that executes in a landscape ofcomputer systems providing message-based services. Transmission of themessage to a second application can be initiated in order to request thebank account statement.

The generated message can include a bank account statement packagecontaining a bank account statement entity characterizing a statement ofa bank regarding turnovers on a customer bank account. The bank accountstatement package can also contains a bank account package containinginformation characterizing a bank account. The bank account statementpackage further contains a bank account statement item packagecontaining an item entity characterizing a single turnover on a bankaccount. The bank account statement item package also contains a paymentexplanation package containing information characterizing payments in abank account statement. The payment explanation package contains apayment difference explanation package containing informationcharacterizing documents relating to payments in a bank accountstatement.

The bank account statement package can further contain a party packagecontaining a payment transaction initiator party entity characterizing aparty that initiated a payment. The party package can also contain apayment transaction destination party entity characterizing a party thatreceives payment in case of a bank transfer or whose account is debitedin case of a direct debit. The party package can also contain anoriginal payment transaction initiator party entity characterizing aparty executing a payment transaction. The party package can alsocontain a final payment transaction destination party entitycharacterizing a party to receive a payment or to be debited. The bankaccount statement package can also include a bank account statement bankaccount package containing a payment transaction initiator bank accountentity characterizing a bank account of a party initiating a paymenttransaction. The bank account statement bank account package can alsocontain a payment transaction destination bank account characterizing abank account of a party receiving a payment or to be debited. The bankaccount statement package can also include a business transactiondocument reference package containing a payment reference entitycharacterizing a document from a payment transaction initiator. Thebusiness transaction document reference package can also include apayment order reference entity characterizing a payment order by apayment transaction initiator. The business transaction documentreference package can also include a business transaction documentreference package. The business transaction document reference packagecan further contain a bill of exchange reference entity characterizing abill of exchange number.

The payment explanation package can further contain a paymentexplanation item characterizing a payment amount. The paymentexplanation package can also contain a payment explanation party packagecontaining an original payment transaction initiator party entitycharacterizing an original party on behalf of which a paymenttransaction is executed. The payment explanation party package can alsocontain a final payment transaction destination party characterizing aparty on behalf of which a payment is received or debited. The paymentexplanation package can also contain a business document objectreference package containing a payment explanation payment transactioninitiator invoice reference entity characterizing an invoice of atransaction initiator. The business document object reference packagecan also contain a payment explanation payment transaction destinationinvoice reference entity characterizing an invoice of a party receivinga payment or being debited. The business document object referencepackage can also contain a payment explanation payment transactioninitiator contract reference entity characterizing a contract of atransaction initiator. The business document object reference packagecan also contain a payment explanation payment transaction destinationcontract reference entity characterizing a contract of a party receivinga payment or being debited. The business document object referencepackage can also contain a payment explanation payment transactioninitiator purchase order reference entity characterizing a purchaseorder of a transaction initiator. The business document object referencepackage can also contain a payment explanation payment transactiondestination purchase order reference entity characterizing a referenceto a purchase order of a party receiving a payment or being debited.

The payment difference explanation package can contain a paymentdifference explanation item entity characterizing differences betweenexpected and actual payment amounts. The payment difference explanationpackage can also contain a business document object reference packagecontaining a payment difference explanation payment transactioninitiator invoice reference entity characterizing an invoice of atransaction initiator. The business document object reference packagecan also contain a payment difference explanation payment transactiondestination invoice reference entity characterizing an invoice of aparty receiving a payment or being debited. The business document objectreference package can also contain a payment difference explanationpayment transaction initiator contract reference entity characterizing acontract of a transaction initiator. The business document objectreference package can also contain a payment difference explanationpayment transaction destination contract reference entity characterizinga contract of a party receiving a payment or being debited. The businessdocument object reference package can also contain a payment differenceexplanation payment transaction initiator purchase order referenceentity characterizing a purchase order of a transaction initiator. Thebusiness document object reference package can further contain a paymentdifference explanation payment transaction destination purchase orderreference entity characterizing a reference to a purchase order of aparty receiving a payment or being debited.

Generating a request for a bank account statement can be accomplished byreceiving an electronic message in a landscape of computer systemsproviding message-based services and initiating generation of a requestfor a bank account statement. The received message includes a bankaccount statement package containing a bank account statement entitycharacterizing a statement of a bank regarding turnovers on a customerbank account. The bank account statement package also includes a bankaccount package containing information characterizing a bank account.The bank account statement package further contains a bank accountstatement item package containing an item entity characterizing a singleturnover on a bank account. The bank account statement item package alsocontains a payment explanation package containing informationcharacterizing payments in a bank account statement. The paymentexplanation package also contains a payment difference explanationpackage containing information characterizing documents relating topayments in a bank account statement.

An electronic message to request bank account balances for a time periodfor a group of bank accounts can be generated by a first applicationthat executes in a landscape of computer systems. Transmission of themessage to a second application can be initiated in order to requestaccount balances for a time period for a group of bank accounts.Responding to a request for account balances for a time period for agroup of bank accounts can include receiving a message including a bankaccount balance report query package and initiating a request for bankaccount balances for a time period for a group of bank accounts. Thebank account balance report query package can contain a bank accountbalance report query entity, a bank account package, and item package.The bank account balance report query entity characterizes a request forbalance information for a bank account. The bank account packagecharacterizes the bank account for which requests are to be made. Theitem package characterizes criteria that are relevant for determiningbank account balances. The bank account package can contain a bankaccount entity identifying the bank account for which balanceinformation is to be ascertained. The item package can contain a bankaccount balance report query item entity characterizing criteria fordetermining bank account balances. The bank account balance report queryitem entity can contain a bank account balance type code characterizinga type of a bank account balance and a date period entity identifying aperiod for which the bank account balances are to be taken intoconsideration. In some variations, the bank account package can furthercontain a bank account differentiator entity characterizing thedifference between accounts that are managed under one account number.In some variations, the bank account differentiator entity can contain abank account differentiator ID characterizing a unique identifier todifferentiate between bank accounts.

An electronic message to respond to a request for bank account balancesfor a time period for a group of bank accounts can be generated by afirst application that executes in a landscape of computer systems.Transmission of the message to a second application can be initiated inorder to receive account balances for a time period for a group of bankaccounts. Responding to a request for account balances for a time periodfor a group of bank accounts can include receiving a message including abank account balance report package and initiating a request for bankaccount balances for a time period for a group of bank accounts. Thebank account balance report package can contain a bank account balancereport entity containing information about balances of a bank account.

In some variations, the bank account balance report package can containa log package, a bank account package and a bank account balancepackage. The log package characterizes log messages that are issued whenbank account balances are determined and can contain a log entitycharacterizing a sequence of log messages issued by an application whileexecuting a task. The bank account package characterizes informationabout the bank account for which requests are made and can contain abank account entity characterizing the bank account to which balanceinformation belongs, and a bank account differentiator entitycharacterizing the difference between accounts that are managed underone account number. The bank account differentiator entity can contain abank account differentiator ID characterizing a unique identifier todifferentiate between bank accounts. The bank account balance packagecharacterizes bank account balances, and can contain a bank accountbalance entity containing bank account balances.

An electronic message to record business document data from a digitizedimage of the data can be generated by a first application that executesin a landscape of computer systems providing message-based services.Transmission of the message to a second application can be initiated inorder to record the digitized business document data either manually orautomatically. Responding to a request to record business document datafrom a digitized image of the data can include receiving a messageincluding a business transaction document image recognition package andinitiating recording of the digitized business document data eithermanually or automatically. A business transaction document imagerecognition package can contain a business transaction document imagerecognition request entity characterizing a request for a digitizedbusiness document to be recognized and an attachment package containingan attachment entity identifying the digitized business document.

In some variations, the digitized business document to be recognized caninclude an invoice, and the request to record business document datafrom an image can include a request for the manual entry of the invoicedata. The digitized business document to be recognized can include aninvoice, and the request to record business document data from an imagecan include a request for automatic entry of the invoice data with theuse of Optical Character Recognition (OCR) software.

An electronic message requesting to change, create, or delete items in acatalogue can be generated by a first application that executes in alandscape of computer systems providing message-based services.Transmission of the message to a second application can be initiated inorder to request to change, create, or delete items in a catalogue.Responding to the request to change, create, or delete items in acatalogue can include receiving a message including a cataloguepublication transmission package and initiating generation of aconfirmation to the request to change, create, or delete items in acatalog. A catalogue publication transmission package can contain acatalogue entity that characterizes a structured directory of catalogueitems.

In some variations, the catalogue publication transmission package canfurther contain a content package. The content package can contain acontent entity, catalogue item package, a catalogue view package, and atransmission information package. The content entity can characterize alist of items to be changed, created, or read. The catalogue itempackage can contain a catalogue item entity, a catalogue itemdescription entity, a catalogue classification entity, a propertyvaluation entity and a catalogue item relationship entity. The catalogueitem entity can characterize information about a catalogue item requiredto change, create, or delete it. The catalogue item description entitycan characterize an item in various locales. The catalogueclassification entity can characterize a classification of a catalogueitem. The property valuation entity can characterize a value of aproperty associated with a catalogue item. The catalogue itemrelationship entity can characterize a relationship between twocatalogue items. The catalogue view package can contain a catalogue viewentity and a catalogue view item entity. The catalogue view entity cancharacterize a restricted subset of a catalogue. The catalogue view itementity can characterize a catalogue item to be included in a catalogueview. The transmission information package containing informationcharacterizing a transmission of an object contained in the message.

An electronic message confirming receipt of a request to change, create,or delete items in a catalogue can be generated by a first applicationthat executes in a landscape of computer systems providing message-basedservices. Transmission of the message to a second application can beinitiated in order to confirm receipt of the request to change, create,or delete items in a catalogue. Responding to the confirmation requestcan include receiving a message including a catalogue publicationtransmission package and initiating generation of a confirmation thatthe request to change, create, or delete items in a catalog can beperformed. The catalogue publication transmission package can contain acatalogue publication transmission entity characterizing informationrequired to confirm whether items in a catalogue request can be changed,created, or deleted. The catalogue publication transmission package canalso contain a catalog package. The catalog package can contain acatalogue entity that can characterize a catalogue of items which can bechanged, created, or deleted.

An electronic message to request institutions to carry out one or morepayment transactions can be generated by a first application thatexecutes in a landscape of computer systems providing message-basedservices. Transmission of the message to a second application can beinitiated in order to request institutions to carry out on paymenttransactions. Responding to a request for instructions to carry out oneor more payment transactions can include receiving a message includingthe instructions to carry out one or more payment transactions, andinitiating an instruction to a payer's account to record the results ofpayment transactions.

The message can comprise a collective payment order package which inturn can include a collective payment order entity and a payment orderpackage. The collective payment order entity characterizes aninstruction to a credit institution to carry out one or more paymenttransactions. The payment order package contains a payment order entitycharacterizing one or more instructions to a credit institution to carryout a payment transaction, and a net amount entity identifying a paymentamount associated with the payment order entity.

In some variations, the instruction to a credit institution cancomprises a payment form code identifying a form of payment, and theinstruction to the payment transaction initiator's account to record theresult of the payment transaction can comprises the result of thepayment transaction based on a form of payment. The instruction to acredit institution can also comprise an account debit indicatoridentifying whether or not the payment transaction initiator's accountis to be debited, and the instruction to the payment transactioninitiator's account to record the result of the payment transaction cancomprises an indication as to whether or not the payment transactioninitiator's account was debited. The instruction to a credit institutioncan comprise a payment procedure code identifying one or more technicalcharacteristics of the payment transaction, and the instruction to thepayment transaction initiator's account to record the result of thepayment transaction can comprises the result of the payment transactionbased on a payment procedure code. The instruction to a creditinstitution can comprise a payment execution date identifying anexecution date for the payment transaction, and the instruction to thepayment transaction initiator's account to record the result of thepayment transaction can comprises a date of execution of the paymenttransaction.

The collective payment order package can include a party packagecontaining information characterizing information concerning partiesinvolved in the payment transaction, and a bank account packagecontaining information characterizing information concerning bankingdetails of a payment transaction initiator and a bank account to be usedby a bank for bank charges.

The party package can include a payment transaction initiator partyentity characterizing the party that initiated a payment. The bankaccount package can include a payment transaction initiator bank accountentity characterizing a bank account of the payment transactioninitiator, and a bank charges bank account entity characterizing a bankaccount to be debited with bank charges for a collective payment order.

The payment order package can include a party package containinginformation characterizing the party that placed the order and a bankaccount package containing information characterizing banking detailsfor the destination party of the payment transaction. It can alsoinclude a payment instruction package containing informationcharacterizing information for participating banks concerning a paymenttransaction execution, and a state central bank report packagecontaining information characterizing legal reporting information to acentral bank. The payment order package further can include informationto satisfy a legal reporting requirement for payments to foreign payees,and a business transaction document reference package containinginformation characterizing references to different documents involved inthe payment transaction, such as checks. It can also include a paymentexplanation package containing information characterizing an explanationfor a purpose, and an amount of a payment, which can include referencesto individual invoices or credit memos.

The party package can include a payment transaction destination partyentity characterizing the party that receives a payment or whose accountis debited, and an original payment transaction initiator party entitycharacterizing the party on whose behalf a payment order can be executedby the payment transaction initiator party entity. It can also include afinal payment transaction destination party entity characterizing theparty that can optionally receive a payment or be debited.

The bank account package can include a payment transaction destinationbank account entity characterizing a bank account of the party that thepayment transaction is destined.

The payment instruction package can include a payment instruction entitycharacterizing an instruction to an executing bank related to thepayment order, such as to send a bank advice to the payee, and acorrespondence bank details entity characterizing details from a bank ofa correspondence bank that should be used for forwarding the paymentorder. The correspondence bank details entity further can include acorrespondence bank type code characterizing a type of a correspondencebank, a bank code characterizing an address or identifier for thecorrespondence bank, and a bank account code characterizing acorrespondence bank account.

The state central bank report package can include a central bank reportitem entity characterizing information to satisfy legal reporting to acentral bank and a requirement for payments to foreign payees.

The business transaction document reference package can include apayment reference entity characterizing a reference to a payer's paymentdocument representing an actual payment that includes at least thepayment procedure, the payment currency, the payment amount, the paymentdate and the payment receiver. The payment reference entity can alsoidentify parties involved and banking details associated with a payment.The business transaction document reference package can also include acheck reference entity characterizing a reference to a check (i.e.,checknumber) that was used for the payment, and a bill of exchangereference entity characterizing a reference to a bill of exchange (i.e.,a bill of exchange number) that was used for the payment.

The payment explanation package can include a payment explanation itementity characterizing a payment amount for the payee. It can refer toone or more invoices or other business documents relevant for thepayment amount such as potential adjustments applied by the payer.

An electronic message to provide notification of the payment behavior ofthe business partner can be generated by a first application thatexecutes in a landscape of computer systems providing message-basedservices. Transmission of the message to a second application can beinitiated in order to provide notification of the payment behavior ofthe business partner. Responding to the message to provide notificationof the payment behavior of the business partner can include receiving amessage including a credit payment behavior summary package andinitiating the notification of the payment behavior of the businesspartner. A credit payment behavior summary package can contain a creditpayment behavior summary message entity and a party package. The creditpayment behavior summary message entity can characterize key figuresregarding the payment behavior of a business partner. The party packagecan contain information that characterizes the parties relevant to thepayment behavior of the business party.

In some variations, the party package can contain a debtor party entity,a creditor party entity, and a seller party entity. The debtor partyentity can characterize a debtor party having a payment obligation. Thecreditor party entity can characterize a party that owns a receivabledue from the debtor party. The seller party entity can characterize aparty that has sold a product to the debtor party. The message toprovide notification of the payment behavior of the business partner canfurther contain a product information package. The product informationpackage can contain information that characterizes the product sold tothe debtor party. The product information package can further contain apayment information package. The payment information package can containinformation that characterizes the payment behavior of the debtor party.The payment information package can contain a last payment entity, anoldest open item entity and a maximum level dunned open item entity. Thelast payment entity can characterize a last payment received from thedebtor party. The oldest open item entity can characterize an oldestopen item of the debtor party. The maximum level dunned open item entitycan characterize an open item of the debtor party having a highestdunning level.

An electronic message requesting to generate a query regardingcreditworthiness of a party can be generated by a first application thatexecutes in a landscape of computer systems providing message-basedservices. Transmission of the message to a second application can beinitiated in order to generate a query regarding creditworthiness of aparty. Responding to a message requesting to generate a query regardingcreditworthiness of a party can include receiving a message including acredit worthiness query package and initiating a query regardingcreditworthiness of a party. The credit worthiness query package cancontain a credit worthiness entity and a party package. The creditworthiness entity can characterize a query regarding creditworthiness ofa party. The party package can contain a debtor party entity that cancharacterize a party for whom creditworthiness information is to beprovided.

In some variations, the party package can further contain a creditorparty entity and a seller party entity. The creditor party entity cancharacterize a party that owns a receivable due from a debtor. Theseller party entity can characterize a party that sells or plans to sella product to a debtor. The credit worthiness query package can furthercontain a product information package. The product information packagecan contain information that can characterize a product category of aproduct sold or to be sold to a debtor.

An electronic message requesting to generate a response to a queryregarding the creditworthiness of a party can be generated by a firstapplication that executes in a landscape of computer systems providingmessage-based services. Transmission of the message to a secondapplication can be initiated in order to generate a response to a queryregarding the creditworthiness of a party. Responding to a messagerequesting to generate a response to a query regarding creditworthinessof a party can include receiving a message including a credit worthinessquery package and initiating a response to a query regardingcreditworthiness of a party. The credit worthiness query package cancontain a credit worthiness entity, a party package and an informationpackage. The credit worthiness entity can characterize a query regardingcreditworthiness of a party. The party package can contain a debtorparty entity that can characterize a party for whom creditworthinessinformation is to be provided. The information package can contain acredit rating entity that can characterize a credit rating for a debtorparty.

In some variations, the party package can further contain a creditorparty entity and a seller party entity. The creditor party entity cancharacterize a party that owns a receivable due from a debtor. Theseller party entity can characterize a party that sells or plans to sella product to a debtor. The credit worthiness query package can furthercontain a product information package. The product information packagecan contain information that can characterize a product category of aproduct sold or to be sold to a debtor. The information package canfurther contain a credit risk class entity, a credit limit entity and acredit exposure entity. The credit risk class entity can characterize arisk of non-payment by a debtor party. The credit limit entity cancharacterize a credit limit for a debtor party. The credit exposureentity can characterize a level of a credit limit that has beenconsumed.

An electronic message to request generation of delivery quantity andscheduling information can be generated by a first application thatexecutes in a landscape of computer systems providing message-basedservices. Transmission of the message to a second application can beinitiated in order to request generation of delivery quantity andscheduling information. Responding to the request for generation ofdelivery quantity and scheduling information can include receiving amessage including a purchase request package and initiating a generationof delivery quantity and scheduling information. A purchase requestpackage can contain a purchase request entity and a purchase requestitem package. The purchase request entity can characterize requisitionrequirements. The purchase request item package can contain a scheduleline package that can characterize quantity and date informationassociated with a requisition.

In some variations, the party package can further contain a buyer partyentity and a bill to party entity. The buyer party entity cancharacterize a party that buys goods or services. The bill to partyentity can characterize a party that is billed for goods or services.The item package can further contain a delivery information package, adelivery schedule item party package, a location package and a scheduleline package. The delivery information package can contain a previousdelivery entity and a cumulative delivery entity. The previous deliveryentity can characterize identification and validity of a last releaseinstance previously transferred in a delivery schedule. The cumulativedelivery entity can characterize identification and validity ofinstances previously transferred in a delivery schedule. The deliveryschedule item party package can contain a buyer party entity and aproduct recipient party entity. The buyer party entity can characterizea party that buys the goods to be delivered. The product recipient partyentity can characterize a party that receives a goods delivery. Thelocation package can contain a ship from location entity, atrans-shipment location entity and a ship to location entity. The shipfrom location entity can characterize a place from which ordered goodsare delivered. The trans-shipment location entity can characterize alocation to which ordered products are trans-shipped en route to arecipient. The ship to location entity can characterize a place to whichordered goods are delivered. The schedule line package can contain aschedule line entity and a confirmed schedule line entity. The scheduleline entity can characterize a statement about goods to be delivered.The confirmed schedule line entity can characterize a confirmation froma vendor party as terms of a delivery of goods from a schedulingagreement An electronic message to request generation of deliveryquantity and scheduling information can be generated by a firstapplication that executes in a landscape of computer systems providingmessage-based services. Transmission of the message to a secondapplication can be initiated in order to request generation of deliveryquantity and scheduling information. Responding to the request forgeneration of delivery quantity and scheduling information can includereceiving a message including a purchase request package and initiatinga generation of delivery quantity and scheduling information. A purchaserequest package can contain a purchase request entity and a purchaserequest item package. The purchase request entity can characterizerequisition requirements. The purchase request item package can containa schedule line package that can characterize quantity and dateinformation associated with a requisition.

In some variations, the party package can further contain a buyer partyentity and a bill to party entity. The buyer party entity cancharacterize a party that buys goods or services. The bill to partyentity can characterize a party that is billed for goods or services.The item package can further contain a delivery information package, adelivery schedule item party package, a location package and a scheduleline package. The delivery information package can contain a previousdelivery entity and a cumulative delivery entity. The previous deliveryentity can characterize identification and validity of a last releaseinstance previously transferred in a delivery schedule. The cumulativedelivery entity can characterize identification and validity ofinstances previously transferred in a delivery schedule. The deliveryschedule item party package can contain a buyer party entity and aproduct recipient party entity. The buyer party entity can characterizea party that buys the goods to be delivered. The product recipient partyentity can characterize a party that receives a goods delivery. Thelocation package can contain a ship from location entity, atrans-shipment location entity and a ship to location entity. The shipfrom location entity can characterize a place from which ordered goodsare delivered. The trans-shipment location entity can characterize alocation to which ordered products are trans-shipped en route to arecipient. The ship to location entity can characterize a place to whichordered goods are delivered. The schedule line package can contain aschedule line entity and a confirmed schedule line entity. The scheduleline entity can characterize a statement about goods to be delivered.The confirmed schedule line entity can characterize a confirmation froma vendor party as terms of a delivery of goods from a schedulingagreement.

Generating a notification regarding a shipment event associated with adelivery of goods can be accomplished by using a first applicationexecuting in a landscape of computer systems providing message-basedservices to generate an electronic message and initiating transmissionof the message to a second application to generate a shipmentnotification regarding an event associated with a delivery of goods. Thegenerated message includes a delivery package containing a deliveryentity characterizing goods or a combination of goods to be madeavailable for transportation. The delivery package also contains alocation package containing a ship to location entity characterizing aplace to which goods are shipped. The delivery package also contains anitem package containing an item entity characterizing a quantity ofgoods in a delivery. The item package further contains a productinformation package containing information characterizing a product in adelivery item.

The delivery package can further contain a handling unit containinginformation characterizing units of packaging materials and packagedproducts. The delivery package can also contain a delivery party packagecontaining a buyer party entity characterizing a party that purchasedgoods specified in a delivery. The delivery party package can alsocontain a vendor party entity characterizing is a party that deliversgoods. The delivery party package can also contain a product recipientparty characterizing is party to whom goods are delivered. The deliveryparty package can also contain a carrier party entity characterizing aparty that transports goods. The delivery party package can also containa bill to party entity characterizing a party to whom an invoice fordelivered goods is sent. The delivery package can also contain atransport information package containing a transport means entitycharacterizing a transport mechanism for a delivery. The transportinformation package can also contain a transport tracking entitycharacterizing information tracking a status of a transport of adelivery. The delivery package can also contain a delivery informationpackage containing information characterizing delivery conditionsrelated to a shipping notification.

The location package can further contain a ship from location entitycharacterizing a place from which goods are shipped. The locationpackage can also contain a trans-shipment location entity characterizinga location at which goods are to be trans-shipped on their way to arecipient. In addition, the item package can further contain a businesstransaction document reference package containing a purchase orderreference entity characterizing a reference to a purchase order or anitem in a purchase order. The business transaction document referencepackage can also contain an origin purchase order reference entitycharacterizing a reference to an original purchase order or an itemwithin an original purchase order. The business transaction documentreference package can also contain a scheduling agreement referenceentity characterizing an outline agreement item. The businesstransaction document reference package can further contain a sales orderreference entity characterizing a reference to an item in a sales order.The location package can further contain a batch package containinginformation characterizing a batch in a delivery item.

Generating a notification regarding a shipment event associated with adelivery of goods can be accomplished by receiving an electronic messagein a landscape of computer systems providing message-based services andinitiating a notification regarding a shipment event associated with adelivery of goods. The received message includes a delivery packagecontaining a delivery entity characterizing goods or a combination ofgoods to be made available for transportation. The delivery package alsocontains a location package containing a ship to location entitycharacterizing a place to which goods are shipped. The delivery packagefurther contains an item package containing an item entitycharacterizing a quantity of goods in a delivery. The item package alsocontains a product information package containing informationcharacterizing a product in a delivery item.

Generating a notification regarding a receipt of a delivery of goods canbe accomplished by using a first application executing in a landscape ofcomputer systems providing message-based services to generate anelectronic message and initiating transmission of the message to asecond application to generate a notification regarding a receipt of adelivery of goods. The generated message includes a delivery packagecontaining a delivery entity characterizing a confirmation of a receiptof a delivery of goods. The delivery package also contains a partypackage containing a vendor party entity characterizing party thatdelivered goods or on whose behalf goods were delivered. The deliverypackage also contains a location package containing informationcharacterizing a place to which goods were delivered. The deliverypackage further contains an item package containing an item entitycharacterizing a quantity of goods that were delivered. The item packagealso contains a product information package containing informationcharacterizing a delivered.

The party package can further contain a product recipient party entitycharacterizing a party that took delivery of goods. In addition, theitem package can further contain a delivery information packagecontaining information characterizing a delivery information for adelivery of goods.

Generating a notification regarding a receipt of a delivery of goods canbe accomplished by receiving an electronic message in a landscape ofcomputer systems providing message-based services and initiatinggeneration of a notification regarding a receipt of a delivery of goods.The received message includes a delivery package containing a deliveryentity characterizing goods or a combination of goods to be madeavailable for transportation. The delivery package also contains alocation package containing a ship to location entity characterizing aplace to which goods are shipped. The delivery package further containsan item package containing an item entity characterizing a quantity ofgoods in a delivery. The item package also contains a productinformation package containing information characterizing a product in adelivery item.

An electronic message requesting to generate invoicing informationassociated with a business transaction can be generated by a firstapplication that executes in a landscape of computer systems providingmessage-based services. Transmission of the message to a secondapplication can be initiated in order to generate invoicing informationassociated with a business transaction . Responding to the request togenerate invoicing information associated with a business transactioncan include receiving a message including invoice package and initiatingthe generation of invoicing information associated with a businesstransaction. The invoice package can contain an invoice entity and aninvoice party package. The invoice entity can characterize payables andreceivables for delivered goods and rendered services. The invoice partypackage can contain a bill to party entity and a bill from party entity.The bill to party entity can characterize a party to which an invoicefor deliveries received or services rendered is sent. The bill fromparty entity can characterize a party initiating an execution of aninvoice.

In some variations, the invoice party package can further contain aninvoice buyer party entity, an invoice seller party entity, an invoiceproduct recipient party entity, an invoice vendor party entity, aninvoice manufacturer party entity, an invoice payer party entity, aninvoice payee party entity and an invoice carrier party entity. Theinvoice buyer party entity can characterize a party authorizingdeliveries or services. The invoice seller party entity can characterizea party that sells goods or services. The invoice product recipientparty entity can characterize a party to whom goods are delivered orservices are provided. The invoice vendor party entity can characterizea party that delivers goods or provides services. The invoicemanufacturer party entity can characterize a party that produces goodsbeing invoiced. The invoice payer party entity can characterize a partythat pays for goods or services. The invoice payee party entity cancharacterize a party that receives payment for goods or services. Theinvoice carrier party entity can characterize a party that transportsgoods to be invoiced.

The invoice due package can further contain a location package, aninvoice delivery information package, an invoice payment informationpackage, an invoice price information package, an invoice tax package,an invoice attachment package, an invoice description package, aninvoice item package, an item hierarchy relationship entity, an itemproduct information package, an item price information package, an itemtax package, an item package, a business transaction document referencepackage, an item attachment package, an item description package and anitem delivery information package. The location package can contain aship to location entity and a ship from location entity. The ship tolocation entity can characterize a place to which goods are shipped orwhere services are provided. The ship from location entity cancharacterize a place from which goods are shipped. The invoice deliveryinformation package can contain information that can characterizedelivery information for goods being invoiced. The invoice paymentinformation package can contain a cash discount terms entity and apayment form entity. The cash discount terms entity can characterizeterms of payment. The payment form entity can characterize a paymentform and required data for the payment form. The invoice priceinformation package can contain information that can characterize atotal price to be settled for goods or services to be invoiced. Theinvoice tax package can contain information that can characterize taxprice components in an invoice. The invoice attachment package cancontain information that can characterize attachment informationassociated with an invoice. The invoice description package can containinformation that can characterize texts associated with an invoice.

The invoice item package can contain an item entity. The item entity cancharacterize pricing information and taxes for a quantity of productthat has been delivered or for a service that has been rendered. Theitem hierarchy relationship entity can characterize hierarchicalrelationships between items. The item product information package cancontain a product entity and a product category entity. The productentity can characterize a product in an invoice item. The productcategory entity can characterize a category of a good or service that isbeing invoiced. The item price information package can containinformation that can characterize an amount invoiced for goods deliveredor services rendered. The item tax package can contain information thatcan characterize tax components in a total amount invoiced for goodsdelivered or services rendered.

The item package can contain an item buyer party entity, an item sellerparty entity, an item product recipient party entity, an item vendorparty entity, an item manufacturer party and a carrier party entity. Theitem buyer party entity can characterize a party authorizing deliveriesor services. The item seller party entity can characterize a party thatsells goods or services. The item product recipient party entity cancharacterize a party to whom goods are delivered or services areprovided. The item vendor party entity can characterize a party thatdelivers goods or provides services. The item manufacturer party cancharacterize a party that produces goods being invoiced. The carrierparty entity can characterize a party that transports goods to beinvoiced. The business transaction document reference package cancontain a purchase order reference entity, a sales order referenceentity, a delivery reference entity, a service acknowledgement referenceentity, an origin invoice reference entity, a purchase contractreference entity, a sales contract reference entity, a buyer productcatalogue reference entity and a seller product catalogue referenceentity. The purchase order reference entity can characterize a purchaseorder or an item within a purchase order. The sales order referenceentity can characterize a sales order or an item within a sales order.The delivery reference entity can characterize a delivery or an itemwithin a delivery. The service acknowledgement reference entity cancharacterize a confirmation by a seller that a service has beenprovided. The origin invoice reference entity can characterize areference to an invoice previously sent. The purchase contract referenceentity can characterize a purchase contract or an item within a purchasecontract. The sales contract reference entity can characterize a salescontract or an item within a sales contract. The buyer product cataloguereference entity can characterize a product catalogue of a buyer or anitem within the catalogue. The seller product catalogue reference entitycan characterize a product catalogue of a seller or an item within thecatalogue. The item attachment package can contain information that cancharacterize attachment information associated with an invoice. The itemdescription package can contain information that can characterize textsassociated with an invoice. The item delivery information package cancharacterize delivery information associated with an invoice. In somevariations, the item package can further contain an accounting package.The accounting package can contain information that can characterize anassignment of an invoice item net amount or partial amount to a set ofaccount assignment objects.

An electronic message requesting to generate business transactioninformation can be generated by a first application that executes in alandscape of computer systems providing message-based services.Transmission of the message to a second application can be initiated inorder to generate business transaction information. Responding to therequest to generate business transaction information can includereceiving a message including invoice due package and initiating thegeneration of business transaction information. An invoice due packagecan contain an invoice due entity, an invoice due party package, aninvoice due location package, an invoice due delivery informationpackage, an invoice due payment information package, an invoice dueprice information package, an invoice due account assignment package, aninvoice due attachment package, an invoice due description package andan invoice due item package. The invoice due entity can characterizedetails of a business transaction relevant for settling the businesstransaction. The invoice due party package can contain information thatcan characterize parties to a business transaction. The invoice duelocation package can contain information that can characterize localesassociated with a business transaction. The invoice due deliveryinformation package can contain information that can characterize adelivery of goods associated with a business transaction. The invoicedue payment information package can contain information that cancharacterize payment terms for a business transaction. The invoice dueprice information package can contain information that can characterizea total price to be settled for goods or services provided under abusiness transaction. The invoice due account assignment package cancontain information that can characterize account assignment informationassociated with a business transaction. The invoice due attachmentpackage can contain information that can characterize attachmentinformation associated with a settlement of a business transaction. Theinvoice due description package can contain information that cancharacterize texts associated with a settlement of a businesstransaction. The invoice due item package can contain information thatcan characterize item information for a settlement of a businesstransaction.

In some variations, the invoice due party package can further contain abuyer party entity, a seller party entity, a product recipient partyentity, a vendor party entity, a bill to party entity, a bill from partyentity, a payer party entity and a payee party entity. The buyer partyentity can characterize a party that purchases goods or services. Theseller party entity can characterize a party that sells goods orservices. The product recipient party entity can characterize a party towhom goods are delivered or services are provided. The vendor partyentity can characterize a party that delivers goods or providesservices. The bill to party entity can characterize a party to which aninvoice for goods or services is sent. The bill from party entity cancharacterize a party that draws up an invoice for goods or services. Thepayer party entity can characterize a party that pays for goods orservices. The payee party entity can characterize a party that receivespayment for goods or services. The invoice due location package canfurther contain a ship to location entity and a ship from location. Theship to location entity can characterize a place to which goods areshipped or where services are provided. The ship from location cancharacterize a place from which goods are shipped. The invoice duepayment information package can further contain a cash discount termsentity and a payment form entity. The cash discount terms entity cancharacterize terms of payment. The payment form entity can characterizea payment form and required data for the payment form.

The item package can further contain an item entity, an item hierarchyrelationship entity, an item product information package, an item priceinformation package, a business transaction document reference package,an item attachment package, an item due description package and adelivery information package. The item entity can characterizeinformation from a business document item that is to be taken intoaccount for a settlement of a business transaction. The item hierarchyrelationship entity can characterize hierarchical relationships betweenitems. The item product information package can contain a product entityand a product category entity. The product entity can characterize aproduct for which an invoice is due. The product category entity cancharacterize a category of a product or service that is being invoiced.The item price information package can contain a price entity and aprocurement cost upper limit entity. The price entity can characterizean amount to be settled for a product or service. The procurement costupper limit entity can characterize a quantity or value-basedrestriction placed on a product or service to be settled.

The business transaction document reference package can contain apurchase order reference entity, a sales order reference entity, adelivery reference entity, a purchase contract reference entity, a salescontract reference entity, a buyer product catalogue reference entityand a vendor product catalogue reference entity. The purchase orderreference entity can characterize a purchase order or an item within apurchase order. The sales order reference entity can characterize asales order or an item within a sales order. The delivery referenceentity can characterize a delivery or an item within a delivery. Thepurchase contract reference entity can characterize a purchase contractor an item within a purchase contract. The sales contract referenceentity can characterize a sales contract or an item within a salescontract. The buyer product catalogue reference entity can characterizea product catalogue of a buyer or an item within the catalogue. Thevendor product catalogue reference entity can characterize a productcatalogue of a vendor or an item within the catalogue. The itemattachment package can contain information that can characterizeattachment information associated with a settlement of a businesstransaction. The item due description package can contain informationthat can characterize texts associated with a settlement of a businesstransaction. The delivery information package can characterize deliveryinformation associated with a business transaction.

Requesting a generation of a loan contract can be implemented by using afirst application executing in a landscape of computer systems providingmessage-based services to generate an electronic message and initiatetransmission of the message to a second application to generate a loancontract or a request associated therewith. The generated messageincludes a loan contract package. The loan contract package contains aloan contract entity characterizing information required to generate aloan contract. The loan contract package also includes a party packagecontaining information characterizing parties to a loan contract. Theloan contract package also contains a product information packagecontaining information characterizing a product upon which a loancontract is based. The loan contract package also contains a paymentinformation package containing information characterizing informationassociated with payment processing. The loan contract package furthercontains an item package containing information characterizingconditions of a loan contract.

The party package can contain a lender party entity characterizing aparty that grants a loan. The party package can also contain a borrowerparty entity characterizing a party that is issued a loan. The partypackage can also contain a payer party entity characterizing a partyresponsible for repayment of a loan. The party package can also containa broker party entity characterizing an agent for issuance of a loan.The party package can further contain a bailsman party entitycharacterizing a party responsible for guaranteeing a loan.

The product information package can further contain a product categoryentity characterizing a product category of a loan. The productinformation package can further contain a product entity. In addition,the payment information package can further contain a payment formentity characterizing a form of payment. The product information packagecan further contain a bank account entity characterizing a bank account.Further, the loan contract package can further contain a loan contractattachment package containing information characterizing documentsrelevant for a loan. The loan contract package can also contain a loancontract item package. The loan contract item package can contain a loancondition information entity characterizing terms and conditions of aloan. The loan can contain a loan interest condition entitycharacterizing an interest condition for a loan. The loan can alsocontain a loan amortizement condition entity characterizing a repaymentcondition for a loan. The loan can further contain a loan fee conditionentity characterizing a fee condition for a loan. The a loan contractitem package can further contain a loan contract item party packagecontaining information characterizing all parties to a loan contract.

Requesting a generation of a loan contract can be accomplished byreceiving an electronic message and initiating generation of a loancontract in a landscape of computer systems providing message-basedservices. The received message includes a loan contract package. Theloan contract package contains a loan contract entity characterizinginformation required to generate a loan contract. The loan contractpackage can also contain a party package containing informationcharacterizing parties to a loan contract. The loan contract package canalso contain a product information package containing informationcharacterizing a product upon which a loan contract is based. The loancontract package can also contain a payment information packagecontaining information characterizing information associated withpayment processing. The loan contract package can further contain anitem package containing information characterizing conditions of a loancontract.

Generating a confirmation of a creation of a loan contract can beaccomplished by using a first application executing in a landscape ofcomputer systems providing message-based services to generate anelectronic message and initiating transmission of the message to asecond application to generate a confirmation of a creation of a loancontract. The generated message includes a loan contract package. Theloan contract package contains a loan contract entity characterizinginformation regarding a creation of a loan contract. The loan contractpackage also contains a log package containing informationcharacterizing log messages associated with a creation of al loancontract. The loan contract package further contains a paymentinformation package, and the payment information package contains a bankaccount entity characterizing information about a bank account to beused to repay a loan.

Generating a confirmation of a creation of a loan contract can beaccomplished by receiving an electronic message in a landscape ofcomputer systems providing message-based services and initiating ageneration of a confirmation of a creation of a loan contract. Thereceived message includes a loan contract package. The loan contractpackage includes a loan contract entity characterizing informationregarding a creation of a loan contract. The loan contract package canalso include a log package containing information characterizing logmessages associated with a creation of al loan contract. The loancontract package can further include a payment information package, andthe payment information package contains a bank account entitycharacterizing information about a bank account to be used to repay aloan.

A notice relating to product activities for a vendor can be created bygenerating an electronic message characterizing activities associatedwith goods of a buyer and initiating transmission of the message to anapplication to generate a notice to a vendor relating to productactivities. In another or the same aspect, generating a notice from abuyer to a vendor relating to product activities can include receivingan electronic message characterizing activities associated with goods ofa buyer and initiating a generation of a notice to a vendor relating toproduct activities.

An electronic message can characterize product activities by including apackage that characterizes activities associated with goods of a buyerat a ship to location and a package containing an entity packagecharacterizing activities associated with goods of a buyer at a ship tolocation. Those packages can be a product activity package and itempackage, respectively, and the entity can be an item entity. Thelocation package can contain a ship to location entity characterizing alocation to which goods are to be delivered and the item package caninclude a product information package characterizing goods to bedelivered.

The product activity message can further contain a party package thatcontains a buyer party entity characterizing a party that purchasesgoods, a vendor party entity characterizing a party that delivers goods,and a product recipient party entity characterizing a party thatreceives a delivery of goods. The party package can further contain abusiness transaction document reference package containing informationcharacterizing references to business documents associated with aproduct activity notice, and the location package can further contain aship from location entity characterizing a location from which goods areto be shipped for delivery. The item package can further contain aninventory package containing an inventory entity characterizing stock ofa good at a buyer and a consignment inventory entity characterizinggoods in possession of a buyer that are owned by a vendor untilpurchased.

An electronic message requesting to generate a notice of an eventaffecting product demand can be generated by a first application thatexecutes in a landscape of computer systems providing message-basedservices. Transmission of the message to a second application can beinitiated in order to generate a notice of an event affecting productdemand. Responding to the request to generate a notice of an eventaffecting product demand can include receiving a message includingproduct demand influencing event package and initiating a generation ofa notice of an event affecting product demand. A product demandinfluencing event package can contain a product demand influencing evententity, a party package and an item package. The product demandinfluencing event entity can characterize a product demand influencingevent. The party package can contain a buyer party entity and a vendorparty entity. The buyer party entity can characterize a party thatpurchases goods. The vendor party entity can characterize a party thatdelivers goods. The item package can contain an item entity, a locationpackage and a product information package. The item entity cancharacterize activities associated with goods of a buyer at a ship tolocation. The location package can contain a ship to location entity.The ship to location entity can characterize a location to which goodsare to be delivered. The product information package can containinformation that can characterize goods to be delivered. In somevariations, the product demand influencing event package can furthercontain a scheduling package. The scheduling package can containinformation that can characterize time orders utilized to define aschedule for logistics associated with goods affected by a productdemand influencing event. The location package can further contain aship from location entity. The ship from location entity cancharacterize a location from which goods are to be shipped for delivery.The item package can further contain a product information package. Theproduct information package can contain information that cancharacterize goods affected by a product demand influencing event.

An electronic message requesting to generate information associated witha purchase order can be generated by a first application that executesin a landscape of computer systems providing message-based services.Transmission of the message to a second application can be initiated inorder to generate information associated with a purchase order.Responding to the request to generate information associated with apurchase order can include receiving a message including purchase orderpackage and initiating generation of information associated with apurchase order.

The purchase order package can contain a purchase order entity, apurchase order party package, a purchase order location package, apurchase order delivery information package, a purchase order paymentinformation package, a price order price information package, a purchaseorder attachment package, a purchase order description package, apurchase order follow up message package and a purchase order itempackage. The purchase order entity can characterize a request by a buyerto a seller to provide certain quantities of products or services. Thepurchase order party package can contain information characterizingparties to a purchase order. The purchase order location package cancontain information characterizing locations associated with a purchaseorder. The purchase order delivery information package can containinformation characterizing a delivery of goods associated with apurchase order. The purchase order payment information package cancontain information characterizing payment terms associated with apurchase order. The price order price information package can containpricing information associated with a purchase order. The purchase orderattachment package can contain information characterizing attachmentsrelevant to a purchase order. The purchase order description package cancontain information characterizing texts associated with a purchaseorder. The purchase order follow up message package can containinformation characterizing messages associated with a purchase order andoccurring subsequent to an issuance of such purchase order. The purchaseorder item package can contain information characterizing an itemassociated with a purchase order.

In some variations, the purchase order party package can further containa buyer party entity, a seller party entity, a product recipient partyentity, a vendor party entity, a manufacturer party entity, a bill toparty entity, a payer party entity and a carrier party entity. The buyerparty entity can characterize a party that buys goods or services. Theseller party entity can characterize a party that sells goods orservices. The product recipient party entity can characterize a party towhich goods are to be delivered or to whom services are to be provided.The vendor party entity can characterize a party that delivers goods orservices. The manufacturer party entity can characterize a party thatmanufactures goods. The bill to party entity can characterize a party towhich an invoice for goods or services is sent. The payer party entitycan characterize a party that pays for goods or services. The carrierparty entity can characterize a party that transports goods. Thepurchase order location package can further contain a ship to locationentity and a ship from location entity. The ship to location entity cancharacterize a location to which goods are to be delivered or whereservices are to be provided. The ship from location entity cancharacterize a location from where goods are to be shipped. The purchaseorder payment information package can further contain a cash discountterms entity, a payment form entity and a payment card entity. The cashdiscount terms entity can characterize terms of payment in an orderingprocess. The payment form entity can characterize a payment form andassociated payment information. The payment card entity can characterizea credit card or a customer payment card. The purchase order descriptionpackage can further contain a description entity and a confirmationdescription entity. The description entity can characterize textassociated with a purchase order. The confirmation description entitycan characterize text associated with an order confirmation. The followup message package can further contain a follow up purchase confirmationentity, a follow up dispatched delivery notification entity and a followup service acknowledgement request entity. The follow up purchaseconfirmation entity can characterize information associated with aconfirmation to be received by a buyer from a seller in connection witha purchase order. The follow up dispatched delivery notification entitycan characterize notification preferences of a buyer relating tooutbound deliveries by a seller. The follow up service acknowledgementrequest entity can characterize notification preferences of a buyerrelating to services provided by a seller.

The purchase order item package can further contain a purchase orderitem entity, a hierarchy relationship entity, a product informationpackage, a price information package, a purchase order item partypackage, a purchase order location package, a purchase order itemdelivery information package, a purchase order item business transactiondocument reference package, a purchase order item attachment package, apurchase order item description package and a schedule line package. Thepurchase order item entity can characterize a product ordered in apurchase order. The hierarchy relationship entity can characterize ahierarchical relationship between items. The product information packagecan contain a product entity and a product category entity. The productentity can characterize a commercial description of a product. Theproduct category entity can characterize a commercial categorization ofa product. The price information package can contain a price entity, aconfirmed price entity, an item buyer party entity, an item seller partyentity, an item product recipient party entity, an item vendor partyentity, an item manufacturer party entity, an item bill to party entity,an item payer party entity, an item carrier party entity, a ship tolocation entity and a ship from location entity. The price entity cancharacterize a purchase order price specified by a buyer. The confirmedprice entity can characterize a purchase order price specified by aseller.

The purchase order item party package can contain an item buyer partyentity can characterize a party that buys goods or services. The itemseller party entity can characterize a party that sells goods orservices. The item product recipient party entity can characterize aparty to which goods are to be delivered or to whom services are to beprovided. The item vendor party entity can characterize a party thatdelivers goods or services. The item manufacturer party entity cancharacterize a party that manufactures goods. The item bill to partyentity can characterize a party to which an invoice for goods orservices is sent. The item payer party entity can characterize a partythat pays for goods or services. The item carrier party entity cancharacterize a party that transports goods. The purchase order locationpackage can contain a ship to location entity and a ship from locationentity. The ship to location entity can characterize a location to whichgoods are to be delivered or where services are to be provided. The shipfrom location entity can characterize a location from where goods are tobe shipped. The purchase order item delivery information package cancontain information characterizing a delivery of goods associated with apurchase order. The purchase order item business transaction documentreference package can contain a quote reference entity, a purchasecontract reference entity, a sales contract reference entity, an originpurchase order reference entity, a buyer product catalogue referenceentity and a seller product catalogue reference entity. The quotereference entity can characterize a reference to a quotation or an itemwithin a quotation. The purchase contract reference entity cancharacterize a purchase contract or an item in a purchase contract. Thesales contract reference entity can characterize a sales contract or anitem in a sales contract. The origin purchase order reference entity cancharacterize an origin purchase order to an item within an originpurchase order. The buyer product catalogue reference entity cancharacterize a product catalogue of a buyer or an item within suchcatalogue. The seller product catalogue reference entity cancharacterize a product catalogue of a seller or an item within suchcatalogue. The purchase order item attachment package can containinformation characterizing attachments relevant to a purchase order. Thepurchase order item description package can contain a description entityand a confirmation description entity. The description entity cancharacterize texts associated with a purchase order item. Theconfirmation description entity can characterize texts regarding apurchase order item confirmation. The schedule line package can containa schedule line entity and a confirmed schedule line entity. Theschedule line entity can characterize a line containing a quantity anddate of a performance schedule required by a buyer for a purchase order.The confirmed schedule line entity can characterize a quantity and dateof a confirmed by a seller for a purchase order.

An electronic message can be generated that characterizes a status of apurchase order and transmission of this message can be initiated so thatsuch status information can be created. In another or the same aspect,an electronic message can be received that can be used to subsequentlycreate status information for a purchase order.

The message can include a purchase order package that contains one ormore of a purchase order information package containing one or more of apurchase order information entity characterizing a request by a buyer toa seller to provide certain quantities of products or services, apurchase order information party package containing informationcharacterizing parties to a purchase order, a purchase order informationlocation package containing information characterizing locationsassociated with a purchase order, a purchase order information paymentinformation package containing information characterizing paymentinformation associated with a purchase order, a price order priceinformation package containing pricing information associated with apurchase order, a purchase order information attachment packagecontaining information characterizing attachments relevant to a purchaseorder, a purchase order information description package containinginformation characterizing texts associated with a purchase order, apurchase order information follow up message package containinginformation characterizing, and a purchase order information itempackage containing information characterizing an item.

The purchase order information party package can further contain one ormore of a buyer party entity characterizing a party that buys goods orservices, a seller party entity characterizing a party that sells goodsor services, a product recipient party entity characterizing a party towhich goods are to be delivered or to whom services are to be provided,a vendor party entity characterizing a party that delivers goods orservices, a manufacturer party entity characterizing a party thatmanufactures goods, a bill to party entity characterizing a party towhich an invoice for goods or services is sent, a payer party entitycharacterizing a party that pays for goods or services, and a carrierparty entity characterizing a party that transports goods. The purchaseorder information location package further can also contain one or bothof a ship to location entity characterizing a location to which goodsare to be delivered or where services are to be provided and a ship fromlocation entity characterizing a location from where goods are to beshipped. The purchase order information payment information package canadditionally contain one or more of a cash discount terms entitycharacterizing terms of payment in an ordering process, a payment formentity characterizing a payment form and associated payment information,and a payment card entity characterizing a credit card or a customerpayment card. The purchase order information description package canfurther contain one or both of a description entity characterizing textassociated with a purchase order and a confirmation description entitycharacterizing text associated with an order confirmation. The follow upmessage package can include one or more of a follow up purchaseconfirmation entity characterizing information associated with aconfirmation to be received by a buyer from a seller in connection witha purchase order, a follow up dispatched delivery notification entitycharacterizing notification preferences of a buyer relating to outbounddeliveries by a seller, a follow up service acknowledgement requestentity characterizing notification preferences of a buyer relating toservices provided by a seller, and a follow up invoice request entitycharacterizing whether a buyer expects to receive an invoice from aseller.

The purchase order information item package can include one or more of apurchase order information item entity characterizing a product orderedin a purchase order, a hierarchy relationship entity characterizing ahierarchical relationship between items, a product information package,a price information package, a purchase order information item partypackage, a purchase order information location package, a purchase orderinformation item delivery information package containing informationcharacterizing a delivery of goods associated with a purchase order, apurchase order information item business transaction document referencepackage, a purchase order information item attachment package containinginformation characterizing attachments relevant to a purchase order, apurchase order information item description package containing adescription entity characterizing texts associated with a purchase orderitem, and a confirmation description entity characterizing textsregarding a purchase order item confirmation. The product informationpackage can contain one or both of a product entity characterizing acommercial description of a product, and a product categorycharacterizing a commercial categorization of a product. The priceinformation package can contain one or more of a price entitycharacterizing a purchase order price specified by a buyer, a confirmedprice entity characterizing a purchase order price specified by aseller, and a procurement cost upper limit entity characterizing a costupper limit for one or more types of procurement costs. The purchaseorder information item party package can contain one or more of an itembuyer party entity characterizing a party that buys goods or services,an item seller party entity characterizing a party that sells goods orservices, an item product recipient party entity characterizing a partyto which goods are to be delivered or to whom services are to beprovided, an item vendor party entity characterizing a party thatdelivers goods or services, an item manufacturer party entitycharacterizing a party that manufactures goods, an item bill to partyentity characterizing a party to which an invoice for goods or servicesis sent, an item payer party entity characterizing a party that pays forgoods or services, and an item carrier party entity characterizing aparty that transports goods. The purchase order information locationpackage can contain one or both of a ship to location entitycharacterizing a location to which goods are to be delivered or whereservices are to be provided, and a ship from location entitycharacterizing a location from where goods are to be shipped. Thepurchase order information item business transaction document referencepackage can contain one or more of a quote reference entitycharacterizing a reference to a quotation or an item within a quotation,a purchase contract reference entity characterizing a purchase contractor an item in a purchase contract, a sales contract reference entitycharacterizing a sales contract or an item in a sales contract, anorigin purchase order reference entity characterizing an origin purchaseorder to an item within an origin purchase order, a buyer productcatalogue reference entity characterizing a product catalogue of a buyeror an item within such catalogue, and a seller product cataloguereference entity characterizing a product catalogue of a seller or anitem within such catalogue.

Generating a request querying a buyer to procure products or servicescan be accomplished by using a first application executing in alandscape of computer systems providing message-based services togenerate an electronic message and initiate transmission of the messageto a second application. The generated message includes a purchaserequest package. The purchase request package contains a purchaserequest entity characterizing requisition requirements. The purchaserequest package further contains a purchase request item package, andthe purchase request item package contains a schedule line packagecontaining information characterizing quantity and date informationassociated with a requisition.

The purchase request party package can further contain a buyer partyentity characterizing a party that buys goods or services. The purchaserequest party package can also contain a seller party entitycharacterizing a party that sells goods or services, The purchaserequest party package can also contain a proposed seller party entitycharacterizing a preferred party for selling goods or services. Thepurchase request party package can also contain a requestor party entitycharacterizing a party that requests procurement of goods or services.The purchase request party package can also contain a product recipientparty entity characterizing a party to which goods are to be deliveredor to whom services are to be provided. The purchase request partypackage can further contain a manufacturer party entity characterizing aparty that manufactures goods.

The generated message can further contain a purchase request locationpackage grouping information associated with locations relevant for arequisition. The purchase request location package includes a ship tolocation entity characterizing a location to which goods are to bedelivered or where services are to be provided. The purchase requestlocation package also includes a ship from location entitycharacterizing a location from where goods are to be shipped.

The purchase request item package can further contain a purchase requestentity characterizing a requested product. The purchase request itempackage can also contain a hierarchy relationship entity characterizingrelationship between items in an item hierarchy. The purchase requestitem package can also contain a product information package containing aproduct entity characterizing a product and a product category entitycharacterizing a product category. The purchase request item package canalso contain a price information package containing a price entitycharacterizing a specified purchase order price, and a procurement costupper limit entity characterizing upper procurement limits. The purchaserequest item package can also contain an item party package containinginformation characterizing parties to a requisition. The purchaserequest item package can also contain a location package containinginformation characterizing location information associated with arequisition. The purchase request item package can also contain anobject reference package containing information characterizing businessdocuments relevant for a requisition. The object reference packagecontains a purchase contract reference entity characterizing a purchasecontract or an item in a purchase contract. The object reference packagealso contains a purchase order reference entity characterizing apurchase order or an item in a purchase order. The object referencepackage also contains a project reference entity characterizing aproject or an element within a project associated with a requisition.The object reference package further contains a project elementassignment entity characterizing an assignment between two elements of aproject associated with a requisition. The purchase request item packagecan also contain an accounting object set assignment package containinginformation characterizing accounting information associated with arequisition. The purchase request item package can also contain anattachment package containing information characterizing attachmentsrelevant to a requisition. The purchase request item package can furthercontain a description package containing information characterizingtexts relating to a requisition.

The schedule line package can further contain a schedule line entitycharacterizing quantity and dates of a performance period associatedwith a requisition. The schedule line package can also contain adelivery period entity characterizing a delivery period for arequisition. The schedule line package can further contain a quantityentity characterizing a quantity specified by a requisition.

Generating a request querying a buyer to procure products or servicescan be accomplished by receiving an electronic message in a landscape ofcomputer systems providing message-based services and initiating ageneration of a request querying a buyer to procure products orservices. The received message includes a purchase request package. Thepurchase request package contains a purchase request entitycharacterizing requisition requirements. The purchase request packagealso contains a purchase request item package containing a schedule linepackage containing information characterizing quantity and dateinformation associated with a requisition.

Generating a confirmation of a fulfillment of a requisition can beaccomplished by using a first application executing in a landscape ofcomputer systems providing message-based services to generate anelectronic message and initiate transmission of the message to a secondapplication. The generated message includes a purchase request packagecontaining a purchase request entity characterizing a confirmation ofrequirements associated with a procurement of products or services. Thepurchase request package also contains an item package containing anitem entity characterizing a product and a purchase order packagecontaining information characterizing a level of fulfillment of arequirement by a purchase order.

Generating a confirmation of a fulfillment of a requisition can beaccomplished by receiving an electronic message in a landscape ofcomputer systems providing message-based services and initiating ageneration of a confirmation of a fulfillment of a requisition. Thereceived message includes a purchase request package containing apurchase request entity characterizes a confirmation of requirementsassociated with a procurement of products or services. The purchaserequest further includes an item package containing an item entitycharacterizing a product, and a purchase order package containinginformation characterizing a level of fulfillment of a requirement by apurchase order.

An electronic message to generate purchasing contract information can begenerated by a first application that executes in a landscape ofcomputer systems providing message-based services. Transmission of themessage to a second application can be initiated in order to generatepurchasing contract information.

The message can include a purchasing contract package. The purchasingcontract package can contain one or more of a purchasing contract entitycharacterizing an agreement to order products or provide services withina certain period of time, a purchasing contract party package containinginformation characterizing parties to a purchasing contract parties to apurchasing contract, a purchasing contract location package containinginformation characterizing locations associated with a purchasingcontract, a purchasing contract delivery information package containinginformation characterizing a delivery requested in a purchasingcontract, a purchasing contract payment information package containinginformation characterizing payment terms for a purchasing contract, apurchasing contract price information package containing informationcharacterizing pricing of goods or services identified in a purchasingcontract, a purchasing contract attachment package containinginformation characterizing documents referring to a purchasing contract,a purchasing contract description package containing informationcharacterizing texts associated with a purchasing contract, and apurchasing contract item package containing information characterizing aproduct or service in a purchasing contract.

The purchasing contract party package can include one or more of a buyerparty entity characterizing a party that buys goods or services, aseller party entity characterizing a party that sells goods or services,a product recipient party entity characterizing a party to which goodsare to be delivered or to whom services are to be provided, and acontract release authorized party entity characterizing a party that isauthorized to effect releases from a purchasing contract. The purchasingcontract attachment package can also contain one or more of anattachment web address entity characterizing a location of documentsreferring to a purchasing contract, an internal attachment web addressentity characterizing a location of internal documents referring to apurchasing contract, and a legal document attachment entitycharacterizing legal text of a purchasing contract. The purchasingcontract description package can include one or more of a descriptionentity characterizing text associated with a purchasing contract, and aninternal description entity characterizing internal text associated witha purchasing contract.

The purchasing contract item package can contain one or more of apurchasing contract item entity characterizing a product or service in apurchasing contract, a purchasing contract item product informationpackage, a purchasing contract item price information package containinginformation characterizing pricing of goods or services identified in apurchasing contract, a purchasing contract item location packagecontaining information characterizing locations associated with apurchasing contract, a purchasing contract item party package containinginformation characterizing parties to a purchasing contract parties to apurchasing contract, a purchasing contract item delivery informationpackage containing information characterizing a delivery requested in apurchasing contract, a purchasing contract business document objectreference package, a purchasing contract item attachment packagecontaining information characterizing documents referring to apurchasing contract, and a purchasing contract item description packagecontaining information characterizing texts associated with a purchasingcontract. The purchasing contract item product information package cancontain one or both of a product entity characterizing a product orservice, and a product category entity characterizing a category for aproduct or service. The purchasing contract business document objectreference package can contain one or more of a quote reference entitycharacterizing a bid of a purchaser or a bid to an item within a bid ofa purchaser, an operational purchasing contract reference entitycharacterizing an operational purchasing contract or an item in anoperational purchasing contract, and a buyer product catalogue referenceentity characterizing a product catalogue of a purchaser or to an itemwithin such a catalogue.

An electronic message to generate a notification of a purchasingcontract release can be generated by a first application that executesin a landscape of computer systems providing message-based services.Transmission of the message to a second application can be initiated inorder to generate a notification of a purchasing contract release.

The message can contain a purchasing contract release package cancontain one or more of a purchasing contract release entitycharacterizing a notification regarding a performed release withreference to a purchasing contract, a purchasing contract release partypackage containing information characterizing a release of a purchasingcontract, a purchasing contract release location package containinginformation characterizing locations associated with a release of apurchasing contract, and a purchasing contract release item package. Thepurchasing contract release item can include one or more of a purchasingcontract release item entity characterizing an item in a purchasingcontract release, a purchasing contract release item location packagecontaining information characterizing locations associated with acontract release item, and a purchasing contract release item businessdocument object package containing information characterizing referencesto business documents relevant to an item in a purchasing contractrelease.

An electronic message to generate replenishment order information can begenerated by a first application that executes in a landscape ofcomputer systems providing message-based services. Transmission of themessage to a second application can be initiated in order to generatereplenishment order information.

The electronic message can include a replenishment order packagecontaining a replenishment order entity characterizing a replenishmentorder executed by a vendor for a customer, and a replenishment orderitem package. The replenishment order item package can contain areplenishment order item entity characterizing an item in areplenishment order, a replenishment order item location package thatcontains a ship from location entity characterizing a location fromwhich products listed in a replenishment order are to be delivered and aship to location entity characterizing a location from which productslisted in a replenishment order are to be delivered. The replenishmentorder item package can also include a replenishment order item productinformation package containing information characterizing a productassociated with a replenishment order.

The replenishment order package can contain one or more of areplenishment order party package, a replenishment order deliveryinformation package containing information characterizing a requesteddelivery for a replenishment order, a replenishment order paymentinformation package containing information characterizing paymentinformation for a replenishment order, and a replenishment orderhandling unit package containing information characterizing packingrequirements for product associated with a replenishment order. Thereplenishment order party package can include one or more of a buyerparty entity characterizing a party that purchases goods associated witha replenishment order, a seller party entity characterizing a party thatsells goods associated with a replenishment order, and a vendor partyentity characterizing a party to provide a replenishment delivery. Inaddition, the replenishment order location package can further contain atrans-shipment location entity characterizing a location at product in areplenishment order is transferred from a first transportation mechanismto a second transportation mechanism.

The replenishment order item package can contain one or more of abusiness transaction documents reference package, a replenishment orderitem party package, a replenishment order item product informationpackage containing information characterizing a product listed in areplenishment order, a replenishment order item batch package containinginformation characterizing a batch to be delivered, a replenishmentorder item promotion package containing information characterizingmarketing promotions associated with a replenishment order, areplenishment order item price information package containing pricinginformation of an item in a replenishment order, and a replenishmentorder item schedule line package. The business transaction documentsreference package can contain on or more of a purchase contractreference entity characterizing a purchase contract or an item in apurchase contract, a scheduling agreement reference entitycharacterizing a scheduling agreement or an item in a schedulingagreement, a purchase order reference entity characterizing a purchaseorder of a buyer or a purchase order item created by a vendor, an originpurchase order reference entity characterizing an original purchaseorder or to an item within an original purchase order, a sales orderreference entity characterizing a sales order or an item in a salesorder, and an origin sales order reference entity characterizing anoriginal sales order or an item within an original sales order. Thereplenishment order item party package can contain one or more of areplenishment order item buyer party entity characterizing a party thatpurchases goods associated with a replenishment order, a replenishmentorder item product recipient party entity characterizing a party toreceive goods associated with a replenishment order, and a replenishmentorder item bill to party entity characterizing a party to receive aninvoice associated with a replenishment order. The replenishment orderitem schedule line package can contain one or both of a schedule lineentity characterizing quantity and scheduling associated with areplenishment order, and a confirmed schedule line entity characterizinga confirmation of quantity and scheduling associated with areplenishment order.

An electronic message to generate replenishment order proposalinformation can be generated by a first application that executes in alandscape of computer systems providing message-based services.Transmission of the message to a second application can be initiated inorder to generate replenishment order proposal information.

The message can include a replenishment order proposal package cancontain a replenishment order proposal entity characterizing a proposalfor an order to replenish product supply and a replenishment orderproposal item package. The replenishment order proposal item package cancontain a replenishment order proposal item entity characterizing anitem in a replenishment order proposal, a replenishment order proposalitem location package, and a replenishment order proposal item productinformation package containing information characterizing a productassociated with a replenishment order proposal. The replenishment orderproposal location package can contain a ship from location entitycharacterizing a location from which products listed in a replenishmentorder proposal are to be delivered and a ship to location entitycharacterizing a location from which products listed in a replenishmentorder proposal are to be delivered.

The replenishment order proposal package can contain one or both of areplenishment order proposal party package and a replenishment orderproposal business document object reference package containinginformation characterizing business documents relating to areplenishment order. The replenishment order proposal party package cancontain one or more of a buyer party entity characterizing a party thatbuys goods associated with a replenishment order, a vendor party entitycharacterizing a party that delivers goods associated with areplenishment order, and a product recipient party entity characterizinga party to which goods associated with a replenishment order aredelivered. The product information package can contain one or both of aproduct category entity characterizing a category of a productassociated with a replenishment order proposal, and a vendor productcategory entity characterizing a vendor category of a product associatedwith a replenishment order proposal.

The replenishment order proposal item package can contain one or more ofa replenishment order proposal item price information package containinginformation characterizing pricing of a product associated with aproposed replenishment order, a replenishment order proposal item partypackage containing information characterizing parties associated with aproposed replenishment order a replenishment order proposal itemlocation package, a replenishment order proposal item business documentobject reference package containing information characterizing businessdocuments relating to a replenishment order, and a schedule linepackage. The replenishment order proposal item location package cancontain one or both of a ship from location entity characterizing alocation from which products listed in a replenishment order proposalare to be delivered, and a ship to location entity characterizing alocation from which products listed in a replenishment order proposalare to be delivered. The schedule line package can contain one or bothof a schedule line entity characterizing quantity and schedulingassociated with a replenishment order proposal, and a confirmed scheduleline entity characterizing a confirmation of quantity and schedulingassociated with a replenishment order proposal.

Generating a notification associated with a return delivery isaccomplished by using a first application executing in a landscape ofcomputer systems providing message-based services to generate anelectronic message and initiating transmission of the message to asecond application to generate a notification associated with a returndelivery. The generated message includes a return delivery instructionpackage. The included return delivery instruction package furthercontains a return delivery instruction entity characterizing logisticalinstructions to a vendor for a future return delivery and a returndelivery instruction item package containing a product informationpackage containing information characterizing.

The return delivery instruction package can further include a partypackage and a location package. A party package can contain a buyerparty entity characterizing a party that has purchased goods beingreturned or has reordered a repurchase of goods. A party package canalso contain a vendor entity characterizing a party that sends backsgoods to be returned. A party package can further contain a productrecipient entity characterizing a company to which goods are returned.In addition, a location package can contains a ship to entitycharacterizing a location from which goods for return are sent back anda ship to location characterizing a location to which goods for returnare sent back.

The return delivery instruction package can further include a returndelivery item package and a delivery handling unit package. A returndelivery item package can contain a return delivery instruction itementity characterizing a quantity of product to be returned and anassociated delivery period. A return delivery item package can alsocontain a delivery item business transaction document reference packagecharacterizing business document references relevant to a product to bereturned A return delivery item package can also contain a party packagecontaining information characterizing business partners relevant to aproduct to be returned. A return delivery item package can furthercontain a batch package containing information characterizing a batch ofproduct to be returned. In addition, a delivery handling unit packagecontaining information characterizing handling requirements for aproduct to be returned.

Generating a notification associated with a return delivery can beaccomplished by receiving an electronic message in a landscape ofcomputer systems providing message-based services and initiating ageneration of a notification associated with a return delivery. Themessage includes a return delivery instruction package. The returndelivery instruction package further includes a return deliveryinstruction entity characterizing logistical instructions to a vendorfor a future return delivery, and a return delivery instruction itempackage containing a product information package containing informationcharacterizing.

Exchanging information associated with a request for quotation isaccomplished by using a first application executing in a landscape ofcomputer systems providing message-based services to generate anelectronic message and initiate transmission of the message to a secondapplication.

Exchanging information associated with a request for quotation isaccomplished by receiving an electronic message in a landscape ofcomputer systems providing message-based services and initiating anexchange of information associated with a request for quotation.

The generated and received message includes a package that containsvarious other packages that contain information associated with arequest for quotation. The package contains a party package, a locationpackage, a delivery information package, a payment information package,a product information package, a business transaction document referencepackage, a follow up business transaction document reference package, anattachment package, a description package, and an item package.

Each of the information containing packages contain differentinformation associated with a request for quotation. A party packagecontains information characterizing parties associated with a requestfor quotation. A location package contains information characterizinglocations associated with a request for quotation. A deliveryinformation package contains information characterizing a requireddelivery associated with a request for quotation. A payment informationpackage contains information characterizing payment informationassociated with a request for quotation. A product information packagecontains information characterizing a product category associated with arequest for quotation. A business transaction document reference packagecontains information characterizing business document referencesassociated with a request for quotation. A follow up businesstransaction document reference package contains informationcharacterizing business transaction documents expected by a buying partyassociated with a request for quotation. An attachment package containsinformation characterizing documents referring to a request forquotation. A description package contains information characterizingtext visible to parties to a request for quotation.

An item package also contains various information containing packagesincluding a product information package, a party package, a deliveryinformation package, a business transaction document reference package,an attachment package, a description package, and a schedule linepackage. A product information package contains informationcharacterizing a product tendered by a request for quotation. A partypackage contains information characterizing parties associated with arequest for quotation. A delivery information package containsinformation characterizing delivery of a product. A business transactiondocument reference package contains information characterizing arequired delivery associated with a request for quotation. An attachmentpackage contains information characterizing documents referring to arequest for quotation. A description package contains informationcharacterizing text visible to parties to a request for quotation. Aschedule line package contains information characterizing quantity anddate information associated with a request for quotation.

The information contained in the various packages is selected from agroup including a request from a buyer to a bidder to start a requestfor quotation process, a request from a buyer to a bidder to modify arequest for quotation during a request for quotation process, acancellation of a request for quotation, a notification from a bidder toa buyer containing a response by the bidder to an invitation to respondto a request for quotation, a notification of an acceptance of a bid inresponse to a request for quotation, a notification of a declination ofa bid in response to a request for quotation, a confirmation from abidder to a buyer indicating that the bidder intends to submit a bid inresponse to a request for quotation, a confirmation from a bidder to abuyer indicating an acceptance or rejection of a quotation accepted bythe buyer, a request to generate a legal text document in response to aninvitation to bid for quotation, and a notification of a generation of alegal text document in response to an invitation to bid on a request forquotation.

Exchanging information associated with services that have been enteredcan be accomplished by using a first application executing in alandscape of computer systems providing message-based services togenerate an electronic message and initiate transmission of the messageto a second application. The generated message includes a serviceacknowledgement package. The service acknowledgement package contains aservice acknowledgement entity characterizing information about aconfirmation by a purchase of an entered service and a party package.The party package further contains a buyer party entity characterizing aparty that purchases goods or services.

The party package can further contain a seller party entitycharacterizing a party selling goods or services. The party package canalso contain a product recipient party entity characterizing a party towhich goods are delivered or for whom services are provided. The partypackage can also contain vendor party entity characterizing a party thatdelivers goods or provides services. The party package can furthercontain a manufacturer party entity characterizing a party thatmanufactures goods.

The service acknowledgement package can further contain a locationpackage containing information characterizing a location at whichproducts have been delivered or a service provided. The serviceacknowledgement package can also contain an attachment packagecontaining information characterizing a document referring to a serviceacknowledgement. The service acknowledgement package can also contain adescription package containing information characterizing text regardinga service acknowledgement. Also, the service acknowledgement package canfurther contain an item package. The item package can contain an itementity characterizing an entered service or service product. The itempackage can also contain a hierarchy relationship entity characterizinga relationship between items in a hierarchy and a product informationpackage. The product information package can contain a product entitycharacterizing a product, and a product category entity characterizing acategory for a product. The service acknowledgement package can alsocontain a price information package containing informationcharacterizing price information for a service acknowledgement item. Theservice acknowledgement package can also contain a party packagecontaining information characterizing parties associated with a serviceacknowledgement. The service acknowledgement package can also contain alocation package containing information characterizing a location atwhich a products have been delivered or services provided.

The service acknowledgement package can also contain a business documentobject reference package. The business document object reference packagecan contain a purchase order reference entity characterizing a purchaseorder or an item within a purchase order. The business document objectreference package can also contain a service acknowledgement referenceentity characterizing a previously sent service acknowledgement. Thebusiness document object reference package can also contain a purchasecontract reference entity characterizing a reference to a purchasecontract or an item within a purchase contract. The business documentobject reference package can also contain a sales contract referenceentity characterizing a reference to a sales contract or an item withina sales contract. The business document object reference package canalso contain a buyer product catalogue reference entity characterizing areference to a product catalogue of a buyer or an item within a productcatalogue of a buyer. The business document object reference package canfurther contain a seller product catalogue reference entitycharacterizing a reference to a product catalogue of a seller or an itemwithin a product catalogue of a seller. The service acknowledgementpackage can also contain an attachment package containing informationcharacterizing a document referring to a service acknowledgement, Theservice acknowledgement package can further contain a descriptionpackage containing information characterizing text regarding a serviceacknowledgement.

The business document object reference package can further contain aproject reference entity characterizing a reference to a project or anelement within a project. The business document object reference packagecan further contain a project element assignment entity characterizingan assignment of two elements within a project that is referenced by anitem of a service acknowledgment. In addition, the item package canfurther contain an accounting package containing informationcharacterizing account assignment information.

Exchanging information associated with services that have been enteredcan be accomplished by receiving an electronic message in a landscape ofcomputer systems providing message-based services and initiating anexchange of information associated with services that have been entered.The received message includes a service acknowledgement package. Theservice acknowledgement package includes a service acknowledgemententity characterizing information about a confirmation by a purchase ofan entered service. The service acknowledgement package further includesa party package, which contains a buyer party entity characterizing aparty that purchases goods or services.

An electronic message to request generation of a supply chain exceptionnotification can be generated by a first application that executes in alandscape of computer systems providing message-based services.Transmission of the message to a second application can be initiated inorder to generate a supply chain exception notification. Responding to arequest to generate the supply chain exception notification can includereceiving a message including a supply chain exception package andinitiating generation of the supply chain exception notification. Thesupply chain exception package can contain a supply chain exceptionreport entity, a business transaction document reference package, alocation package and a product information package. The supply chainexception report entity can characterize an exception that occurred in asupply chain. The business transaction document reference package cancontain a purchaser order entity that can characterize a reference to apurchase order or an item within a purchase order for which an exceptionin a supply chain has occurred. The location package can contain a shipfrom location that can characterize a location from which orderedproducts are delivered. A product information package can characterize aproduct associated with a supply chain exception.

In some variations, the message requesting generation of a supply chainexception notification can further include a party package containing abuyer party entity, a vendor party entity and a product recipiententity. The buyer party entity can characterize a buyer of goods orservices. The vendor party entity can characterize a vendor of goods orservices. The product recipient entity can characterize a recipient ofgoods or services. The business transaction document reference packagecan further contain a scheduling agreement reference entity, a salesorder reference entity, an inbound delivery reference entity and a batchpackage. The scheduling agreement reference entity can characterize areference to an item in a scheduling agreement. The sales orderreference entity can characterize a reference to a sales order or to anitem in a sales order. The inbound delivery reference entity cancharacterize an inbound delivery or an item of an inbound delivery. Thesupply chain exception package can further contain a batch package. Thebatch package can contain a batch entity, a property valuation packageand a log package. The batch entity can characterize a batch ofproducts. The property valuation package can characterize properties ofa characteristic of a supply chain exception. The log package cancontain a validation log entity that can characterize a logisticsplanning or logistics execution check log. The log package can alsocontain an item entity. The location package can further contain a shipto location entity that can characterize a location where orderedproducts are delivered.

An electronic message to generate a tax declaration can be generated bya first application that executes in a landscape of computer systemsproviding message-based services. Transmission of the message to asecond application can be initiated in order to provide tax declarationinformation to generate a tax declaration based on a purchase.Responding to a request to generate a tax declaration can includereceiving a message including a tax declaration package and initiating ageneration of a tax declaration. A tax declaration package can contain alog package and a party package, where the log package can contain avalidation log entity characterizing log messages from a tax authorityassociated with a receipt and validation of a tax return based on apurchase, and the party package can contain a tax payer party entitythat characterizes a party liable for tax on a purchase. The partypackage can also contain a tax authority party entity that characterizesa tax authority that receives a tax declaration. In some variations, alog package can also contain an item entity. The item entity cancharacterize a log of a receipt and validation of a tax refund based ona purchase. The party package can also contain a tax operator entitythat characterizes a party that creates and sends a tax return for taxon purchases. A declaration package can also contain an item packagethat characterizes reported taxes on purchases.

An electronic message to create information associated with a vendorinitiated purchase order can be generated by a first application thatexecutes in a landscape of computer systems providing message-basedservices. Transmission of the message to a second application can beinitiated in order to generate information associated with a vendorinitiated purchase order.

The message can include a vendor generated order package containing avendor generated order entity characterizing a purchaser order that isinitiated by a vendor for a customer, a party package, a locationpackage, and a vendor generated order item package. The party packagecan contain a buyer party entity characterizing a party to receive agoods replenishment delivery, and a vendor party entity characterizing aparty to provide a goods replenishment delivery. The location packagecan contain a ship from location entity characterizing a location fromwhich goods associated with a purchase order is to be delivered, and aship to location entity characterizing a location at which goodsassociated with a purchase order is to be delivered. The vendorgenerated order item package can contain a vendor generated order itementity characterizing quantities of goods and associated delivery andlocation conditions for goods in a purchase order, and a productinformation package containing information characterizing goodsassociated with a purchase order. The location package can furthercontain a trans-shipment location entity characterizing a location atwhich delivery of products using a first transport mechanism changes tosecond transport mechanism. The vendor generated order package can alsocontain a handling unit containing information characterizing packingrequirements for goods associated with a replenishment order.

The vendor generated order item package can further contain one or moreof a business transaction document reference package, a promotionpackage containing information characterizing marketing promotionsrelevant to goods associated with a purchase order, and a schedule linepackage. The business transaction document reference package can containone or both of a purchasing contract reference entity characterizing apurchase contract or an item in a purchase contract and a sales orderreference entity characterizing a sales order or an item in a salesorder. The schedule line package can contain one or more of a scheduleline entity characterizing quantity and scheduling dates forreplenishment deliveries of goods associated with a purchase order, anda confirmed schedule line entity characterizing confirmed quantity andscheduling dates for replenishment deliveries of goods associated with apurchase order.

Adapters and other proxies can be utilized such that messages or otherdata structures that are not in a format compatible with the generatedand received messages can be utilized in connection with the subjectmatter described herein. For example, generating the message can includeconverting or mapping a non-compatible message format or other datastructure into a compatible message type prior to its transmission.Similarly, a received message can be subsequently converted or mappedinto a non-compatible message format or other data structure to effectthe actions specified by the received message.

Other systems, methods, features and advantages of the subject matterdescribed herein will be or will become apparent to one with skill inthe art upon examination of the following figures and detaileddescription. It is intended that such additional systems, methods,features and advantages be included within this description, be withinthe scope of the subject matter described herein, and be protected bythe accompanying claims.

V. BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate an implementation of the subjectmatter described herein and, together with the description, serve toexplain the advantages and principles of the subject matter describedherein. In the drawings,

FIGS. 1A-1F depict problems that may arise without the use of consistentinterfaces;

FIG. 1 depicts a flow diagram of the overall steps performed by methodsand systems consistent with the subject matter described herein;

FIG. 2 depicts a scenario variant model in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 3 depicts a process interaction model for invoice processing inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 4 depicts a business document flow for an invoice request inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 5 depicts data processing systems suitable for practicing methodsand systems consistent with the subject matter described herein;

FIG. 6 depicts message categories in accordance with methods and systemsconsistent with the subject matter described herein;

FIG. 7 depicts a message choreography for a purchase order scenario inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 8 depicts a message choreography of a Master Data Management inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 9 depicts a message choreography of a Source of Supply, PurchaseRequirement, and Purchase Order in accordance with methods and systemsconsistent with the subject matter described herein;

FIG. 10 depicts a message choreography of a Product Demand, ProductForecast and Product Activity in accordance with methods and systemsconsistent with the subject matter described herein;

FIG. 11 depicts a message choreography of a RFQ and Quote in accordancewith methods and systems consistent with the subject matter describedherein;

FIG. 12 depicts a message choreography of Purchasing in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 13 depicts a message choreography of Sales in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 14 depicts a message choreography of a Vendor ManagedInventory/Responsive Replenishment in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 15 depicts a message choreography of an Advanced ShipmentNotification and Proof of Delivery in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 16 depicts a message choreography of a Service Acknowledgement inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 17 depicts a message choreography of an Inventory Change inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 18 depicts a message choreography of Billing Due in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 19 depicts a message choreography of Invoicing Due in accordancewith methods and systems consistent with the subject matter describedherein;

FIG. 20 depicts a message choreography of an Invoice in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 21 depicts a message choreography of Invoice Accounting and PaymentDue in accordance with methods and systems consistent with the subjectmatter described herein;

FIG. 22 depicts a message choreography of Tax Due in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 23 depicts a message choreography of Credit Worthiness, CreditAgency Report, Credit Payment, and Credit Commitment in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 24 depicts a message choreography of a Personnel Time Sheet inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 25-251 depict data type structures in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 252 depicts an example of a package in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 253 depicts another example of a package in accordance with methodsand systems consistent with the subject matter described herein;

FIG. 254 depicts a third example of a package in accordance with methodsand systems consistent with the subject matter described herein;

FIG. 255 depicts a fourth example of a package in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 256 depicts the representation of a package in the XML schema inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 257 depicts a graphical representation of cardinalities between twoentities in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 258 depicts an example of a composition in accordance with methodsand systems consistent with the subject matter described herein;

FIG. 259 depicts an example of a hierarchical relationship in accordancewith methods and systems consistent with the subject matter describedherein;

FIG. 260 depicts an example of an aggregating relationship in accordancewith methods and systems consistent with the subject matter describedherein;

FIG. 261 depicts an example of an association in accordance with methodsand systems consistent with the subject matter described herein;

FIG. 262 depicts an example of a specialization in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 263 depicts the categories of specializations in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 264 depicts an example of a hierarchy in accordance with methodsand systems consistent with the subject matter described herein;

FIG. 265 depicts a graphical representation of a hierarchy in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 266A-B depict a flow diagram of the steps performed to create abusiness object model in accordance with methods and systems consistentwith the subject matter described herein;

FIGS. 267A-NN depict the business object model in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 268 depicts the message choreography for the Invoice interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 269A-F depict a flow diagram of the steps performed to generate aninterface from the business object model in accordance with methods andsystems consistent with the subject matter described herein;

FIGS. 270A-C depict examples of package templates in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 271 depicts the package template of FIG. 270A after the removal ofa package in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 272 depicts an entity template for the party package from thebusiness object model in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 273 depicts the entity template for the party package of FIG. 272after removal of an entity in accordance with methods and systemsconsistent with the subject matter described herein;

FIG. 274 depicts the party package of FIG. 272 after removal of thenonessential entities for the Invoice Request in accordance with methodsand systems consistent with the subject matter described herein;

FIG. 275 depicts a portion of the business object model in accordancewith methods and systems consistent with the subject matter describedherein;

FIG. 276 depicts a further portion of the business object model inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 277 depicts the package template of FIG. 270A after the removal ofthe nonessential packages for the Invoice Request in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 278 depicts package template of FIG. 277 after the “businesstransaction document” is changed in accordance with methods and systemsconsistent with the subject matter described herein;

FIGS. 279A-N depict a data model for Invoice interfaces in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 280A-K depict an element structure for Invoice interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 281 depicts an example illustrating the transmittal of a businessdocument in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 282 depicts an interface proxy in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 283 depicts an example illustrating the transmittal of a messageusing proxies in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 284 depicts components of a message in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 285 depicts IDs used in a message in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 286 depicts a reference to previous messages in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 287 depicts a reference to business documents from previoustransactions in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 288 depicts a message choreography for Purchase Requirementinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 289A-H depict a data model for Purchase Requirement interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 290A-G depict an element structure for Purchase Requirementinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 291 depicts message choreography for a Source of Supply interfacein accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 292A-C depict a data model for the Source of Supply interface inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 293A-D depict an element structure for the Source of Supplyinterface in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 294 depicts a message choreography for Purchase Order interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 295A-P depict the data model for the Purchase Order interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 296 depicts a data mode for the Purchase Order Cancellationinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 297A-ZA depict an element structure for the Purchase Orderinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 298 depicts a message choreography for Service Acknowledgementinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 299A-J depict a data model for the Service Acknowledgementinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 300A-L depict an element structure for the Service Acknowledgementinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 301 depicts a message choreography for RFQ interfaces in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 302A-K depict a data model for the RFQ interfaces in accordancewith methods and systems consistent with the subject matter describedherein;

FIG. 303 depicts a data model for RFQ Cancellation interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 304A-J depict a data model for Quote interfaces in accordance withmethods and systems consistent with the subject matter described herein;

FIGS. 305A-D depict a data model for RFQ Result interfaces in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 306A-O depict an element structure for RFQ interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 307A-C depict an element structure for RFQ Cancellation interfacesin accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 308A-M depict an element structure for Quote interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 309A-D depict an element structure for RFQ Request interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 310 depicts a message choreography for Order to Invoice inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 311 depicts a message choreography for the Order to Invoiceprovided by RosettaNet;

FIG. 312 depicts a message choreography for the Order to Invoiceprovided by CIDX;

FIGS. 313-317 depict a hierarchization process in accordance withmethods and systems consistent with the subject matter described herein;

FIGS. 318-358QG depict additional data type structures in accordancewith methods and systems consistent with the subject matter describedherein;

FIG. 359 depicts a message choreography for the Catalogue interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 360A-F depict a data model for Catalogue Update Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 361A-AA depict an element structure for the Catalogue UpdateMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 362A-F depict a data model for Catalogue Publication Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 363A-Z depict an element structure for Catalogue PublicationMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 364 depicts a data model for Catalogue Publication TransmissionPackage Message in accordance with methods and systems consistent withthe subject matter described herein;

FIGS. 365A-B depict an element structure for the Catalogue PublicationTransmission Package Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIG. 366 depicts a data model for Catalogue Publication ConfirmationMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 367A-B depict an element structure for the Catalogue PublicationConfirmation Message in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 368 depicts a data model for Catalogue Publication TransmissionCancellation Request Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIGS. 369A-B depict an element structure for Catalogue PublicationTransmission Cancellation Request Message in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 370 depicts a data model for Catalogue Publication TransmissionCancellation Confirmation Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIGS. 371A-B depict an element structure for the Catalogue PublicationTransmission Cancellation Confirmation Message in accordance withmethods and systems consistent with the subject matter described herein;

FIG. 372 depicts a data model for Catalogue Publication TransmissionItem Lock Request Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIGS. 373A-C depict an element structure for the Catalogue PublicationTransmission Item Lock Request Message in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 374 depicts a data model for Catalogue Publication TransmissionItem Lock Confirmation Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIGS. 375A-B depict an element structure for Catalogue PublicationTransmission Item Lock Confirmation Message in accordance with methodsand systems consistent with the subject matter described herein;

FIGS. 375AA-AB depict a data model for Catalogue PublicationTransmission Content Change Request Message in accordance with methodsand systems consistent with the subject matter described herein;

FIG. 375BA depicts a data model for Catalogue Publication TransmissionContent Change Confirmation Message in accordance with methods andsystems consistent with the subject matter described herein;

FIG. 375BB depicts an illustration of a Catalog Content Managementsystem in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 376 depicts a message choreography for the Purchase OrderInformation interfaces in accordance with methods and systems consistentwith the subject matter described herein;

FIGS. 377A-N depict a data model for Purchase Order Information Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 378A-ZA depict an element structure for the Purchase OrderInformation Message in accordance with methods and systems consistentwith the subject matter described herein;

FIGS. 378AA-S depict an element structure for Purchase Order InformationLegal Document Message in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 379 depicts a message choreography for Tax Due interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 380A-C depict a data model for Tax Due Message in accordance withmethods and systems consistent with the subject matter described herein;

FIGS. 381A-D depict an element structure for the Tax Due Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 382 depicts a message choreography for Delivery Informationinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 383A-H depict a data model for Delivery Information Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 384A-J depict an element structure for the Delivery InformationMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 385 depicts a message choreography for Personnel TimesheetInformation interfaces in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 386 depicts a data model for Personnel Timesheet Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 387A-C depict an element structure for Personnel Timesheet Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIG. 388 depicts a message choreography for Credit Worthiness interfacesin accordance with methods and systems consistent with the subjectmatter described herein;

FIG. 389 depicts a data model for Credit Worthiness Query Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 390 depicts a data model for Credit Worthiness Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 391A-B depict an element structure for the Credit Worthiness QueryMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 392A-C depict an element structure for the Credit WorthinessMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 393 depicts a message choreography for Credit Agency Reportinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 394 depicts a data model for Credit Agency Report Query Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 395A-B depict a data model for Credit Agency Report Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 396A-C depict an element structure for the Credit Agency ReportQuery Message in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 397A-E depict an element structure for the Credit Agency ReportMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 398 depicts a message choreography for Invoicing Accountinginterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 399 depicts a data model for Accounting Cancellation Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 400A-B depict an element structure for Accounting CancellationMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 401 depicts a message choreography for Invoice Due interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 402A-M depict a data model for Invoice Due Message in accordancewith methods and systems consistent with the subject matter describedherein;

FIG. 403 depicts a data model for Invoice Due Cancellation Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 404A-J depict an element structure for the Invoice Due Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 405 depicts a message choreography for Inventory Change interfacesin accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 406A-B depict a data model for Inventory Change Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 407A-D depict an element structure for the Inventory ChangeMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 408 depicts a message choreography for Sales Order Fulfillmentinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 409A-L depict a data model for Sales Order Fulfillment Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 410A-M depict an element structure for Sales Order FulfillmentMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 411 depicts a message choreography for Delivery interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 412A-C depict a data model for Despatched Delivery NotificationMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 413 depicts a data model for Received Delivery Notification Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 414A-G depict an element structure for Despatched DeliveryNotification Message in accordance with methods and systems consistentwith the subject matter described herein;

FIGS. 415A-C depict an element structure for Received DeliveryNotification Message in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 416 depicts a message choreography for Invoice Accountinginterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 417A-C depict a data model for Invoice Accounting Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 418A-E depict an element structure for Invoice Accounting Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIG. 419 depicts a message choreography for Delivery Execution Requestinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 420A-L depict a data model for Delivery Execution Request Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 421A-K depict an element structure for the Delivery ExecutionRequest Message in accordance with methods and systems consistent withthe subject matter described herein;

FIG. 422 depicts a message choreography for Delivery Schedule interfacesin accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 423A-C depict a data model for Delivery Schedule Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 424A-V depict an element structure for the Delivery ScheduleMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 424AA-AU depict an element structure for the Delivery ScheduleNotification Message in accordance with methods and systems consistentwith the subject matter described herein;

FIGS. 424BA-BJ depict an element structure for the Delivery ScheduleConfirmation Message in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 425 depicts a message choreography for Invoice Issued Informationinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 426 depicts a data model for Invoice Issued Message in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 427A-B depict an element structure for the Invoice Issued Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIG. 428 depicts a message choreography for Product Activity interfacesin accordance with methods and systems consistent with the subjectmatter described herein;

FIG. 429 depicts a data model for Product Activity Message in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 430A-L depict an element structure for the Product ActivityMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 431 depicts a message choreography for Payment Due invoices inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 432A-C depict a data model for Payment Due Message in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 433A-D depict an element structure for Payment Due Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 434 depicts a message choreography for Order ID Assignmentinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 435 depicts a data model for Order ID Assignment Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 436A-E depict an element structure for the Order ID AssignmentMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 437 depicts a message choreography for Product Demand InfluencingEvent interfaces in accordance with methods and systems consistent withthe subject matter described herein;

FIG. 438 depicts a data model for ProductDemand Influencing EventMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 439A-L depict an element structure for the ProductDemandInfluencing Event Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIG. 440 depicts a message choreography for Product Forecast interfacesin accordance with methods and systems consistent with the subjectmatter described herein;

FIG. 441 depicts a data model for Product Forecast Notification Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 442A-J depict an element structure for the Product ForecastNotification Message in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 443 depicts a message choreography for Product Forecast Revisioninterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 444 depicts a data model for Product Forecast Revision Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 445A-M depict an element structure for the Product ForecastRevision Message in accordance with methods and systems consistent withthe subject matter described herein;

FIG. 446 depicts a message choreography for Replenishment Orderinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 447A-F depict the data model for Replenishment Order Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 448A-W depict an element structure for the Replenishment OrderMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 449 depicts a message choreography for Vendor Generated Orderinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 450A-B depict the data model for the Vendor Generated OrderMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 451A-O depict an element structure for the Vendor Generated OrderMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 452 depicts a message choreography for Bank Account Balanceinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 453 depicts a data model for Bank Account Balance Report QueryMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 454 depicts a data model for Bank Account Balance Report ResponseMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 455A-B depict an element structure for the Bank Account BalanceReport Response Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIGS. 456A-B depict an element structure for the Bank Account BalanceReport Query Message in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 457 depicts a message choreography for Bank Account Statementinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 458A-E depict the data model for Bank Account Statement Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 459A-I depict an element structure for the Bank Account StatementMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 460 depicts a message choreography for Business TransactionDocument Image Recognition Request interfaces in accordance with methodsand systems consistent with the subject matter described herein;

FIG. 461 depicts a data model for Business Transaction Document ImageRecognition Request in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 462 depicts an element structure for the Business TransactionDocument Image Recognition Request Message in accordance with methodsand systems consistent with the subject matter described herein;

FIG. 463 depicts a message choreography for Collective Payment Orderinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 464A-F depict the data model for Collective Payment Order inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 465A-F depict an element structure for the Collective PaymentOrder Message in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 466 depicts a message choreography for Credit Payment BehaviorSummary interfaces in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 467 depicts a data model for Credit Payment Behavior SummaryMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 468A-H depict an element structure for the Credit PaymentBehaviour Summary Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIG. 469 depicts a message choreography for Customs Vendor Declarationinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 470 depicts a data model for the Customs Vendor Declaration Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 471A-G depict an element structure for the Customs VendorDeclaration Message in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 472 depicts a message choreography for Invoice interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 473A-D depict the data model for Supplier Invoice InformationMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 474 depicts a data model for Supplier Invoice Settlement ReleaseRequest Message in accordance with methods and systems consistent withthe subject matter described herein;

FIG. 475 depicts a data model for Supplier Invoice CancellationExecution Request Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIGS. 476A-D depict the data model for Invoice Message in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 477A-J depict an element structure for the Invoice Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 478 depicts a message choreography for Loan Contract interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 479 depicts a data model for Loan Calculation Query Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 480 depicts a data model for Loan Calculation Message in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 481A-C depict the data model for the Loan Contract in accordancewith methods and systems consistent with the subject matter describedherein;

FIG. 482 depicts a data model for Loan Contract Create ConfirmationMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 483A-E depicts an element structure for Loan Contract CreateRequest Message in accordance with methods and systems consistent withthe subject matter described herein;

FIGS. 484A-B depicts an element structure for the Loan CalculationMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 485A depicts an element structure for the Loan Contract CreateConfirmation Message in accordance with methods and systems consistentwith the subject matter described herein;

FIGS. 486A-B depict an element structure for the Loan Calculation QueryMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 487 depicts a message choreography for Purchase Request interfacesin accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 488A-D depict the data model for Purchase Request Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 489 depicts a data model for Purchase Request Confirmation Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 490A-J depict an element structure for the Purchase RequestMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 491A-B depict an element structure for the Purchase RequestConfirmation Message in accordance with methods and systems consistentwith the subject matter described herein;

FIG. 492 depicts a message choreography for Purchasing Contractinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 493A-D depict the data model for the Purchasing Contract UseMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 494 depicts a data model for the Purchasing Contract ReleaseMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 495A-D depict an element structure for the Purchasing ContractRelease Message in accordance with methods and systems consistent withthe subject matter described herein;

FIGS. 496A-J depict an element structure for the Purchasing ContractMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 497 depicts a message choreography for Replenishment Order Proposalinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 498A-C depict the data model for Replenishment Order ProposalMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 499A-I depict an element structure for the Replenishment OrderProposal Request Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIGS. 499AA-AM depict an element structure for the Replenishment OrderProposal Confirmation Message in accordance with methods and systemsconsistent with the subject matter described herein;

FIG. 500 depicts a message choreography for Return Delivery Instructioninterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 501A-C depict the data model for the Return Delivery InstructionMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 502A-L depict an element structure for the Return DeliveryInstruction Notification in accordance with methods and systemsconsistent with the subject matter described herein;

FIG. 503 depicts a message choreography for RFQ Legal Documentinterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 504A-L depict the data model for the RFQ Legal Document Message inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIGS. 505A-M depict an element structure for the RFQ Legal DocumentMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIG. 506 depicts a message choreography for Supply Chain Exceptioninterfaces in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 507A-C depict the data model for Supply Chain Exception ReportMessage in accordance with methods and systems consistent with thesubject matter described herein;

FIGS. 508A-P depict an element structure for the Supply Chain ExceptionReport Message in accordance with methods and systems consistent withthe subject matter described herein;

FIG. 509 depicts a message choreography for VATDeclaration interfaces inaccordance with methods and systems consistent with the subject matterdescribed herein;

FIG. 510 depicts a data model for VATDeclaration Message in accordancewith methods and systems consistent with the subject matter describedherein;

FIGS. 511A-F depict an element structure for the VATDeclaration Messagein accordance with methods and systems consistent with the subjectmatter described herein;

FIGS. 512A-E depict an element structure for the VATDeclaration RequestMessage in accordance with methods and systems consistent with thesubject matter described herein; and,

FIGS. 513A-D depict an element structure for the VATDeclarationConfirmation Message in accordance with methods and systems consistentwith the subject matter described herein.

VI. DETAILED DESCRIPTION

Reference will now be made in detail to an implementation consistentwith the subject matter described herein as illustrated in theaccompanying drawings. Wherever possible, the same reference numberswill be used throughout the drawings and the following description torefer to the same or like parts.

A. Overview

Methods and systems consistent with the subject matter described hereinfacilitate e-commerce by providing consistent interfaces that aresuitable for use across industries, across businesses, and acrossdifferent departments within a business during a business transaction.To generate consistent interfaces, methods and systems consistent withthe subject matter described herein utilize a business object model,which reflects the data that will be used during a given businesstransaction. An example of a business transaction is the exchange ofpurchase orders and order confirmations between a buyer and a seller.The business object model is generated in a hierarchical manner toensure that the same type of data is represented the same way throughoutthe business object model. This ensures the consistency of theinformation in the business object model. Consistency is also reflectedin the semantic meaning of the various structural elements. That is,each structural element has a consistent business meaning. For example,the location entity, regardless of in which package it is located,refers to a location.

From this business object model, various interfaces are derived toaccomplish the functionality of the business transaction. Interfacesprovide an entry point for components to access the functionality of anapplication. For example, the interface for a Purchase Order Requestprovides an entry point for components to access the functionality of aPurchase Order, in particular, to transmit and/or receive a PurchaseOrder Request. One skilled in the art will recognize that each of theseinterfaces may be provided, sold, distributed, utilized, or marketed asa separate product or as a major component of a separate product.Alternatively, a group of related interfaces may be provided, sold,distributed, utilized, or marketed as a product or as a major componentof a separate product. Because the interfaces are generated from thebusiness object model, the information in the interfaces is consistent,and the interfaces are consistent among the business entities. Suchconsistency facilitates heterogeneous business entities in cooperatingto accomplish the business transaction.

Without cross-component consistency, different conceptual approacheslead to different interface structures, resulting in incompatibleinterfaces. For example, FIGS. 1A-C depict three different approaches toa transport condition 102 a, 102 b, 102 c, which specifies how productsare to be transported. The transport condition 102 a, 102 b, 102 c,considers a business partner 104 a, 104 b, 104 c, a product 106 a, 106b, 106 c, and a combination of the business partner and the product 108a, 108 b, 108 c.

As depicted in FIG. 1A, the transport condition 102 a may depend on thebusiness partner 104 a. Alternatively, as depicted in FIG. 1B, thetransport condition 102 b may depend on the product 106 b. As a thirdalternative, the transport condition 102 c may depend on the combinationof the business partner and the product 108 c. These three conceptualmodels represent three different object models that may be used toderive interfaces.

FIGS. 1D-F depict the resulting consistent interfaces from these objectmodels. In particular, FIG. 1D depicts an interface for quotations 102d, an interface for purchase orders 104 d and an interface for goodsissued 106 d derived using the conceptual model depicted in FIG. 1A.FIG. 1E depicts these same respective interfaces 102 e, 104 e, 106 ederived using the conceptual model depicted in FIG. 1B. FIG. 1F depictsthese same respective interfaces 102 f, 104 f, 106 f derived using theconceptual model depicted in FIG. 1C. As depicted in FIG. 1G,inconsistent interfaces 102 g, 104 g, 106 g result without across-component understanding of a transport condition.

FIG. 1 depicts a flow diagram of the overall steps performed by methodsand systems consistent with the subject matter described herein.Initially, to generate the business object model, design engineers studythe details of a business process, and model the business process usinga “business scenario” (step 100). The business scenario identifies thesteps performed by the different business entities during a businessprocess. Thus, the business scenario is a complete representation of aclearly defined business process. For example, in FIG. 2, a scenariovariant model is used to depict an illustrative business scenario for aMaintenance Repair Operation (“MRO”) Procurement 200. The developers usethese scenario variant models to depict the individual process stepsperformed by the business entities during the business process.

For an MRO Procurement, the customer initially processes an internalrequest (step 202). The internal request corresponds to the customer'sinternal documentation for the requested maintenance or repair. Thecustomer then processes a purchase request (step 204). The purchaserequest corresponds to the customer's internal documentation for aspecific product or service related to the maintenance or repair. Next,the customer processes a purchase order (step 206), which is sent to thesupplier. This prompts the supplier to process a sales order (step 208).The sales order is the supplier's internal documentation regarding therequested product or service. After processing the sales order, thesupplier processes an outbound delivery (step 210), which is thesupplier's internal documentation identifying the products or servicesthat will be provided to the customer. The supplier then sends a goodsand services confirmation to the customer (step 212). Next, the supplierprocesses a customer invoice (step 214) and sends the invoice to thecustomer. Upon receiving the invoice, the customer processes thesupplier invoice (step 216). The customer also processes a due item(step 218). The due item summarizes the information regarding theproduct or service ordered by the customer. Next, the customer processesthe payment (step 220) by sending the payment information to thebusiness partner and sending the payment information to the house bank.After receiving the payment information, the business partner processesthe payment (step 222), and the bank processes the payment (step 224).The bank also creates a bank statement (step 226) and forwards the bankstatement information to the customer. During the MRO Procurement, thecustomer also processes an accounting document (step 228). Theaccounting document is the customer's internal documentation regardingthe payment to the supplier.

Returning to the overall process in FIG. 1, after creating the businessscenario, the developers add details to each step of the businessscenario (step 102). In particular, for each step of the businessscenario, the developers identify the complete process steps performedby each business entity. A discrete portion of the business scenarioreflects a “business transaction,” and each business entity is referredto as a “component” of the business transaction. The developers alsoidentify the messages that are transmitted between the components. A“process interaction model” represents the complete process stepsbetween two components. For example, FIG. 3 depicts the processinteraction model for the invoice processing 230 between the supplier300, which processes the customer invoice, and the customer 302, whichprocesses the supplier invoice.

The supplier uses an Invoice Request Out interface 304 to send anInvoice Request message 306 to the customer. The customer uses theInvoice Request In interface 308 to receive the Invoice Request message(step 310), and to create an internal instantiation of the supplierinvoice 312. The customer processes the supplier invoice (step 314), anduses an Invoice Confirmation Out interface 316 to send an InvoiceConfirmation 318 to the supplier. The supplier uses an InvoiceConfirmation In interface 320 to receive the Invoice Confirmation 318.

Returning to FIG. 1, after creating the process interaction model, thedevelopers create a “message choreography” (step 104), which depicts themessages transmitted between the two components in the processinteraction model. The developers then represent the transmission of themessages between the components during a business process in a “businessdocument flow” (step 106). Thus, the business document flow illustratesthe flow of information between the business entities during a businessprocess.

FIG. 4 depicts an exemplary business document flow 400 for the processof purchasing a product or service. The business entities involved withthe illustrative purchase process include Accounting 402, Payment 404,Invoicing 406, Supply Chain Execution (“SCE”) 408, Supply Chain Planning(“SCP”) 410, Fulfillment Coordination (“FC”) 412, Supply RelationshipManagement (“SRM”) 414, Supplier 416, and Bank 418. The businessdocument flow 400 is divided into four different transactions:Preparation of Ordering (“Contract”) 420, Ordering 422, Goods Receiving(“Delivery”) 424, and Billing/Payment 426. In the business documentflow, arrows 428 represent the transmittal of documents. Each documentreflects a message transmitted between entities. One of ordinary skillin the art will appreciate that the messages transferred may beconsidered to be a communications protocol. The process flow follows thefocus of control, which is depicted as a solid vertical line (e.g., 429)when the step is required, and a dotted vertical line (e.g., 430) whenthe step is optional.

During the Contract transaction 420, the SRM 414 sends a Source ofSupply Notification 432 to the SCP 410. This step is optional, asillustrated by the optional control line 430 coupling this step to theremainder of the business document flow 400.

During the Ordering transaction 422, the SCP 410 sends a PurchaseRequirement Request 434 to the FC 412, which forwards a PurchaseRequirement Request 436 to the SRM 414. The SRM 414 then sends aPurchase Requirement Confirmation 438 to the FC 412, and the FC 412sends a Purchase Requirement Confirmation 440 to the SCP 410. The SRM414 also sends a Purchase Order Request 442 to the Supplier 416, andsends Purchase Order Information 444 to the FC 412. The FC 412 thensends a Purchase Order Planning Notification 446 to the SCP 410. TheSupplier 416, after receiving the Purchase Order Request 442, sends aPurchase Order Confirmation 448 to the SRM 414, which sends a PurchaseOrder Information confirmation message 454 to the FC 412, which sends amessage 456 confirming the Purchase Order Planning Notification to theSCP 410. The SRM 414 then sends an Invoice Due Notification 458 toInvoicing 406.

During the Delivery transaction 424, the FC 412 sends a DeliveryExecution Request 460 to the SCE 408. The Supplier 416 could optionally450 send a Despatched Delivery Notification 452 to the SCE 408. The SCE408 then sends a message 462 to the FC 412 notifying the FC 412 that therequest for the Delivery Information was created. The FC 412 then sendsa message 464 notifying the SRM 414 that the request for the DeliveryInformation was created. The FC 412 also sends a message 466 notifyingthe SCP 410 that the request for the Delivery Information was created.The SCE 408 sends a message 468 to the FC 412 when the goods have beenset aside for delivery. The FC 412 sends a message 470 to the SRM 414when the goods have been set aside for delivery. The FC 412 also sends amessage 472 to the SCP 410 when the goods have been set aside fordelivery.

The SCE 408 sends a message 474 to the FC 412 when the goods have beendelivered. The FC 412 then sends a message 476 to the SRM 414 indicatingthat the goods have been delivered, and sends a message 478 to the SCP410 indicating that the goods have been delivered. The SCE 408 thensends an Inventory Change Accounting Notification 480 to Accounting 402,and an Inventory Change Notification 482 to the SCP 410. The FC 412sends an Invoice Due Notification 484 to Invoicing 406, and SCE 408sends a Received Delivery Notification 486 to the Supplier 416.

During the Billing/Payment transaction 426, the Supplier 416 sends anInvoice Request 487 to Invoicing 406. Invoicing 406 then sends a PaymentDue Notification 488 to Payment 404, a Tax Due Notification 489 toPayment 404, an Invoice Confirmation 490 to the Supplier 416, and anInvoice Accounting Notification 491 to Accounting 402. Payment 404 sendsa Payment Request 492 to the Bank 418, and a Payment RequestedAccounting Notification 493 to Accounting 402. Bank 418 sends a BankStatement Information 496 to Payment 404. Payment 404 then sends aPayment Done Information 494 to Invoicing 406 and a Payment DoneAccounting Notification 495 to Accounting 402.

Within a business document flow, business documents having the same orsimilar structures are marked. For example, in the business documentflow 400 depicted in FIG. 4, Purchase Requirement Requests 434, 436 andPurchase Requirement Confirmations 438, 440 have the same structures.Thus, each of these business documents is marked with an “O6.”Similarly, Purchase Order Request 442 and Purchase Order Confirmation448 have the same structures. Thus, both documents are marked with an“O1.” Each business document or message is based on a message type. Themessage type is identified within the rectangle within each of thebusiness documents depicted in the business document flow. For example,Source of Supply Notification 432 is based on message type 77, asreflected by “MT 77.” A list of various message types with theircorresponding codes and a description of each message type is providedbelow. Code Name Description 0077 Source of Supply ASourceOfSupplyNotification is a notice to Supply Chain NotificationPlanning about available sources of supply. 0080 Catalogue Update ACatalogueUpdateNotification is a notice from a catalogue Notificationprovider to an interested party about a new catalogue transmitted in themessage or about changes to an existing catalogue transmitted in themessage. 0081 Catalogue Publication A CataloguePublicationRequest is arequest from catalogue Request authoring to the Catalogue Search Engine(the publishing system) to publish a new or changed catalogue or todelete an already published catalogue (the catalogue is possibly splitinto several transmission packages). 0082 CataloguePublication ACataloguePublicationTransmissionPackageNotification isTransmissionPackage the notification of the Catalogue Search Engine (theNotification publishing system) to Catalogue Authoring about a packageof a catalogue publication transmission and information about thereception of this package and the validity of its content. 0083CataloguePublication A CataloguePublicationConfirmation is theconfirmation of Confirmation the Catalogue Search Engine (the publishingsystem) to Catalogue Authoring whether the publication or deletion of acatalogue requested by a CataloguePublicationRequest was successful ornot. 0084 CataloguePublication ACataloguePublicationTransmissionCancellationRequest is Transmission therequest of Catalogue Authoring to Catalogue Search CancellationRequestEngine (the publishing system) to cancel the transmission of a catalogueand to restore an earlier published state (if such exists) of thecatalogue. Moreover, no more packages are sent for this transmission.0085 CataloguePublication ACataloguePublicationTransmissionCancellationConfirmationTransmissionCancellation is the confirmation of Catalogue Search Engine(the Confirmation publishing system) whether the transmission of acatalogue has been cancelled successfully and an earlier published stateof this catalogue (if such exists) has been restored or not. 0086CataloguePublication A CataloguePublicationTransmissionItemLockRequestis TransmissionItemLock the request of Catalogue Authoring to locksingle items of Request the catalogue contained in the cataloguepublication transmission. 0087 Catalogue Publication ACataloguePublicationTransmissionItemLockConfirmation Transmission ItemLock is the confirmation of Catalogue Search Engine (the Confirmationpublishing system) to Catalogue Authoring whether single items of thecatalogue contained in the catalogue publication transmission could belocked or not. To lock means that if the catalogue is not yet publishedthe items must not be published and if the catalogue is alreadypublished, the publication of these items must be revoked. 0101 PurchaseOrder Request A PurchaseOrderRequest is a request from a purchaser to aseller to deliver goods or provide services. 0102 Purchase Order ChangeA PurchaseOrderChangeRequest is a change to a Request purchaser'srequest to the seller to deliver goods or provide services. 0103Purchase Order A PurchaseOrderCancellationRequest is the cancellation ofCancellation Request a purchaser's request to the seller to delivergoods or provide services. 0104 Purchase Order APurchaseOrderConfirmation is a confirmation, partial Confirmationconfirmation, or change from a seller to the purchaser, regarding therequested delivery of goods or provision of services. 0120 PurchaseOrder A PurchaseOrderInformation is information from a Informationpurchasing system for interested recipients about the current state of apurchase order when creating or changing a purchase order, confirming apurchase order or canceling a purchase order. 0121 Purchase OrderPlanning A PurchaseOrderPlanningNotification is a message byNotification means of which planning applications are notified aboutthose aspects of a purchase order that are relevant for planning. 0130Purchase Requirement A PurchaseRequirementRequest is a request from aRequest requestor to a purchaser to (externally) procure products(materials, services) (external procurement). 0131 Purchase Order APurchaseRequirementConfirmation is a notice from the Requirementpurchaser to the requestor about the degree of fulfillment ofConfirmation a requirement. 0140 Product Demand AProductDemandInfluencingEventNotification is a Influencing Eventnotification about an event which influences the supply or Notificationdemand of products. 0141 Product Forecast A ProductForecastNotificationis a notification about future Notification product demands (forecasts).0142 Product Forecast A ProductForecastRevisionNotification is anotification Revision Notification about the revision of future productdemands (forecasts). 0145 Product Activity A ProductActivityNotificationis a message which Notification communicates product-related activitiesof a buyer to a vendor. Based on this, the vendor can perform supplyplanning for the buyer. 0151 RFQ Request An RFQRequest is the requestfrom a purchaser to a bidder to participate in a request for quotationfor a product. 0152 RFQ Change Request An RFQChangeRequest is a changeto the purchaser's request for a bidder to participate in the requestfor quotation for a product. 0153 RFQ Cancellation AnRFQCancellationRequest is a cancellation by the Request purchaser of arequest for quotation for a product. 0154 RFQ Result Notification AnRFQResultNotification is a notification by a purchaser to a bidder aboutthe type and extent of the acceptance of a quote or about the rejectionof the quote. 0155 Quote Notification A QuoteNotification is the quoteof a bidder communicated to a purchaser concerning the request forquotation for a product by the purchaser. 0160 Sales Order Fulfillment ASalesOrderFulfillmentRequest is a request (or change or Requestcancellation of such a request) from a selling component to a procuringcomponent, to fulfill the logistical requirements (e.g.,available-to-promise check, scheduling, requirements planning,procurement, and delivery) of a sales order. 0161 Sales OrderFulfillment A SalesOrderFulfillmentConfirmation is a confirmation,Confirmation partial confirmation or change from the procuring componentto the selling component, regarding a sales order with respect to whichprocurement has been requested. 0185 Order ID Assignment AnOrderIDAssignmentNotification is a message that Notification allows abuyer to assign a vendor order numbers for identifying “purchase ordersgenerated by the vendor.” 0200 Delivery Execution ADeliveryExecutionRequest is a request to a warehouse or Request supplychain execution to prepare and execute the outbound delivery of goods orthe acceptance of an expected or announced inbound delivery. 0201Delivery Information A DeliveryInformation is a message about thecreation, change, and execution status of a delivery. 0202 DespatchedDelivery A DespatchedDeliveryNotification is a notification Notificationcommunicated to a product recipient about the planned arrival, pickup,or issue date of a ready-to-send delivery, including details about thecontent of the delivery. 0203 Received Delivery AReceivedDeliveryNotification is a notification Notification communicatedto a vendor about the arrival of the delivery sent by him to the productrecipient, including details about the content of the delivery. 0210Delivery Schedule A DeliveryScheduleNotification is a message that issent Notification from a buyer to a vendor to notify the latter aboutthe quantity of a product to be delivered with a certain liability at acertain date in accordance with a given scheduling agreement betweenbuyer and vendor. 0213 Vendor Generated Order AVendorGeneratedOrderNotification is a message that is Notification usedby a vendor/seller to transfer the replenishment order that he hasinitiated and planned to a customer/buyer so that the latter can createa purchase order. The notification sent by the vendor/seller to thecustomer/buyer regarding the planned replenishment order can be regardedas a “purchase order generated by the seller.” 0214 Vendor GeneratedOrder VendorGeneratedOrderConfirmation is the confirmation Confirmationfrom a customer/buyer that a purchase order has been created for thereplenishment order initiated and planned by his vendor/seller. Thisconfirmation from the customer/buyer for a “purchase order generated bythe seller” can be regarded as a “purchase order” in the traditionalsense, which, in turn, triggers the corresponding fulfillment process atthe vendor/seller. 0216 Replenishment Order AReplenishmentOrderNotification is a message that is used Notification.by Logistics Planning (SCP, vendor) to transfer a replenishment orderplanned for a customer/buyer to Logistics Execution (SCE, vendor) inorder to trigger further processing for the order and prepare theoutbound delivery. 0217 Replenishment Order AReplenishmentOrderConfirmation is a message that is Confirmation used byLogistics Execution (SCE, vendor) to confirm to Logistics Planning (SCP,vendor) that a replenishment order that is planned for a customer/buyercan be fulfilled. 0240 Service A ServiceAcknowledgementRequest is arequest by a seller Acknowledgement to a purchaser to confirm theservices recorded. Request 0241 Service AServiceAcknowledgementConfirmation is a confirmation Acknowledgement (orrejection) of the services recorded. Confirmation 0250 Inventory ChangeAn InventoryChangeNotification is a summery of detailed Notificationinformation about inventory changes in inventory management, which isrequired for logistics planning. 0251 Inventory Change AnInventoryChangeAccountingNotification is a summary AccountingNotification of aggregated information about inventory changes ininventory management, which is required for financials. 0252 InventoryChange An InventoryChangeAccountingCancellationRequest is a AccountingCancellation request for the full cancellation of posting informationRequest previously sent to financials with respect to a goods movement.0290 Billing Due Notification A BillingDueNotification is a notificationabout billing- relevant data communicated to an application in which thesubsequent operative processing of billing takes place. 0291 InvoicingDue An InvoicingDueNotification is a notification about Notificationinvoicing-relevant data communicated to an application in which theoperative verification and creation of invoices takes place, and/or inwhich “self billing” invoices (evaluated receipt settlement) arecreated. 0401 Invoice Request An InvoiceRequest is a legally bindingnotice about accounts receivable or accounts payable for delivered goodsor provided services - typically a request that payment be made forthese goods or services. 0402 Invoice Confirmation AnInvoiceConfirmation is the response of a recipient of an invoice to thebill-from-party by which the invoice as a whole is confirmed, rejected,or classified as “not yet decided.” 0410 Invoice Issued AnInvoiceIssuedInformation is information about provided Informationservices, delivered products, or credit or debit memo request items thathave been billed, the items of an invoice that have been used for this,and the extent to which they have been billed. 0411 Invoice AccountingAn InvoiceAccountingNotification is a notification to Notificationfinancials about information on incoming or outgoing invoices frominvoice verification or billing. 0412 Invoice Accounting AnInvoiceAccountingCancellationRequest is a request for CancellationRequest the full cancellation of posting information previously sent tofinancials, regarding an incoming or outgoing invoice or credit memo.0420 Tax Due Notification A TaxDueNotification communicates data fromtax determination and calculation relevant for tax reports and taxpayments to the tax register of a company. 0430 Payment Due APaymentDueNotification notifies an application Notification (Payment),in which subsequent operative processing of payments take place, aboutdue dates (accounts receivable and accounts payable) of businesspartners. 0450 Credit Agency Report A CreditAgencyReportQuery is aninquiry to a credit Query agency concerning the credit report for abusiness partner. 0451 Credit Agency Report A CreditAgencyReportResponseis a response from a credit Response agency concerning the inquiry aboutthe credit report for a business partner. 0452 Credit Worthiness Query ACreditWorthinessQuery is an inquiry to credit management concerning thecredit worthiness of a business partner. 0453 Credit Worthiness ACreditWorthinessResponse is a response from credit Response managementconcerning the inquiry about the credit worthiness of a businesspartner. 0454 Credit Worthiness A CreditWorthinessChangeInformation isinformation about Change Information changes of the credit worthiness ofa business partner. 0455 Credit Commitment A CreditCommitmentQuery is aninquiry from credit Query management concerning existing paymentobligations of a business partner. 0456 Credit Commitment ACreditCommitmentResponse is a response concerning an Response inquiryfrom credit management about existing payment obligations of a businesspartner. 0457 Credit Commitment A CreditCommitmentRecordNotification isa notice to Record Notification credit management about existing paymentobligations of business partners. 0458 Credit Worthiness ACreditWorthinessCriticalPartiesQuery is an inquiry to Critical PartiesQuery credit management about business partners, for which the creditworthiness has been rated as critical. 0459 Credit Worthiness ACreditWorthinessCriticalPartiesResponse is a response Critical PartiesResponse from credit management concerning an inquiry about businesspartners, for which the credit worthiness has been rated as critical.0460 Credit Payment Record A CreditPaymentRecordNotification is a noticeto credit Notification management about the payment behavior of businesspartners. 0601 Personnel Time Sheet A PersonnelTimeSheetInformationcommunicates recorded Information personnel times and personnel timeevents from an upstream personnel time recording system to personneltime management.

From the business document flow, the developers identify the businessdocuments having identical or similar structures, and use these businessdocuments to create the business object model (step 108). The businessobject model includes the objects contained within the businessdocuments. These objects are reflected as packages containing relatedinformation, and are arranged in a hierarchical structure within thebusiness object model, as discussed below.

Methods and systems consistent with the subject matter described hereinthen generate interfaces from the business object model (step 110). Theheterogeneous programs use instantiations of these interfaces (called“business document objects” below) to create messages (step 112), whichare sent to complete the business transaction (step 114). Businessentities use these messages to exchange information with other businessentities during an end-to-end business transaction. Since the businessobject model is shared by heterogeneous programs, the interfaces areconsistent among these programs. The heterogeneous programs use theseconsistent interfaces to communicate in a consistent manner, thusfacilitating the business transactions.

Standardized Business-to-Business (“B2B”) messages are compliant with atleast one of the e-business standards (i.e., they include thebusiness-relevant fields of the standard). The e-business standardsinclude, for example, RosettaNet for the high-tech industry, ChemicalIndustry Data Exchange (“CIDX”), Petroleum Industry Data Exchange(“PIDX”) for the oil industry, UCCnet for trade, PapiNet for the paperindustry, Odette for the automotive industry, HR-XML for humanresources, and XML Common Business Library (“xCBL”). Thus, B2B messagesenable simple integration of components in heterogeneous systemlandscapes. Application-to-Application (“A2A”) messages exceed thestandards, and thus provide the benefit of the full functionality ofapplication components. Although various steps of FIG. 1 were describedas being performed manually, one skilled in the art will appreciate thatsuch steps could be computer-assisted or performed entirely by acomputer, including being performed by either hardware, software, or anyother combination thereof.

B. Implementation Details

As discussed above, methods and systems consistent with the subjectmatter described herein create consistent interfaces by generating theinterfaces from a business object model. Details regarding the creationof the business object model, the generation of an interface from thebusiness object model, and the use of an interface generated from thebusiness object model are provided below.

FIG. 5 depicts two exemplary data processing systems 500, 550 suitablefor practicing methods and systems consistent with the subject matterdescribed herein. Data processing system 500 includes a main memory 502,a secondary storage device 504, a processor 506, and an input/output(I/O) device 508. Likewise, data processing system 550 includes a mainmemory 552, a secondary storage device 554, a processor 556, and aninput/output (I/O) device 558. Each data processing system 500, 550 mayfurther comprise standard input devices, such as a keyboard, a mouse ora speech processing means (each not illustrated). The internalcomponents of each data processing system 500, 550 exchange informationwith one another via system buses 510, 560. The components are standardin most computer systems suitable for use with practicing methods andconfiguring systems consistent with the subject matter described herein.One skilled in the art will recognize that data processing systems 500,550 may contain additional or different components.

Memory 502 includes program 512, which is an application program thatfacilitates the transfer of information between business entities.Memory 552 similarly includes program 562, which is an applicationprogram that facilitates the transfer of information between businessentities. For example, program 512 could be an accounting program thattransfers information to program 562, which could be a manufacturingprogram. Although depicted in two separate data processing systems 500,550, one having skill in the art will appreciate that programs 512, 562can reside in the same data processing system, the same computer, andeven in the same memory. Each program 512, 562 may comprise or may beincluded in one or more code sections containing instructions forperforming their respective operations. While programs 512, 562 aredescribed as being implemented as software, the present implementationmay be implemented as a combination of hardware and software or hardwarealone.

Memory 502 also includes an exchange infrastructure (“XI”) 514, which isan infrastructure that supports the technical interaction of businessprocesses across heterogeneous system environments. XI centralizes thecommunication between components within a business entity and betweendifferent business entities. If necessary, XI carries out the mappingbetween the messages. XI is a publicly available product sold by SAP AG,Walldorf, Germany. Similarly, memory 552 includes an XI 564. XI 514, 564integrates different versions of systems implemented on differentplatforms (e.g., Java® and ABAP). XI 514, 564 is based on an openarchitecture, and makes use of open standards, such as XML™ and Java®environments. XI 514, 564 offers services that are useful in aheterogeneous and complex system landscape. In particular, XI 514, 564offers a runtime infrastructure for message exchange, configurationoptions for managing business processes and message flow, and optionsfor transforming message contents between sender and receiver systems.XML is a trademark of the Massachusetts Institute of Technology,Institut National de Recherche en Informatique et en Automatique, andKeio University. Java is a registered trademark of Sun Microsystems,Inc. All names used herein may be trademarks or registered trademarks oftheir respective companies.

XI 514, 564 stores data types 516, 566, a business object model 518,568, and interfaces 520, 570. The details regarding the business objectmodel are described below. Data types 516, 566 are the building blocksfor the business object model 518, 568. The business object model 518,568 is used to derive consistent interfaces 520, 570. XI 514, 564 allowsfor the exchange of information from a first company having one computersystem to a second company having a second computer system over networkconnection 525 by using the standardized interfaces 520, 570.

Although not shown in FIG. 5, like all data processing systems, dataprocessing systems 500, 550 have operating systems that control theiroperations, including the execution of programs 512, 562 by processors506, 556. Also, although aspects of one implementation consistent withthe principles of the subject matter described herein are describedherein with programs 512, 562 stored in main memories 502, 552, oneskilled in the art will appreciate that all or part of systems andmethods consistent with the subject matter described herein may bestored on or read from other computer-readable media, such as secondarystorage devices 504, 554, like hard disks, floppy disks, and CD-ROM; acarrier wave received from a network, such as the Internet; or otherforms of ROM or RAM, either currently known or later developed. Finally,although specific components of data processing system 500, 550 havebeen described, one skilled in the art will appreciate that a dataprocessing system suitable for use with the methods and systemsconsistent with the subject matter described herein may containadditional or different components.

Methods and systems consistent with the subject matter described hereinprovide and use interfaces 520, 570 derived from the business objectmodel 518, 568 suitable for use with more than one business area, forexample different departments within a company such as finance, ormarketing. Also, they are suitable across industries and acrossbusinesses. Interfaces 520, 570 are used during an end-to-end businesstransaction to transfer business process information in anapplication-independent manner. For example the interfaces can be usedfor fulfilling a sales order.

1. Message Overview

To perform an end-to-end business transaction, consistent interfaces areused to create business documents that are sent within messages betweenheterogeneous programs.

a) Message Categories

As depicted in FIG. 6, the communication between a sender 602 and arecipient 604 can be broken down into basic categories that describe thetype of the information exchanged and simultaneously suggest theanticipated reaction of the recipient 604. A message category is ageneral business classification for the messages. Communication issender-driven. In other words, the meaning of the message categories isestablished or formulated from the perspective of the sender 602. Themessage categories include information 606, notification 608, query 610,response 612, request 614, and confirmation 616.

(1) Information

Information 606 is a message sent from a sender 602 to a recipient 604concerning a condition or a statement of affairs. No reply toinformation is expected. Information 606 is sent to make businesspartners or business applications aware of a situation. Information 606is not compiled to be application-specific. Examples of “information”are an announcement, advertising, a report, planning information, and amessage to the business warehouse.

(2) Notification

A notification 608 is a notice or message that is geared to a service. Asender 602 sends the notification 608 to a recipient 604. No reply isexpected for a notification. For example, a billing notification relatesto the preparation of an invoice while a dispatched deliverynotification relates to preparation for receipt of goods.

(3) Query

A query 610 is a question from a sender 602 to a recipient 604 to whicha response 612 is expected. A query 610 implies no assurance orobligation on the part of the sender 602. Examples of a query 610 arewhether space is available on a specific flight or whether a specificproduct is available. These queries do not express the desire forreserving the flight or purchasing the product.

(4) Response

A response 612 is a reply to a query 610. The recipient 604 sends theresponse 612 to the sender 602. A response 612 generally implies noassurance or obligation on the part of the recipient 604. The sender 602is not expected to reply. Instead, the process is concluded with theresponse 612. Depending on the business scenario, a response 612 alsomay include a commitment, i.e., an assurance or obligation on the partof the recipient 604. Examples of responses 612 are a response statingthat space is available on a specific flight or that a specific productis available. With these responses, no reservation was made.

(5) Request

A request 614 is a binding requisition or requirement from a sender 602to a recipient 604. Depending on the business scenario, the recipient604 can respond to a request 614 with a confirmation 616. The request614 is binding on the sender 602. In making the request 614, the sender602 assumes, for example, an obligation to accept the services renderedin the request 614 under the reported conditions. Examples of a request614 are a parking ticket, a purchase order, an order for delivery and ajob application.

(6) Confirmation

A confirmation 616 is a binding reply that is generally made to arequest 614. The recipient 604 sends the confirmation 616 to the sender602. The information indicated in a confirmation 616, such as deadlines,products, quantities and prices, can deviate from the information of thepreceding request 614. A request 614 and confirmation 616 may be used innegotiating processes. A negotiating process can consist of a series ofseveral request 614 and confirmation 616 messages. The confirmation 616is binding on the recipient 604. For example, 100 units of X may beordered in a purchase order request; however, only the delivery of 80units is confirmed in the associated purchase order confirmation.

b) Message Choreography

A message choreography is a template that specifies the sequence ofmessages between business entities during a given transaction. Thesequence with the messages contained in it describes in general themessage “lifecycle” as it proceeds between the business entities. Ifmessages from a choreography are used in a business transaction, theyappear in the transaction in the sequence determined by thechoreography. This illustrates the template character of a choreography,i.e., during an actual transaction, it is not necessary for all messagesof the choreography to appear. Those messages that are contained in thetransaction, however, follow the sequence within the choreography. Abusiness transaction is thus a derivation of a message choreography. Thechoreography makes it possible to determine the structure of theindividual message types more precisely and distinguish them from oneanother.

For example, the message choreography 700 for a purchase order scenariobetween buyer 702 and seller 704 is depicted in FIG. 7. A Purchase OrderRequest Message 706 is the request from the buyer 702 to the seller 704to deliver goods or render services. The message type 708 of thePurchase Order Request Message 706 is 0101, as defined above. ThePurchase Order Change Request Message 710 requests a change of aprevious purchase order request or purchase order change requestmessage. The message type 712 of the Purchase Order Change RequestMessage 710 is 0102. The Purchase Order Cancellation Request Message 714is the cancellation of the request of the buyer 702 to the seller 704 todeliver goods or render services. The message type 716 of the PurchaseOrder Cancellation Request Message 714 is 0103. The Purchase OrderConfirmation Message 718 is a confirmation, a partial confirmation, or achange with respect to the delivery of goods or the rendering ofservices that were requested or cancelled. The message type 720 of thePurchase Order Confirmation Message 718 is 0104.

Illustrative message choreographies that cover a number of transactionsare presented below.

(1) Master Data Management

FIG. 8 depicts the message choreography of a Master Data Management. TheMaster Data Management choreography involves three components: aCatalogue Provider 802, a Catalogue Authoring Tool (CAT) 804, and aCatalogue Search Engine (CSE) 806. The Catalogue Provider 802 sends aCatalogueUpdateNotification message 808 to the CAT 804. The message type810 of the CatalogueUpdateNotification message 808 is 0080, i.e., anotice from a catalogue provider to an interested party about a newcatalogue transmitted in the message or about changes to an existingcatalogue transmitted in the message. The message type 810 can bedivided into multiple messages. The CAT 804 then sends aCataloguePublicationRequest message 812 to the CSE 806. The message type814 of the CataloguePublicationRequest message 812 is 0081, i.e., arequest from catalogue authoring to the Catalogue Search Engine (thepublishing system) to publish a new or changed catalogue or to delete analready published catalogue (the catalogue is possibly split intoseveral transmission packages). The message type 814 also can be dividedinto multiple messages.

The CSE 806 sends a CataloguePublicationTransmissionPackageNotificationmessage 816 to the CAT 804. The message type 818 of theCataloguePublicationTransmissionPackageNotification message 816 is 0082,i.e., the notification of the Catalogue Search Engine (the publishingsystem) to Catalogue Authoring about a package of a cataloguepublication transmission and information about the reception of thispackage and the validity of its content. The message type 818 can bedivided into multiple messages.

The CSE 806 sends a CataloguePublicationConfirmation message 820 to theCAT 804. The message type 822 of the CataloguePublicationConfirmationmessage 820 is 0083, i.e., the confirmation of the Catalogue SearchEngine (the publishing system) to the Catalogue Authoring whether thepublication or deletion of a Catalogue requested by aCataloguePublicationRequest 812 was successful or not.

The CAT 804 sends a CataloguePublicationTransmissionCancellationRequestmessage 824 to the CSE 806. The message type 826 of theCataloguePublicationTransmissionCancellationRequest message 824 is 0084,i.e., the request of Catalogue Authoring to Catalogue Search Engine (thepublishing system) to cancel the transmission of a Catalogue and torestore an earlier published state (if such exists) of the Catalogue.Moreover, no more packages are sent for this transmission.

The CSE 806 sends aCataloguePublicationTransmissionCancellationConfirmation message 828 tothe CAT 804. The message type 830 of theCataloguePublicationTransmissionCancellationConfirmation message 828 is0085, i.e., the confirmation of Catalogue Search Engine (the publishingsystem) whether the transmission of a Catalogue has been cancelledsuccessfully and an earlier published state of this catalogue (if suchexists) has been restored or not.

The CAT 804 sends a CataloguePublicationTransmissionItemLockRequestmessage 832 to the CSE 806. The message type 834 of theCataloguePublicationTransmissionItemLockRequest message 832 is 0086,i.e., the request of Catalogue Authoring to lock single items of thecatalogue contained in the catalogue publication transmission.

The CSE 806 sends a CataloguePublicationTransmissionItemLockConfirmationmessage 836 to the CAT 804. The message type 838 of theCataloguePublicationTransmissionItemLockConfirmation message 836 is0087, i.e., the confirmation of Catalogue Search Engine (the publishingsystem) to Catalogue Authoring whether single items of the cataloguecontained in the catalogue publication transmission could be locked ornot. If an item of the catalogue is locked and the catalogue is not yetpublished, the items must not be published. If the catalogue is alreadypublished, the publication of these items must be revoked.

(2) Purchasing and Sales

(a) Source of Supply, Purchase Requirement, and Purchase Order

FIG. 9 depicts the message choreography of a Source of Supply, PurchaseRequirement, and Purchase Order. The Source of Supply, PurchaseRequirement, and Purchase Order choreography involves three components:Supply Chain Planning (SCP) 902, Purchasing (SRM) 904, and a Supplier906.

The SRM 904 sends a SourceOfSupplyNotification message 908 to the SCP902. The message type 910 of the SourceOfSupplyNotification message 908is 0077, i.e., a notice to Supply Chain Planning about available sourcesof supply.

The SCP 902 sends a PurchaseRequirementRequest message 912 to the SRM904. The message type 914 of the PurchaseRequirementRequest message 912is 0130, i.e., a request from a requestor to a purchaser to (externally)procure products (materials, services) (external procurement).

The SRM 904 sends a PurchaseOrderRequest message 916 to the Supplier906. The message type 918 of the PurchaseOrderRequest message 916 is0101, i.e., a request from a purchaser to a seller to deliver goods orprovide services.

The SRM 904 sends a PurchaseOrderChangeRequest message 920 to theSupplier 906. The message type 922 of the PurchaseOrderChangeRequestmessage 920 is 0102, i.e., a change to a purchaser's request to theseller to deliver goods or provide services.

The SRM 904 sends a PurchaseOrderCancellationRequest message 924 to theSupplier 906. The message type 926 of thePurchaseOrderCancellationRequest message 924 is 0103, i.e., thecancellation of a purchaser's request to the seller to deliver goods orprovide services.

The Supplier 906 sends a PurchaseOrderConfirmation message 928 to theSRM 904. The message type 930 of the PurchaseOrderConfirmation message928 is 0104, i.e., a confirmation, partial confirmation, or change froma seller to the purchaser, regarding the requested delivery of goods orprovision of services.

The SRM 904 sends a PurchaseRequirementConfirmation message 932 to theSCP 902. The message type 934 of the PurchaseRequirementConfirmationmessage 932 is 0131, i.e., a notice from the purchaser to the requestorabout the degree of fulfillment of a requirement.

(b) Product Demand, Product Forecast and Product Activity

FIG. 10 depicts the message choreography of a Product Demand, ProductForecast and Product Activity. The Product Demand, Product Forecast andProduct Activity choreography involves two components: a Buyer (ERP)1002 and a Vendor (SCM) 1004.

The Buyer 1002 sends a ProductDemandInfluencingEventNotification message1006 to the Vendor 1004. The message type 1008 of theProductDemandInfluencingEventNotification message 1006 is 0140, i.e., anotification about an event which influences the supply or demand ofproducts.

The Buyer 1002 sends a ProductForecastNotification message 1010 to theVendor 1004. The message type 1012 of the ProductForecastNotificationmessage 1010 is 0141, i.e., a notification about future product demands(forecasts).

The Buyer 1002 sends a ProductActivityNotification message 1014 to theVendor 1004. The message type 1016 of the ProductActivityNotificationmessage 1014 is 0145, i.e., a message which communicates product-relatedactivities of a buyer to a vendor. Based on this, the vendor can performsupply planning for the buyer.

The Vendor 1004 sends a ProductForecastRevisionNotification message 1018to the Buyer 1002. The message type 1020 of theProductForecastRevisionNotification message 1018 is 0142, i.e., anotification about the revision of future product demands (forecasts).

The Buyer 1002 sends the ProductForecastRevisionNotification message1022 to the Vendor 1004. The message type 1024 of theProductForecastRevisionNotification message 1022 is 0142.

(c) RFQ and Quote

FIG. 11 depicts the message choreography of a RFQ and Quote. The RFQ andQuote choreography involves two components: Purchasing (SRM) 1102 and aSupplier 1104.

The SRM 1102 sends a RFQRequest message 1106 to the Supplier 1104. Themessage type 1108 of the RFQRequest message 1106 is 0151, i.e., therequest from a purchaser to a bidder to participate in a request forquotation for a product.

The Supplier 1104 sends a RFQAcceptanceConfirmation message 1110 to theSRM 1102. The message type of the RFQAcceptanceConfirmation message 1110can be any conventional RFQ Acceptance Confirmation 1112.

The SRM 1102 sends a RFQChangeRequest message 1114 to the Supplier 1104.The message type 1116 of the RFQChangeRequest message 1114 is 0152,i.e., a change to the purchaser's request for a bidder to participate inthe request for quotation for a product.

The SRM 1102 sends a RFQCancellationRequest message 1118 to the Supplier1104. The message type 1120 of the RFQCancellationRequest message 1118is 0153, i.e., a cancellation by the purchaser of a request forquotation for a product.

The Supplier 1104 sends a QuoteNotification message 1122 to the SRM1102. The message type 1124 of the QuoteNotification message 1122 is0155, i.e., the quote of a bidder communicated to a purchaser concerningthe request for quotation for a product by the purchaser.

The SRM 1102 sends a RFQResultNotification message 1126 to the Supplier1104. The message type 1128 of the RFQResultNotification message 1126 is0154, i.e., a notification by a purchaser to a bidder about the type andextent of the acceptance of a quote or about the rejection of the quote.

The Supplier 1104 sends a RFQResultAcceptanceConfirmation message 1130to the SRM 1102. The message type of the RFQResultAcceptanceConfirmationmessage 1130 can be any conventional RFQ Result Acceptance Confirmation1132.

(d) Purchasing

FIG. 12 depicts the message choreography of Purchasing. The Purchasingchoreography involves five components: Sales (CRM) 1202, Purchasing(SRM) 1204, Fulfillment Coordination (FC) 1206, Supply Chain Planning(SCP) 1208, and Supply Chain Execution (SCE) 1210. Line 1212 denotes acompany border. Thus, one company includes Sales 1202, while anothercompany includes SRM 1204, FC 1206, SCP 1208, and SCE 1210.

The SRM 1204 sends a PurchaseOrderRequest message 1214 to the CRM 1202.The message type 1216 of the PurchaseOrderRequest message 1214 is 0101,i.e., a request from a purchaser to a seller to deliver goods or provideservices.

The SRM 1204 sends a PurchaseOrderInformation message 1218 to the FC1206. The message type 1220 of the PurchaseOrderInformation message 1218is 0120, i.e., information from a purchasing system for interestedrecipients about the current state of a purchase order when creating orchanging a purchase order, confirming a purchase order or canceling apurchase order.

The FC 1206 sends the PurchaseOrderInformation message 1222 to the SCP1208. The message type 1224 of the PurchaseOrderInformation message 1222is message type 0120.

The CRM 1202 sends a PurchaseOrderConfirmation message 1226 to the SRM1204. The message type 1228 of the PurchaseOrderConfirmation message1226 is 0104, i.e., a confirmation, partial confirmation, or change froma seller to the purchaser, regarding the requested delivery of goods orprovision of services.

The SRM 1204 sends a PurchaseOrderInformation message 1230 to the FC1206. The message type 1232 of the PurchaseOrderInformation message 1230is 0120, described above.

The FC 1206 sends the PurchaseOrderInformation message 1234 to the SCP1208. The message type 1236 of the PurchaseOrderInformation message 1234is 0120.

The FC 1206 sends a DeliveryExecutionRequest message 1238 to the SCE1210, as depicted by line 1242. Alternatively, the SRM 1204 may send theDeliveryExecutionRequest message 1238 to the SCE 1210, as depicted bybroken line 1240. The message type 1244 of the DeliveryExecutionRequestmessage 1238 is 0200, i.e., a request to a warehouse or supply chainexecution to prepare and execute the outbound delivery of goods or theacceptance of an expected or announced inbound delivery.

The SCE 1210 sends a DeliveryInformation message 1246 to the FC 1206.The message type 1248 of the DeliveryInformation message 1246 is 0201,i.e., a message about the creation, change, and execution status of adelivery.

The FC 1206 sends a DeliveryInformation message 1250 to the SCP 1208.The message type 1252 of the DeliveryInformation message is 0201.

The FC 1206 sends a DeliveryInformation message 1254 to the SRM 1204.The message type 1256 of the DeliveryInformation message 1254 is 0201.

(e) Sales

FIG. 13 depicts the message choreography of Sales. The Saleschoreography involves five components: Purchasing (SRM) 1302, Sales(CRM) 1304, Fulfillment Coordination (FC) 1306, Supply Chain Planning(SCP) 1308, and Supply Chain Execution (SCE) 1310. Line 1312 denotes acompany border. Thus, one company includes SRM 1302, while anothercompany includes CRM 1304, FC 1306, SCP 1308, and SCE 1310.

The SRM 1302 sends a PurchaseOrderRequest message 1314 to the CRM 1304.The message type 1316 of the PurchaseOrderRequest message 1314 is 0101,i.e., a request from a purchaser to a seller to deliver goods or provideservices.

The CRM 1304 sends a SalesOrderFulfillmentRequest message 1318 to the FC1306. The message type 1320 of the SalesOrderFulfillmentRequest message1318 is 0160, i.e., a request (or change or cancellation of such arequest) from a selling component to a procuring component, to fulfillthe logistical requirements (for example, available-to-promise check,scheduling, requirements planning, procurement, and delivery) of a salesorder.

The FC 1306 sends the SalesOrderFulfillmentRequest message 1322 to theSCP 1308. The message type 1324 of the SalesOrderFulfillmentRequestmessage 1322 is 0160.

The SCP 1308 sends a SalesOrderFulfillmentConfirmation message 1326 tothe FC 1306. The message type 1328 of theSalesOrderFulfillmentConfirmation message 1326 is 0161, i.e., aconfirmation, partial confirmation or change from the procuringcomponent to the selling component, regarding a sales order with respectto which procurement has been requested.

The FC 1306 sends the SalesOrderFulfillmentConfirmation message 1330 tothe CRM 1304. The message type 1332 of theSalesOrderFulfillmentConfirmation message 1330 is 0161.

The CRM 1304 sends a PurchaseOrderConfirmation message 1334 to the SRM1302. The message type 1336 of the PurchaseOrderConfirmation message1334 is 0104, i.e., a confirmation, partial confirmation, or change froma seller to the purchaser, regarding the requested delivery of goods orprovision of services.

The FC 1306 sends a DeliveryExecutionRequest message 1338 to the SCE1310. The message type 1340 of the DeliveryExecutionRequest message 1338is 0200, i.e., a request to a warehouse or supply chain execution toprepare and execute the outbound delivery of goods or the acceptance ofan expected or announced inbound delivery.

The SCE 1310 sends a DeliveryInformation message 1344 to the FC 1306.The message type 1346 of the DeliveryInformation message 1344 is 0201,i.e., a message about the creation, change, and execution status of adelivery.

The FC 1306 sends the DeliveryInformation message 1348 to the SCP 1308.The message type 1350 of the DeliveryInformation message 1348 is 0201,i.e., a message about the creation, change, and execution status of adelivery.

The FC 1306 also sends the DeliveryInformation message 1352 to the CRM1304. The message type 1354 of the DeliveryInformation message 1352 is0201.

(f) Vendor Managed Inventory/Responsive Replenishment

FIG. 14 depicts the message choreography of a Vendor ManagedInventory/Responsive Replenishment. The Vendor ManagedInventory/Responsive Replenishment choreography involves threecomponents: a Buyer 1402, Supply Chain Planning 1404, and Supply ChainExecution 1406. Line 1408 denotes a company border. Thus, one companyincludes Buyer 1402, while another company includes Supply ChainPlanning 1404 and Supply Chain Execution 1406.

The Buyer 1402 sends an OrderIDAssignmentNotification message 1410 toSupply Chain Planning 1404. The message type 1412 of theOrderIDAssignmentNotification message 1410 is 0185, i.e., a message thatallows a buyer to assign a vendor order numbers for identifying“purchase orders generated by the vendor.”

Supply Chain Planning 1404 sends a ReplenishmentOrderNotificationmessage 1414 to Supply Chain Execution 1406. The message type 1416 ofthe ReplenishmentOrderNotification message 1414 is 0216, i.e., a messagethat is used by Logistics Planning (SCP, vendor) to transfer areplenishment order planned for a customer/buyer to Logistics Execution(SCE, vendor) in order to trigger further processing for the order andprepare the outbound delivery.

Supply Chain Execution 1406 sends a ReplenishmentOrderConfirmationmessage 1418 to Supply Chain Planning 1404. The message type 1420 of theReplenishmentOrderConfirmation message 1418 is 0217, i.e., a messagethat is used by Logistics Execution (SCE, vendor) to confirm toLogistics Planning (SCP, vendor) that a replenishment order that isplanned for a customer/buyer can be fulfilled.

Supply Chain Planning 1404 sends a VendorGeneratedOrderNotificationmessage 1422 to the Buyer 1402. The message type 1424 of theVendorGeneratedOrderNotification message 1422 is 0213, i.e., a messagethat is used by a vendor/seller to transfer the replenishment order thathe has initiated and planned to a customer/buyer so that the latter cancreate a purchase order. The notification sent by the vendor/seller tothe customer/buyer regarding the planned replenishment order can beregarded as a “purchase order generated by the seller.”

The Buyer 1402 sends a VendorGeneratedOrderConfirmation message 1426 toSupply Chain Planning 1404. The message type 1428 of theVendorGeneratedOrderConfirmation message 1426 is 0214, i.e.,VendorGeneratedOrderConfirmation is the confirmation from acustomer/buyer that a purchase order has been created for thereplenishment order initiated and planned by his vendor/seller. Thisconfirmation from the customer/buyer for a “purchase order generated bythe seller” can be regarded as a “purchase order” in the traditionalsense, which, in turn, triggers the corresponding fulfillment process atthe vendor/seller.

(3) Delivery and Goods Movement

(a) Advanced Shipment Notification and Proof of Delivery

FIG. 15 depicts the message choreography of an Advanced ShipmentNotification and Proof of Delivery. The Advanced Shipment Notificationand Proof of Delivery choreography involves two components: a Vendor1502 and a Product Recipient 1504.

The Vendor 1502 sends a DespatchedDeliveryNotification message 1506 tothe Product Recipient 1504. The message type 1508 of theDespatchedDeliveryNotification message 1506 is 0202, i.e., anotification communicated to a product recipient about the plannedarrival, pickup, or issue date of a ready-to-send delivery, includingdetails about the content of the delivery.

The Product Recipient 1504 sends a ReceivedDeliveryNotification message1510 to the Vendor 1502. The message type 1512 of theReceivedDeliveryNotification message 1510 is 0203, i.e., a notificationcommunicated to a vendor about the arrival of the delivery sent by himto the product recipient, including details about the content of thedelivery.

(b) Service Acknowledgement

FIG. 16 depicts the message choreography of a Service Acknowledgement.The Service Acknowledgement choreography involves two components:Purchasing (SRM) 1602 and a Supplier 1604.

The Supplier 1604 sends a ServiceAcknowledgementRequest message 1606 tothe SRM 1602. The message type 1608 of the ServiceAcknowledgementRequestmessage 1606 is 0240, i.e., a request by a seller to a purchaser toconfirm the services recorded.

The SRM 1602 sends a ServiceAcknowledgementConfirmation message 1610 tothe Supplier 1604. The message type 1612 of theServiceAcknowledgementConfirmation message 1610 is 0241, i.e., aconfirmation (or rejection) of the services recorded.

(c) Inventory Change

FIG. 17 depicts the message choreography of an Inventory Change. TheInventory Change choreography involves three components: InventoryManagement (SCE) 1702, Logistic Planning (SCP) 1704 and FinancialAccounting 1706.

The SCE 1702 sends an InventoryChangeNotification message 1708 to theSCP 1704. The message type 1710 of the InventoryChangeNotificationmessage 1708 is 0250, i.e., a summery of detailed information aboutinventory changes in inventory management, which is required forlogistics planning.

The SCE 1702 sends an InventoryChangeAccountingNotification message 1712to Financial Accounting 1706. The message type 1714 of theInventoryChangeAccountingNotification message 1712 is 0251, i.e., asummary of aggregated information about inventory changes in inventorymanagement, which is required for financials.

The SCE 1702 sends an InventoryChangeAccountingCancellationRequestmessage 1716 to Financial Accounting 1706. The message type 1718 of theInventoryChangeAccountingCancellationRequest message 1716 is 0252, i.e.,a request for the full cancellation of posting information previouslysent to financials with respect to a goods movement.

(4) Invoice and Payment and Financials

(a) Billing Due

FIG. 18 depicts the message choreography of Billing Due. The Billing Duechoreography involves three components: Sales (CRM) 1802, Supply ChainExecution (SCE) 1804, and Billing 1806.

The CRM 1802 sends a BillingDueNotification message 1808 to Billing1806. The message type 1810 of the BillingDueNotification message 1808is 0290, i.e., a notification about billing-relevant data communicatedto an application in which the subsequent operative processing ofbilling takes place.

The SCE 1804 sends a BillingDueNotification message 1816 to Billing1806. The message type 1818 of the BillingDueNotification message 1816is 0290, i.e., a notification about billing-relevant data communicatedto an application in which the subsequent operative processing ofbilling takes place.

(b) Invoicing Due

FIG. 19 depicts the message choreography of Invoicing Due. The InvoicingDue choreography involves three components: Purchasing (SRM) 1902,Supply Chain Execution (SCE) 1904, and Invoicing 1906.

The SRM 1902 sends an InvoicingDueNotification message 1908 to Invoicing1906. The message type 1910 of the InvoicingDueNotification message 1908is 0291, i.e., a notification about invoicing-relevant data communicatedto an application in which the operative verification and creation ofinvoices takes place, and/or in which “self billing” invoices (evaluatedreceipt settlement) are created.

The SCE 1904 sends an InvoicingDueNotification message 1916 to Invoicing1906. The message type 1918 of the InvoicingDueNotification message 1916is 0291, i.e., a notification about invoicing-relevant data communicatedto an application in which the operative verification and creation ofinvoices takes place, and/or in which “self billing” invoices (evaluatedreceipt settlement) are created.

(c) Invoice

FIG. 20 depicts the message choreography of an Invoice. The Invoicechoreography involves four components: Purchasing (SRM) 2002, Invoicing2004, Billing 2006, and Sales (CRM) 2008. Line 2010 denotes a companyborder. Thus, one company includes SRM 2002 and Invoicing 2004, whileanother company includes Billing 2006 and CRM 2008.

Billing 2006 sends an InvoiceRequest message 2012 to Invoicing 2004. Themessage type 2014 of the InvoiceRequest message 2012 is 0401, i.e., alegally binding notice about accounts receivable or accounts payable fordelivered goods or provided services—typically a request that payment bemade for these goods or services.

Invoicing 2004 sends an InvoiceReceivedInformation message 2016 to theSRM 2002. The message type 2018 of the InvoiceReceivedInformationmessage 2016 can be a conventional Invoice Received Information.

Billing 2006 sends an InvoiceIssuedInformation message 2020 to Sales2008. The message type 2022 of the InvoiceIssuedInformation message 2020is 0410, i.e., information about provided services, delivered products,or credit or debit memo request items that have been billed, the itemsof an invoice that have been used for this, and the extent to which theyhave been billed.

Invoicing 2004 sends an InvoiceConfirmation message 2024 to Billing2006. The message type 2026 of the InvoiceConfirmation message 2024 is0402, i.e., the repose of a recipient of an invoice to thebill-from-party by which the invoice as a whole is confirmed, rejected,or classified as ‘not yet decided.’

(d) Invoice Accounting and Payment Due

FIG. 21 depicts the message choreography of Invoice Accounting andPayment Due. The Invoice Accounting and Payment Due choreographyinvolves three components: Invoicing/Billing 2102, Accounting 2104 andPayment 2106.

Invoicing/Billing 2102 sends an InvoiceAccountingNotification message2108 to Accounting 2104. The message type 2110 of theInvoiceAccountingNotification message 2108 is 0411, i.e., a notificationto financials about information on incoming or outgoing invoices frominvoice verification or billing.

Invoicing/Billing 2102 sends an InvoiceAccountingCancellationRequestmessage 2112 to Accounting 2104. The message type 2114 of theInvoiceAccountingCancellationRequest message 2112 is 0412, i.e., arequest for the full cancellation of posting information previously sentto financials, regarding an incoming or outgoing invoice or credit memo.

Invoicing/Billing 2102 sends a PaymentDueNotification message 2116 toPayment 2106. The message type 2118 of the PaymentDueNotificationmessage 2116 is 0430, i.e., the PaymentDueNotification notifies anapplication (Payment), in which subsequent operative processing ofpayments take place, about due dates (accounts receivable and accountspayable) of business partners.

Invoicing/Billing 2102 sends a PaymentDueCancellationRequest message2120 to Payment 2106. The message type 2122 of thePaymentDueCancellationRequest message 2120 can be any conventionalPayment Due Cancellation Request.

(e) Tax Due

FIG. 22 depicts the message choreography of Tax Due. The Tax Duechoreography involves two components: Tax Calculation 2202 and TaxRegister 2204.

Tax Calculation 2202 sends a TaxDueNotification message 2206 to the TaxRegister 2204. The message type 2208 of the TaxDueNotification message2206 is 0420, i.e., the TaxDueNotification communicates data from taxdetermination and calculation relevant for tax reports and tax paymentsto the tax register of a company.

Tax Calculation 2202 sends a TaxDueCancellationRequest message 2210 tothe Tax Register 2204. The message type 2212 of theTaxDueCancellationRequest message 2210 can be any conventional Tax DueCancellation Request.

(f) Credit Worthiness, Credit Agency Report, Credit Payment, and CreditCommitment

FIG. 23 depicts the message choreography of Credit Worthiness, CreditAgency Report, Credit Payment, and Credit Commitment. The CreditWorthiness, Credit Agency Report, Credit Payment, and Credit Commitmentchoreography involves five components: Payment or Accounting 2302, Salesor Financials 2304, a Billing System (e.g., Telco) 2306, CreditManagement 2308, and Credit Agency 2310.

Sales or Financials 2304 sends a CreditCommitmentRecordNotificationmessage 2312 to Credit Management 2308. The message type 2314 of theCreditCommitmentRecordNotification message 2312 is 0457, i.e., a noticeto credit management about existing payment obligations of businesspartners.

Payment or Accounting 2302 sends a CreditPaymentRecordNotificationmessage 2316 to Credit Management 2308. The message type 2318 of theCreditPaymentRecordNotification message 2316 is 0460, i.e., a notice tocredit management about the payment behavior of business partners.

Sales or Financials 2304 sends a CreditWorthinessQuery message 2320 toCredit Management 2308. The message type 2322 of theCreditWorthinessQuery message 2320 is 0452, i.e., an inquiry to creditmanagement concerning the credit worthiness of a business partner.

Credit Management 2308 sends a CreditAgencyReportQuery message 2324 toCredit Agency 2310. The message type 2326 of the CreditAgencyReportQuerymessage 2324 is 0450, i.e., an inquiry to a credit agency concerning thecredit report for a business partner.

Credit Agency 2310 sends a CreditAgencyReportResponse message 2328 toCredit Management 2308. The message type 2330 of theCreditAgencyReportResponse message 2328 is 0451, i.e., a response from acredit agency concerning the inquiry about the credit report for abusiness partner.

Credit Management 2308 sends a CreditCommitmentQuery message 2332 to theBilling System 2306. The message type 2334 of the CreditCommitmentQuerymessage 2332 is 0455, i.e., an inquiry from credit management concerningexisting payment obligations of a business partner.

The Billing System 2306 sends a CreditCommitmentResponse message 2336 toCredit Management 2308. The message type 2338 of theCreditCommitmentResponse message 2336 is 0456, i.e., a responseconcerning an inquiry from credit management about existing paymentobligations of a business partner.

Credit Management 2308 sends a CreditWorthinessResponse message 2340 toSales or Financials 2304. The message type 2342 of theCreditWorthinessResponse message 2340 is 0453, i.e., a response fromcredit management concerning the inquiry about the credit worthiness ofa business partner.

Credit Management 2308 sends a CreditWorthinessChangeInformation message2344 to Sales or Financials 2304. The message type 2346 of theCreditWorthinessChangeInformation message 2344 is 0454, i.e.,information about changes of the credit worthiness of a businesspartner.

Sales or Financials 2304 sends a CreditWorthinessCriticalPartiesQuerymessage 2348 to Credit Management 2308. The message type 2350 of theCreditWorthinessCriticalPartiesQuery message 2348 is 0458, i.e., aninquiry to credit management about business partners, for which thecredit worthiness has been rated as critical.

Credit Management 2308 sends a CreditWorthinessCriticalPartiesResponsemessage 2352 to Sales or Financials 2304. The message type 2354 of theCreditWorthinessCriticalPartiesResponse message 2352 is 0459, i.e., aresponse from credit management concerning an inquiry about businesspartners, for which the credit worthiness has been rated as critical.

(5) Human Capital Management

(a) Personnel Time Sheet

FIG. 24 depicts the message choreography of a Personnel Time Sheet. ThePersonnel Time Sheet choreography involves two components: PersonnelTime Recording 2402 and Personnel Time Management 2404.

Personnel Time Recording 2402 sends a PersonalTimeSheetInformationmessage 2406 to Personnel Time Management 2404. The message type 2408 ofthe PersonalTimeSheetInformation message 2406 is 0601, i.e., thePersonnelTimeSheetInformation communicates recorded personnel times andpersonnel time events from an upstream personnel time recording systemto personnel time management.

2. Components of the Business Object Model

The overall structure of the business object model ensures theconsistency of the interfaces that are derived from the business objectmodel. The derivation ensures that the same business-related subjectmatter or concept is represented and structured in the same way in allinterfaces.

The business object model defines the business-related concepts at acentral location for a number of business transactions. In other words,it reflects the decisions made about modeling the business entities ofthe real world acting in business transactions across industries andbusiness areas. The business object model is defined by the businessobjects and their relationship to each other (the overall netstructure).

A business object is a capsule with an internal hierarchical structure,behavior offered by its operations, and integrity constraints. Businessobjects are semantically disjoint, i.e., the same business informationis represented once. In the business object model, the business objectsare arranged in an ordering framework. From left to right, they arearranged according to their existence dependency to each other. Forexample, the customizing elements may be arranged on the left side ofthe business object model, the strategic elements may be arranged in thecenter of the business object model, and the operative elements may bearranged on the right side of the business object model. Similarly, thebusiness objects are arranged from the top to the bottom based ondefined order of the business areas, e.g., finance could be arranged atthe top of the business object model with CRM below finance and SRMbelow CRM.

To ensure the consistency of interfaces, the business object model maybe built using standardized data types as well as packages to grouprelated elements together, and package templates and entity templates tospecify the arrangement of packages and entities within the structure.

a) Data Types

Data types are used to type object entities and interfaces with astructure. This typing can include business semantic. For example, thedata type BusinessTransactionDocumentID is a unique identifier for adocument in a business transaction. Also, as an example, Data typeBusinessTransactionDocumentParty contains the information that isexchanged in business documents about a party involved in a businesstransaction, and includes the party's identity, the party's address, theparty's contact person and the contact person's address.BusinessTransactionDocumentParty also includes the role of the party,e.g., a buyer, seller, product recipient, or vendor.

The data types are based on Core Component Types (“CCTs”), whichthemselves are based on the World Wide Web Consortium (“W3C”) datatypes. “Global” data types represent a business situation that isdescribed by a fixed structure. Global data types include bothcontext-neutral generic data types (“GDTs”) and context-based contextdata types (“CDTs”). GDTs contain business semantics, but areapplication-neutral, i.e., without context. CDTs, on the other hand, arebased on GDTs and form either a use-specific view of the GDTs, or acontext-specific assembly of GDTs or CDTs. A message is constructed withreference to a use, and is thus a use-specific assembly of GDTs andCDTs. The data types can be aggregated to complex data types.

To achieve a harmonization across business objects and interfaces, thesame subject matter is always typed with the same data type. Forexample, the data type “GeoCoordinates” is built using the data type“Measure” so that the measures in a GeoCoordinate (i.e., the latitudemeasure and the longitude measure) are represented the same as other“Measures” that appear in the business object model.

(1) CoreComponentTypes (CCTs)

(a) Amount

A CCT Amount 2500 is used to represent amounts, costs, remunerations,and fees. A CCT Amount 2500 includes an amount with the correspondingcurrency unit. An example of the CCT Amount 2500 is: <AmountcurrencyCode=“EUR”>777.95</Amount>, which represents the amount 777.95Euros.

The structure of CCT Amount 2500 is depicted in FIG. 25. CCT Amount 2500includes the attribute currencyCode 2502. For CCT Amount 2500, theCategory is complexType 2504, the Property is Amount 2510, theRepresentation/Association is Content 2514, the Type is xsd 2518, theType Name is decimal 2522, and the Length can have a maximum 22predecimal places and 6 decimal places 2626.

For the currencyCode 2502, the Category is Attribute 2506, the ObjectClass is Amount 2508, the Property is Currency 2512, theRepresentation/Association is Code 2516, the Type is xsd 2520, the TypeName is token 2524, and the Length is three 2528. The Cardinalitybetween CCT Amount 2500 and currencyCode 2502 is one 2530. CurrencyCode2502 is mandatory 2532. CurrencyCode 2502 requires the currency toalways be specified.

(b) BinaryObject

A CCT BinaryObject 2600 includes a finite data stream of any number ofcharacters in binary notation (octets). CCT BinaryObject 2600 can bedelivered to a partner using two methods: (1) an implicit representationas an element value; or (2) as a MIME attachment within a message, witha unique URI-based reference to the corresponding attachment. An examplefor CCT BinaryObject 2600 is a representation of CCT BinaryObject 2600as an element value based on base64 encoding is: <BinaryObjecttypeCode=“application/zip” name=“photos.zip”>   T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS   BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk   IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS   BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1   YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW    NrIHF1YWNrCkUgSSBFIEkgTwo=</BinaryObject>.

An example of a reference to CCT BinaryObject 2600 that is delivered asa MIME attachment within a message is:

<BinaryObject uri=“cid:a34ccrt@15.4.9.92/s445”/>.

The element value of CCT BinaryObject 2600 is based on theXML-scheme-specific built-in data type xsd: base64binary. This enablesany binary data to be represented using base64 encoding. This is doneusing the base64 Content-Transfer-Encoding procedure.

The structure of CCT BinaryObject 2600 is depicted in FIG. 26. CCTBinaryObject 2600 includes attributes mimeCode 2602, charSetCode 2604,format 2606, filename 2608, and URI 2610. For CCT BinaryObject 2600, theCategory is complexType 2612, the Property is Binary-Object 2634, theRepresentation/Association is Content 2646, the Type is xsd 2658, andthe Type Name is base64binary 2670.

MimeCode 2602 identifies the medium type (image, audio, video,application) of the binary content according to the MIME type definitionin IETF RFC 2046 and the corresponding MIME type recommendations. FormimeCode 2602, the Category is Attribute 2614, the Object Class isBinary-Object 2625, the Property is mime 2636, theRepresentation/Association is Code 2648, the Type is xsd 2660, the TypeName is token 2672, and the Cardinality may be 0 or 1 2680. Mimecode2602 is necessary when CCT BinaryObject 2600 is represented as anelement value (see 2688).

CharSetCode 2604 identifies the specific character set of text data. ForCharSetCode 2604, the Category is Attribute 2616, the Object Class isBinary-Object 2626, the Property is Character Set 2638, theRepresentation/Association is Code 2650, the Type is xsd 2662, the TypeName is token 2674, and the Cardinality may be 0 or 1 2680. CharSetCode2604 is necessary when CCT BinaryObject 2600 is represented as anelement value and comprises text data (see 2690).

Format 2606 describes the format of the binary content if the format isnot clear or unique from the “mimeCode.” For Format 2606, the Categoryis Attribute 2618, the Object Class is Binary-Object 2628, the Propertyis Format 2640, the Representation/Association is Text 2652, the Type isxsd 2664, the Type Name is token 2675, and the Cardinality may be 0 or 12684. Format 2606 may be optional (see 2692).

Filename 2608 contains the corresponding name or file name of the binarycontent according to the MIME protocol. For filename 2608, the Categoryis Attribute 2620, the Object Class is Binary-Object 2630, the Propertyis Filename 2642, the Representation/Association is Text 2654, the Typeis xsd 2666, the Type Name is string 2676, and the Cardinality is may be0 or 1 2686. Filename 2608 is not defined in ebXML CCTS 1.8, but it isto be submitted. Filename 2608 also conforms with IETF RFC 1341 (see2694).

URI 2610 references the physical location of CCT BinaryObject 2600 ifthis is represented as a MIME attachment in a SOAP message or in anebXML-MSG message. The syntax of the URI is defined in the IETF RFC 2396recommendation and is as follows: <scheme>.<scheme-specific part>. ForURI 2610, the Category is Attribute 2622, the Object Class isBinary-Object 2632, the Property is Uniform Resource 2644, theRepresentation/Association is Identifier 2656, the Type is xsd 2668, andthe Type Name is any URI 2678. URI 2610 is necessary when referencing aremote CCT BinaryObject 2600 (see 2696).

As enumerated by the Internet Assigned Numbers Authority (IANA),November 2002, various MIME types are available for mimeCode 2602. Forexample one MIME type may be iso-8859-n, where n is a placeholder forthe number of the relevant ISO character set from 1 to 9. Anotherexample MIME type is us-ascii.

Various URI schemes are also available for the scheme-specific part inthe URI, as enumerated by the IANA. For example, one available scheme iscid which is a content identifier. Another available scheme is uuid,which is a Universal Unique Identifier Scheme.

CCT BinaryObject 2600 can be used for binary data and all types ofbinary files. This includes graphics (such as diagrams, mathematiccurves, and the like), pictures (such as photos, passport photos, andthe like), sound recordings, video recordings, and documents in binarynotation (such as PDF, DOC, and XLS files). The primaryRepresentation/Association for CCT BinaryObject 2600 is BinaryObject.Additional secondary Representation/Associations may be Graphic,Picture, Sound and Video.

The useful data in Binary Object 2600 may be delivered either as anelement value using base64 octet representation or as a MIME attachment.In certain variations, CCT BinaryObject 2600 is not used to reference afile that is located on a Web server. The global data type “WebAddress”is available for this purpose. If CCT BinaryObject 2600 is in a MIMEattachment, the URI 2610 may reference the corresponding “Content ID” ofthe respective MIME attachment. For this purpose, URI scheme cid may beused, which identifies a freely defined “Content ID”. URI scheme uuidmay also be used for this purpose. Uuid identifies a uniqueidentification in accordance with UUID guidelines.

It is not necessary to specify the “typeCode” and “fileName” attributesin a MIME attachment, since this information is contained in the MIMEattachment itself.

(c) Code

A CCT Code 2700 is a character string of letters, numbers, specialcharacters (except escape sequences), and symbols. It represents adefinitive value, a method, or a property description in an abbreviatedor language-independent form. An example for the CCT Code 2700 is: aStandard Code/Standard Agency is <SecurityErrorCode listID=“DE 0571”listAgencyID=“6”>4</SecurityErrorCode>.

An example of a Proprietary Code/Standard Agency is <SecurityErrorCodelistID=“SEC” listAgencyID=“065055766” listAgencySchemeID=“DUNS”listAgencySchemeAgencyID=“016”>ANS</SecurityErrorCode>.

An example of a Proprietary Code/Proprietary Agency is<SecurityErrorCode listID=“SEC” listAgencyID=“4711”listAgencySchemeID=“PartyA”listAgencySchemeAgencyID=“ZZZ”>ER05</SecurityErrorCode>

The structure of CCT Code 2700 is depicted in FIG. 27. CCT Code 2700includes Attributes listID 2702, listVersionID 2704, listAgencyID 2706,listAgency-SchemeID 2708, and listAgency-SchemeAgencyID 2710. For CCTCode 2700, the Category is complexType 2712, the Property is Code 2734,the Representation/Association is Content 2746, the Type is xsd 2758,and the Type Name is token 2770.

ListID 2702 identifies a list of the codes that belong together. ListID2702 is unique within the agency that manages this code list. For listID2702, the Category is Attribute 2714, the Object Class is CodeList 2724,the Property is Identification 2736, the Representation/Association isIdentifier 2748, the Type is xsd 2760, the Type Name is token 2772, andthe Cardinality is may be 0 or 1 2782. The attribute ListID may beoptional (see 2792).

ListVersionID 2704 identifies the version of a code list. ForlistVersionID 2704, the Category is Attribute 2716, the Object Class isCodeList 2726, the Property is Version 2738, theRepresentation/Association is Identifier 2750, the Type is xsd 2762, theType Name is token 2774, and the Cardinality may be 0 or 1 2784. Theattribute ListVersionID may be optional (see 2792).

ListAgencyID 2706 identifies the agency that manages the code list. Theagencies from DE 3055 are used as the default (without roles). ForlistAgencyID 2706, the Category is Attribute 2718, the Object Class isCodeListAgency 2728, the Property is Identification 2740, theRepresentation/Association is Identifier 2752, the Type is xsd 2764, theType Name is token 2776, and the Cardinality is may be 0 or 1 2786. Theattribute ListAgencyID may be optional (see 2796).

ListAgencySchemeID 2708 identifies the identification scheme thatrepresents the context that is used to identify the agency. ForlistAgencySchemeID 2708, the Category is Attribute 2720, the ObjectClass is CodeListAgency 2730, the Property is Scheme 2742, theRepresentation/Association is Identifier 2754, the Type is xsd 2766, theType Name is token 2778, and the Cardinality is may be zero or one 2788.The attribute ListVersionAgencyID may be optional (see 2797).

ListAgencySchemeAgencyID identifies the agency that manages thelistAgencySchemeID. This attribute can contain values from DE 3055(excluding roles). For listAgencySchemeAgencyID 2710, the Category isAttribute 2722, the Object Class is CodeListAgency 2732, the Property isSchemeAgency 2744, the Representation/Association is Identifier 2756,the Type is xsd 2768, the Type Name is token 2780, and the Cardinalitymay be zero or one 2790. The attribute listAgencySchemeAgencyID may beoptional (see 2798).

The CCT Code 2700 data type is used for elements that are used in thecommunication between partners or systems to enable a common coded valuerepresentation in place of texts, methods, or properties. This code listshould be relatively stable, and not subject to frequent or significantchanges (for example, CountryCode, LanguageCode, and so on). If theagency that manages the code list is not named explicitly, but isspecified by using a role, this is done in the tag name.

Standardized codes and proprietary codes may be represented by CCT Code2700. For standardized codes whose code lists are managed by an agencyfrom the DE 3055 code list, listID 2702 identifies the code list for thestandard code, listVersionID 2704 identifies the version of the codelist, and listAgencyID 2706 identifies the agency from DE 3055(excluding roles). For proprietary codes whose code lists are managed byan agency that is identified using a standard, listID 2702 identifies acode list for the proprietary code, listVersionID 2704 identifies aversion of the code list, listAgencyID 2706 identifies standardized IDfor the agency (such as the company that manages the proprietary codelist), listAgencySchemeID 2708 identifies the identification scheme forthe schemeAgencyID, and listAgencySchemeAgencyID 2710 identifies theagency from DE 2055 that manages the standardized ID ‘listAgencyID’. Forproprietary codes whose code lists are managed by an agency that isidentified without the use of a standard, list ID 2702 identifies a codelist for the proprietary code, listVersionID 2704 identifies a versionof the code list, listAgencyID 2706 identifies a proprietary ID for theagency (such as the company that manages the proprietary code list),list AgencySchemeID 2708 identifies the identification scheme for theschemeAgencyID, and listAgencySchemeAgencyID 2710 identifies ‘ZZZ’ whichis mutually defined from DE 3055.

For proprietary codes whose code lists are managed by an agency that isspecified using a role or not at all, listID 2702 identifies anidentification scheme for the proprietary identifier, and listVersionID2704 identifies a version of the identification scheme. The role isspecified as a prefix in the tag name. If there is more than one codelist, listID and listVersionID can be used as attributes. No attributesare required if there is only one code list.

The representation term for the CCT Code 2700 is Code.

If CCT Code 2700 is used as a basis to define a specific code GDT thatcombines parts of standard code lists of different standardizationorganizations, and the complied lists are not disjunctive, attributeslistID 2702, listVersionID 2704, and listAgencyID 2706 may be includedin the GDT. However, these attributes may not be required in the GDT ifthe compiled lists are not disjunctive but, in each interface that usesthe GDT, the lists supported by the interface are disjunctive.

To be able to represent values, methods, and property descriptions ascode, the corresponding code list may be consistent and, unlikeidentifier lists, subject to very few changes to its content. In certainvariations, CCT Code 2700 is not used to uniquely identify any logicalor real objects. In some cases it may not be possible to differentiateclearly between Identifier and Code for coded values. This isparticularly applicable if a coded value is used to uniquely identify anobject and, at the same time, this coded value is used to replace alonger text. For example, this includes the coded values for “Country,”“Currency,” “Organization,” “Region,” and the like. If the list of codedvalues in this case is consistent, then the GDT Code can be used for theindividual coded values.

For example, a passport number (PassportId) is an “Identifier,” becausea) it identifies a (real) object, namely, a natural person, and b) thelist of passport numbers is constantly growing as new passport numbersare issued. A country code (CountryCode or CountryId) may be either anIdentifier or a Code. The country code uniquely identifies a realobject, namely, the country. However, the country code itself is also areplacement for the respective (unique) country name. Therefore, it isalso a Code. Since the code list is relatively consistent, the countryname should be represented as a Code. Changes are caused by politicalevents and such changes are few in comparison to those relating tonatural persons. A process code (ProcessCode) is a Code, because a) itdescribes a method type and not an object, and b) the list of processcodes seldom changes.

(d) DateTime

A CCT DateTime 2800 is the time stamp, accurate to the second, of acalendar day. An example for CCT DateTime 2800 is: the following coderepresents Apr. 19, 2002 at 3:30, in Berlin:

<DateTime>2002-04-19T15:30:00+01:00</DateTime>.

The structure of CCT DateTime 2800 is depicted in FIG. 28. The Categoryfor CCT DateTime 2800 is simpleType 2802, the Property is DateTime 2804,the Representation/Association is Content 2806, the Type is xsd 2808,and the Type Name is dateTime 2810.

The CCT DateTime 2800 core component type uses the W3C built-in datatype xsd: dateTime. This is structured in accordance with the extendedrepresentation of ISO 8601. However, unlike in xsd: date, in certainvariations, negative years or years are not represented with more than 4numeric values in “Date.” The extended representation may be representedas CCYY-MM-DDThh:mm:ss(.sss)Z or CCYY-MM-DDThh:mm:ss(.sss)(+/−)hh:mm(for example, 2002-04-19T15:30:00Z or 2002-04-19T10:30:00+05:00,respectively).

The extended representation uses CC for century (00-99); YY for year(00-99); MM for month (01-12); DD for day (01-28 for month 02; 01-29 formonth 02 when the year is a leap year; 01-30 for months 04, 06, 09, and11; 01-31 for months 01, 03, 05, 07, 08, 10, and 12); a hyphen betweenthe year, month, and day; a separator “T” between the date and time; hhfor hours (00-23); mm for minutes (00-59); ss for seconds (00-59); sssfor one or more characters after the decimal point to representfractions of a second; a colon between the hours, minutes, and seconds;Z to specify when the represented time is also the UTC time; +hh:mm tospecify when the represented time is a local time that is ahead of UTCtime; and −hh:mm to specify when the represented time is a local timethat is behind UTC time.

The time stamp may be indicated without additional information (Z,+hh:mm, −hh:mm) relative to the coordinated world time (UTC time). Incertain variations, this time stamp is not then be converted to therespective local time and is therefore for information purposes.

Ranges Day, Time, Minutes, Seconds, and Time Zone are defined forDateTime. Day represents all dates from the Gregorian calendar. Timerepresents exactly 24 hours (0-23). Minutes represents exactly 60minutes (0-59). Seconds represents exactly 60 seconds (0-59). Time zonemay be expressed in UTC (Coordinated Universal Time). If DateTimerepresents a local time, the time difference with respect to UTC timemay also be specified.

CCT DateTime 2800 is used for exact time stamps that may contain the dayand time. It may be, the creation date/time, receipt date/time,processing date/time, delivery date/time, expiry date/time, and thelike. The primary representation term for the CCT DateTime 2800 isDateTime. Additional secondary representation terms are Date and Time.Date is a calendar representation of a particular day. The Built-In DataType of Date is xsd: date and a restriction is length=10. Time is a timestamp, accurate to the second, of a particular time. The Built-In DataType for Time is xsd: time.

The coordinated world time or coordinated universal time (UTC) iscurrently the uniform basis for time specifications that are usedinternationally. It is based on the route of the sun and is an extremelyconstant time unit. The mean solar time at the Greenwich meridian can beused as an approximate guide value for UTC.

The Gregorian calendar is currently used primarily in the western worldand is an approximation of the complicated calculation of a “tropicalyear.” The mean of the “tropical year” is 365.2422 days. The Gregoriancalendar, in use since 1582, defines the rules for leap years.

(e) ElectronicAddress

A CCT ElectronicAddress 2900 is a unique digital address that isrepresented by the Unified Resource Identifier (URI). An example for CCTElectronicAddress 2900 in http format is: <Address>   www.sap.com/InterfaceRepository/ElectronicAddresses/   description.htm </Address> One example representation of an X.400address is: <Address protocolID=“XF” >   mailto:c=DE;a=SAP;p=SAP;o=EXCHANGE;s=STUHEC;    g=GUNTHER </Address>.

The structure of CCT ElectronicAddress 2900 is depicted in FIG. 29. CCTElectronicAddress 2900 includes attributes protocolID 2902 andlanguageCode 2904. The Category for CCT ElectronicAddress 2900 iscomplexType 2906, the Property is ElectronicAddress 2916, theRepresentation/Association is Content 2922, the Type is xsd 2928 and theType Name is any URI 2934.

For protocolID 2902, the Category is Attribute 2908, the Object Class isElectronicAddress 2912, the Property is Protocol 2918, theRepresentation/Association is Identifier 2924, the Type is xsd 2930, theType Name is token 2936, and the Cardinality between the CCT ElectronicAddress 2900 and protocolID 2902 is zero or one 2942. The protocolIDAttribute 2902 may be optional (see 2946).

For languageCode 2904, the Category is Attribute 2908, the Object Classis ElectronicAddress 2914, the Property is Language 2920, theRepresentation/Association is Code 2926, the Type is xsd 2932, the TypeName is language 2938, the Length is from two to nine 2940, and theCardinality between CCT Electronic Address 2900 and languageCode 2904 iszero or one 2944. The languageCode Attribute 2904 may be optional (see2948).

The syntax for CCT Electronic Address 2900 is specified in the IETF RFC2396. A URI consists of the scheme (in other words, how to access aresource), followed by a colon and the scheme-specific part. Thescheme-specific part is relevant for the service that is connected tothe particular scheme. A resource can have multiple URIs. One reason maybe that a resource exists physically at multiple locations, due tomirroring, or it may be addressed using different protocols, which arespecified by the scheme name. For example, a file can be referencedusing http and ftp.

A URI is therefore generally constructed as <scheme>:<scheme-specificpart>. The following is an example of a URL with typical partialexpression types:

<scheme>://<user>:<password>@<host>:<port>/<path>?<query>;

<argument>=<value>&<argument>=<value>#<fragment>.

URI schemes that are available include ftp, http, mailto, File, cid,mid, nfs, https, uuid. Additional URI schemes that are currently notrequired include Gopher, News, nntp, telnet, wais, prospere, z39.50s,z39.50r, vemmi, service, imap, acap, rtsp, tip, pop, data, dav,opaquelocktoken, sip, tel, fax, modem, Idap, soap.beep, soap.beeps, urn,go, afs, tn3270, and mailserver.

If the above-listed URI schemes are not sufficient to determine theaddress protocol, one can either apply for another URI scheme inaccordance with the guidelines of IETF RFC 2717, or define thecorresponding protocol type more exactly by specifying the “protocolID”attribute as well. For this protocol type, the codes from the UN/EDIFACTDE 3155 “Communication Address Code Qualifier” code list are used. Thesecodes include AB, AF, AN, AO, EM, El, FT, GM, IM, SW, and XF. AB refersto Communications number assigned by Societe Internationale deTelecommunications Aeronaufiques (SITA). AD refers to the AT&T mailboxidentifier. AF refers to the switched telecommunications network of theUnited States Department of Defense. AN refers to the ODETTE FileTransfer Protocol. AO refers to identification of the Uniform ResourceLocation (URL) Synonym: World wide web address. EM refers to theElectronic Mail Exchange of mail by electronic means (SMTP). EI refersto the number identifying the service and service user of an EDItransmission. FT refers to the file transfer access method according toISO. GM refers to the GEIS (General Electric Information Service)mailbox. IM refers to the Internal mail address/number. SW refers tocommunications address assigned by Society for Worldwide InterbankFinancial Telecommunications s.c. XF refers to the X.400 address.

No codings currently exist for ms (Microsoft Mail) and ccmail protocols,although respective coding proposals are expected to be submitted to theUN/CEFACT Forum for standardization.

If the attachment is a document or text, attribute languageCode 2904 maybe used to represent the language of the attachment in accordance withIETF RFC 1766 or IETF RFC 3066.

CCT ElectronicAddress 2900 is a core component type that can be used torepresent global data types (GDTS) for email addresses, Web sites, anddocuments or information provided on Web sites. The representation termfor the CCT ElectronicAddress 2900 is ElectronicAddress.

In certain variations, CCT ElectronicAddress 2900 is not used as areference component for binary data that is sent as an additional MIMEattachment. The CCT BinaryObject 2900 is available for this purpose.

(f) Identifier

A CCT Identifier 3000 is a unique identification of an object within anidentification scheme that is managed by an agency. There may bemultiple identification schemes for identifying an object. An examplefor CCT Identifier 3000 is: a Standard Identifier/Standard Agency is<ProductID schemeID=“GTIN”schemeAgencyID=“113”>10614141000415</ProductId>. One example of aProprietary Identifier/Standard Agency is <ProductIDschemeID=“householdappliance” schemeAgencyID=“065055766”schemeAgencySchemeID=“DUNS”schemeAgencySchemeAgencyID=“016”>123</ProductId>. One example of aProprietary Identifier/Proprietary Agency is <ProductIDschemeID=“householdappliance” schemeAgencyID=“4711”schemeAgencySchemeID=“PartyA”schemeAgencySchemeAgencyID=“ZZZ”>456</ProductId>.

The structure of CCT Identifier 3000 is depicted in FIG. 30. CCTIdentifier 3000 includes Attributes schemeID 3002, schemeVersionID 3004,schemeAgencyID 3006, schemeAgency-SchemeID 3008, andschemeAgency-SchemeAgencyID 3010. For CCT Identifier 3000, the Categoryis complexType 3012, the Object Class is Identifier 3024, the Propertyis identifier 3036, the Representation/Association is Content 3048, theType is xsd 3060, and the Datatype is token 3072.

SchemeID 3002 identifies an identification scheme. The identificationscheme represents the context that is used to identify an object.SchemeID is unique within the agency that manages this identificationscheme. For schemeID, the Category is Attribute 3014, the Object Classis IdentificationScheme 3026, the Property is Identification 3038, theRepresentation/Association is Identifier 3050, the Type is xsd 3062, theDatatype is token 3074, and the Length is from one to sixty 3084. TheCardinality between the CCT Identifier 3000 and schemeID 3002 is zero orone 3090. The schemeID attribute 3002 may be optional (see 3095).

SchemeVersionID 3004 identifies the version of an identification scheme.For schemeVersionID, the Category is Attribute 3016, the Object Class isIdentificationScheme 3028, the Property is Version 3040, theRepresentation/Association is Identifier 3052, the Type is xsd 3064, theData-type is token 3076, and the Length is from one to fifteen 3086. TheCardinality between the CCT Identifier 3000 and SchemeVersion ID is zeroor one 3091. The schemeVersionID attribute 3004 may be optional (see3096).

SchemeAgencyID 3006 identifies the agency that manages an identificationscheme. The agencies from DE 3055 are used as the default, but incertain variations the roles defined in DE 3055 are not used. ForschemeAgencyID, the Category is Attribute 3018, the Object Class isIdentificationScheme-Agency 3030, the Property is Identification 3042,the Representation/Association is Identifier 3054, the Type is xsd 3066,the Datatype is token 3078, and the Length is between one to sixty 3087.The Cardinality between the CCT Identifier 3000 and schemeAgencyID 3006is zero or one 3092. The schemeAgencyID attribute 3006 may be optional(see 3097).

SchemeAgencySchemeID 3008 identifies the identification scheme thatrepresents the context that is used to identify the agency. ForschemeAgencySchemeID, the Category is Attribute 3020, the Object Classis IdentificationScheme-Agency 3032, the Property is Scheme 3044, theRepresentation/Association is Identifier 3056, the Type is xsd 3068, theDatatype is token 3080, and the Length is from one to sixty 3088. TheCardinality between CCT Identifier 3000 and schemeAgencySchemeID 3008 iszero or one 3093. The SchemeAgencySchemeID attribute 3008 may beoptional (see 3098).

SchemeAgencySchemeAgencyID 3010 identifies the agency that manages theSchemeAgencySchemeID. This attribute can contain values from DE 3055(excluding roles). For SchemeAgencySchemeAgencyID, the Category isAttribute 3022, the Object Class is IdentificationScheme-Agency 3034,the Property is SchemeAgency 3046, the Representation/Association isIdentifier 3058, the Type is xsd 3070, the Data-type is token 3082, andthe Length is three 3089. The Cardinality between the CCT Identifier andSchemeAgencySchemeAgencyID 3010 is zero or one 3099. TheSchemeAgencySchemeAgencyID attribute 3010 may be optional (see 3099).

The CCT Identifier 3000 data type is used for elements or attributesthat are used in the communication between partners or systems to enableunique identification of logical or real objects. The number of typesshould not be limited, but continues to grow (e.g., ProductId, OrderId,. . . ). New IDs are continually added.

If the agency that manages the identification scheme is not explicitlyidentified, but is specified using a role, this is done in the tag name.

Standardized and proprietary identifiers can be represented. Forstandardized identifiers whose identification schemes are managed by anagency from the DE 3055 code list, schemeID 3002 identifies anidentification scheme for the standard identifier, schemeVersionID 3004identifies a version of the identification scheme, and schemeAgencyID3006 identifies an agency from DE 3055 (excluding roles). Forproprietary identifiers whose identification schemes are managed by anagency that is identified using a standard, schemeID 3002 identifies anidentification scheme for the proprietary identifier, schemeVersionID3004 identifies a version of the identification scheme, schemeAgencyID3006 identifies a standardized ID for the agency (normally the companythat manages the proprietary identifier), schemeAgencySchemeID 3008identifies an identification scheme for the schemeAgencyID, andschemeAgencySchemeAgencyID 3010 identifies an agency from DE 3055 thatmanages standardized ID ‘schemeAgencyID’. For proprietary identifierswhose identification schemes are managed by an agency that is identifiedwithout the use of a standard, schemeID 3002 identifies anidentification scheme for the proprietary identifier, schemeVersionID3004 identifies a version of the identification scheme, schemeAgencyID3006 identifies a proprietary ID for the agency (normally the companythat manages the proprietary identifier), schemeAgencySchemeID 3008identifies an identification scheme for the schemeAgencyID, andschemeAgencySchemeAgencyID 3010 identifies ‘ZZZ’ which is mutuallydefined from DE 3055.

For proprietary identifiers whose identification schemes are managed byan agency that is specified using a role or not at all, schemeID 3002identifies an identification scheme for the proprietary identifier andschemeVersionID 3004 identifies a version of the identification scheme.The role is specified as a prefix in the tag name. If there is more thanone identification scheme, schemeID 3002 and schemeVersionID 3004 can beused as attributes. No attributes are required if there is oneidentification scheme.

The representation term for the CCT “Identifier” is Identifier.

(g) Indicator

A CCT Indicator 3100 is the binary encoded specification of a fact thathas the value ‘0’ or ‘1’, i.e., ‘true’ or ‘false’. An example for theCCT Indicator 3100 is:

<Indicator>true</Indicator>.

The structure of CCT Indicator 3100 is depicted in FIG. 31. The Categoryfor CCT Indicator 3100 is simpleType 3102, the Property is Indicator3104, the Representation/Association is Content 3106, the Type is xsd3108, and the Type Name is Boolean 3110.

CCT Indicator 3100 can have either the value ‘true’ (‘1’) or ‘false’(‘0’). CCT Indicator 3100 is used for binary classifications,indicators, flags, and the like. The representation term for the CCT“Indicator” is Indicator.

(h) Measure

CCT Measure 3200 is a physical measure value with the correspondingmeasurement unit. One example of CCT Measure 3200 is <MeasureunitCode=“KG”>100</Measure>

The structure of Measure 3200 is depicted in FIG. 32. The Category forCCT Measure 3200 is complex Type 3204, the Property is Measure 3210, theRepresentation/Association is Content 3214, the Datatype is xsd: decimal3218, and the length is 13 predecimal digits and 6 decimal values.Measure 3200 also includes attribute unitCode 3202. For AttributeunitCode 3202, the Category is Attribute 3206, the Object Class isQuantity 3206, the Property is Unit 3212, the representation term isCode 3216, the Datatype is xsd: token 3220, the length is 1 to 3 3224,and the Cardinality is one 3226.

Positive and negative quantities can be used by using the built-in datatype “xsd: decimal.” Negative values may be prefixed with a negativesign (“−”). However, positive values do not require a positive sign “+”prefix. Measurement units are represented in the attribute “unitCode,”in accordance with UN/ECE Recommendation #20.

Measure is used for the representation of measure values with physicalsizes (meters, centimeters, kilograms). The Representation/Associationfor the CCT “Measure” is Measure.

Measure should not be confused with Quantity. In contrast to Measure,Quantity is used for the definition of quantity values or units.Quantities can on the one hand be piece sizes, such as packets,containers, and the like. but also physical sizes (meters, centimeters,kilograms).

(i) Numeric

A CCT Numeric 3300 is a decimal value. An example of the CCT Numeric3300 is:

<Numeric>123.345</Numeric>.

The structure of CCT Numeric 3300 is depicted in FIG. 33. The Categoryfor CCT Numeric 3300 is complexType 3302, the Property is Numeric 3304,the Representation/Association is Content 3306, and the Datatype is xsd:decimal 3308.

Positive and negative numeric values can be used by using the built-indata type “xsd: decimal.” Negative values may be prefixed with anegative sign (“−”). However, positive values do not require a positivesign “+” prefix. The decimal sign may be represented as a period (“.”).

The primary representation term for CCT Numeric 3300 is Numeric. Othersecondary representation terms are Value, Rate, and Percent.

In certain variations, CCT Numeric 3300 is not used for an indication ofquantity, measure or amount.

(j) Quantity

A CCT Quantity 3400 is a quantity with the corresponding quantity unit.An example of the CCT Quantity 3400 is: <QuantityunitCode=“CT”>100</Quantity>(CT=Carton).

The structure of CCT Quantity 3400 is depicted in FIG. 34. CCT Quantity3400 includes attribute unitCode 3402. For the CCT Quantity 3400, theCategory is Complex Type 3404, the Property is Quantity 3410, theRepresentation/Association is Content 3414, the Data Type is xsd:decimal 3418, and the Length is thirteen predecimal and six decimalplaces 3422.

For the Attribute unitCode 3402, the Category is Attribute 3406, theObject Class is Quantity 3406, the Property is Unit 3412, theRepresentation/Association is Code 3416, the Datatype is xsd: token3420, and the Length is from one to three 3424. The Cardinality betweenthe CCT Quantity 3400 and unitCode 3402 is one 3426. The attributeunitCode 3402 is mandatory (see 3428).

Positive and negative quantities can be used by using the built-in datatype “xsd: decimal.” Negative values may be prefixed with a negativesign (“−”). However, positive values do not require a positive sign “+”prefix. Measurement units are represented in the attribute “unitCode,”in accordance with UN/ECE Recommendation #20 or X12 355.

CCT Quantity 3400 is used for the representation of quantity values orunits. This can involve physical sizes (meters, centimeters, kilograms)or piece sizes, such as packets, containers, and the like. Therepresentation term for the CCT Quantity 3400 is Quantity.

CCT Quantity 3400 should not be confused with Measure. In contrast toQuantity, Measure is used for the definition of physical properties,such as sizes (temperature, lengths, and the like.) and weights of apart, product or article.

(k) Text

A CCT Text 3500 is a character string with an optional languagespecification. An example for CCT Text 3500 is: <TextlanguageCode=“DE”>Text is a character string with optional languagespecification.</Text>.

The structure of CCT Text 3500 is depicted in FIG. 35. CCT Text 3500includes Attribute languageCode 3502. For CCT Text 3500, the Category iscomplexType 3504, the Property is Text 3508, theRepresentation/Association is Content 3512, the Type is xsd 3516, theType Name is string 3520, and the Length is infinity 3524.

If the attachment is a document or text, languageCode 3502 can be usedto show the language of the attachment in accordance with IETF RFC 1766or IETF RFC 3066. For languageCode 3502, the Category is Attribute 3506,the Property is Language 3510, the Type is xsd 3518, the Type Name islanguage 3522, and the Length is from two to nine 3526. The Cardinalitybetween the CCT Text 3500 and languageCode 3502 is zero or one 3528.Attribute languageCode 3502 may be optional (see 3530).

The primary representation term for the CCT Text 3500 include Amount,BinaryObject, Code, DateTime, Identifier, Indicator, Measure, Numeric,Quantity, and Text. Additional secondary representation terms includeGraphic, Picture, Sound, Video, Date, Time, Value, Rate, Percent, andName. The character length for CCT Text 3500 is not defined.

(2) Global Data Types

(a) AcceptanceStatusCode

The GDT AcceptanceStatusCode 3600 is a coded representation of thestatus of the acceptance by a communication partner regarding a businesstransaction that has been transmitted to that partner. An example forGDT AcceptanceStatusCode 3600 is:

<AcceptanceStatusCode>AP</AcceptanceStatusCode>.

The structure of GDT AcceptanceStatusCode 3600 is depicted in FIG. 36.For GDT AcceptanceStatusCode 3600, the Property is Acceptance StatusCode 3602, the Representation/Association is Code 3604, the Type is CCT3606, the Type Name is Code 3608, and the Length is two 3610.AcceptanceStatusCode CCT 3600 may be restricted (see 3612).

The possible values for GDT AcceptanceStatusCode 3600 may be a selectionfrom the UN/EDIFACT code list DE 4343. Three codes that may be used areAP, AJ, and RE. AP means the business transaction transmitted by thecommunication partner has been accepted, AJ means a decision regardingthe business transaction transmitted by the communication partner hasnot (yet) been made, and RE means the business transaction transmittedby the communication partner has been rejected.

GDT AcceptanceStatusCode 3600 may be used as a business status insteadof as a technical acknowledgment of a message. GDT AcceptanceStatusCode3600 also may be used as an immediate response to individual messages inbilateral negotiation processes between communication partners.

In a variation, GDT AcceptanceStatusCode 3600 is a proprietary selectionfrom the UN/EDIFACT code list DE 4343. Addition of codes to thisselection from the code list may require the approval of the ProcessIntegration Council (PIC).

(b) AccountingObjectSet

A GDT AccountingObjectSet 3700 is a set of different account assignmentobjects. An account assignment object is a business object to whichchanges in value from business transactions may be assigned inaccounting. An example of GDT AccountingObjectSet 3700 is:<AccountingObjectSet>    <CostCenterID>CC1000</CostCenterID>   ........... </AccountingObjectSet>.

The structure of GDT AccountingObjectSet 3700 is depicted in FIG. 37.GDT AccountingObjectSet 3700 includes an element CostCenterID 3702. ForGDT AccountingObjectSet 3700, the Object Class is Accounting Object Set3706 and the Representation/Association is Details 3712.

For CostCenterID 3702, the Category is Element 3704, the Object Class isCost Center 3708, the Property is Identification 3710, theRepresentation/Association is identifier 3714, the Type is CCT 3716, theType is identifier 3718, and the Length is from one to thirty-two 3720.The Cardinality between the GDT AccountingObjectSet 3700 andCostCenterID 3702 is zero or one 3722.

The data type GDT AccountingObjectSet 3700 provides the identifier formultiple types of account assignment objects including cost center(organizational unit for which costs arise), sales order, project,asset, task, funds center, and profit center. Identifiers are optional,but at least one identifier may be specified.

The data type GDT AccountingObjectSet 3700 may be used for accountassignment, i.e., to assign an amount or quantity to a set of accountassignment objects. The amount or quantity is assigned to accountassignment objects of the GDT AccountingObjectSet 3700 according toaccounting rules. For example, expenses from the purchase of officematerials can be transferred to Accounting once the incoming invoice forthe materials has been checked and then assigned to a cost center CC1000and a profit center PC3050 there.

Applications that distribute an amount to several AccountingObjectSets(e.g., as percentages) may perform this distribution themselves andtransfer the partial amounts, each with a separate AccountingObjectSet,to accounting. An example of a percentage distribution to severalAccountingObjectSets is 40% to cost center CC1000 and profit centerPC3050, 20% to cost center CC2000 and task IO0815, and 40% to costcenter CC3000

(c) ActionCode

A GDT ActionCode 3802 is a coded representation of an instruction to therecipient of a message about how to process a transmitted businessobject.

An example for GDT ActionCode 3802 is: <Item actionCode=‘04’>   <ID>10</ID>    <!--... Further Elements ...--> </Item>

The structure of ActionCode 3802 is depicted in FIG. 38. For GDTActionCode 3802, the Property is Action 3804, theRepresentation/Association is Code 3806, the Type is CCT 3808, the TypeName is Code, and the Length is two 3812. GDT ActionCode 3802 may be arestricted GDT (see 3814).

In a variation, GDT ActionCode 3802 can have a value from 01 to 06. Thename for code 01 is Create and means that the element is to be createdat the recipient. The element does not exist at the recipient. Theelement ID and data is transferred. The name for code 02 is Change andmeans that the element is to be changed at the recipient. The elementexists at the recipient. The element ID and data is transferred. Thename for the code 03 is Delete and means the element is to be deleted atthe recipient. The element exists at the recipient. The element ID istransferred; data is transferred with the exception of elements that aremandatory due to their cardinality. The name for the code 04 is Save andmeans the element is to be saved at the recipient. The element can existat the recipient. If the element already exists there, it is changed. Ifit does not exist there, it is created. The name for code 05 is Removeand means the element is to be deleted at the recipient. The element canexist at the recipient. If it exists, it is deleted. The element ID istransferred; data is not transferred with the exception of elements thatare mandatory due to their cardinality. The name for code 06 is NoAction and means that no action is to be carried out for the element atthe recipient. The element exists at the recipient. The element ID anddata is transferred.

ActionCodes may be used under one another in a hierarchy of elements.The following table lists the combinations that may be allowed (X) andnot allowed (−). Parent ActionCode 01 02 03 04 05 06 Child 01 X X — X —— 02 — X — X — — 03 — X — X — — 04 X(1) X — X — X(2) 05 — X — X — — 06 —X — X — —

For the table above, note (1) indicates that the code can have themeaning of the code “01” (Create). Note (2) in the table indicates that,to ensure compatibility with regard to enhancements, code “04” (Save) isallowed because this code is the default code if no code is transferred.A sender preferably does not set this code. A recipient preferablyhandles this code as a code “06” (No Action).

Also, regarding the table above, no further codes occur under code “03”(Delete) or “05” (Remove) because, apart from the element ID, no furtherdata is transferred. A recipient checks the existence of an elementusing the rules described for the individual codes and generates anerror if necessary. A recipient checks the validity of the codes in ahierarchy of elements according to the rules described and generates anerror if necessary. A recipient ignores elements and ActionCodestransferred under a code “03” (Delete) or “05 (Remove) and behaves as ifthese elements and ActionCodes had not been transferred. A syntax checkis allowed for these elements.

The actions requested at the recipient can have names that are typicallyused in the business context of a message, as long as this does notchange the semantics of the ActionCodes defined above. For example,“Annul” or “Cancel” can be used instead of “Delete”. An ActionCode is anattribute of the element to which it refers.

The ActionCodes “01” (Create), “02” (Change), “03” (Delete), and “06”(No Action) may model strict semantics that lead to errors at therecipient if the elements corresponding to the actions requested by thesender exist (“01”) or do not exist (“02”, “03”, “06”) at the recipient.Using strict semantics, therefore, may require that the sender have anduse information about the messages it has already sent. The ActionCodes“04” (Save) and “05” (Remove) model soft semantics that, in a variation,do not lead to errors if the respective elements do not exist at therecipient. These soft semantics, therefore, do not require that thesender have and use information about the messages it has already sent.In a variation, an ActionCode that is not filled in a message instanceor does not exist in an interface may be assumed to be “04” (Save). Thisensures compatibility when enhancing interfaces to include anActionCode.

In some messages, the action at the top level may be represented in thename of the message type rather than by an ActionCode. These messagesbehave semantically as if the ActionCode were at the level of thetransferred BusinessTransactionDocument (for example: a message of themessage type PurchaseOrderChangeRequest behaves semantically as if anActionCode “02” (Change) were specified at the PurchaseOrder level).

An ActionCode may be used with a CompleteTransmissionIndicator for theparent element. For information about the combined use ofCompleteTransmissionIndicator and ActionCode, see the description hereinfor the CompleteTransmissionIndicator. The ActionCode, can also be usedfor an element whose parent element does not have aCompleteTransmissionIndicator. In this case, the child elements of theparent element are transferred, not just the changed child elements.

The ActionCode may be used for elements that remain uniquelyidentifiable across several messages in a business process or that canonly occur once in a message (cardinality 0..1 or 1). If an elementcannot be clearly identified, it is documented explicitly when theActionCode is used.

In a variation, the ActionCodes “03” (Delete) and “05” (Remove) do notstipulate that the recipient delete the respective element physically.However, once the element has been deleted, the recipient applicationhandles further transmitted ActionCodes as if the element has beenphysically deleted. For example, in the case of the ActionCode “01”(Create), it is possible to create a new element with the sameidentification as the deleted element. Exceptions to this ActionCodebehavior are explained and documented in the corresponding descriptionof the interface or message type.

(d) ActiveIndicator

A GDT ActiveIndicator 3902 indicates whether an object is commerciallyactive and whether it can be used in a process or not. An example of GDTActiveIndicator 3902 is:

<ActiveIndicator>true</ActiveIndicator>.

The structure of GDT ActiveIndicator 3902 is depicted in FIG. 39. Forthe GDT ActiveIndicator 3902, the Property is Active Indicator 3904, theRepresentation/Association is Indicator 3906, and the Type is CCT:Indicator 3908. GDT ActiveIndicator 3902 can have values 1 (true) or 0(false). True means the object is active and false means the object isnot active.

GDT ActiveIndicator 3902 is used to label objects that can becommercially active or inactive, for example, sources of supply. In thecontext of an interface, there may be a description of which object theGDT ActiveIndicator 3902 refers to and what it means in terms ofbusiness.

(e) Address

A GDT Address 4000 a contains structured information about types ofaddresses. This information includes details about addressees, thepostal address, and the physical location and communication connections.

The structure of GDT Address 4000 a is depicted in FIG. 40. GDT Address4000 a includes elements OrganisationFormattedName 4002 a, PersonName4003 a, FunctionalTitleName 4004 a, DepartmentName 4005 a, Office 4006a, PhysicalAddress 4012 a, TaxJurisdictionCode 4036 a,TimeZoneDifferenceValue 4037 a, GeoCoordinates 4038 a, and Communication4039 a. For the GDT Address 4000 a, the Object Class is Address 4000 band the Representation/Association is Details 4000 c.

Within the global data type GDT Address 4000 a,OrganisationFormattedName 4002 a contains the name of an organization(for example, a company or corporate body) as a part of the address. Forexample, this might be the address of a business partner. ForOrganisatoinFormattedName 4002 a, the Category is Element 4002 b, theObject Class is Address 4002 c, the Property is Organisation FormattedName 4002 d, the Representation/Association is Name 4002 e, the Type isCCT 4002 f, the Type Name is text 4002 g, and the Length is from zero toforty 4002 h. The Cardinality between the GDT Address 4000 a andOrganisatoinFormattedName 4002 b is from zero to four 4003 i.OrganisationFormattedName may be restricted (see 4002 j).

PersonName 4003 a contains the parts of a natural person's name. ForPersonName 4003 a, the Category is Element 4003 b, the Object Class isAddress 4003 c, the Property is Person Name 4003 d, theRepresentation/Association is Person Name 4003 e, the Type is GDT 4003f, and the Type Name is Person Name 4003 g. The Cardinality between theGDT Address 4000 a and PersonName 4003 a is zero or one 4003 h.

FunctionalTitleName 4004 a contains the function of a contact person andcan be a part of the address of the contact person in the organization.For the FunctionalTitleName 4004 a, the Category is Element 4004 b, theObject Class is Address 4004 c, the Property is Functional Title Name4004 d, the Representation/Association is Name 4004 e, the Type is CCT4004 f, the Type Name is Text 4004 g, and the Length is from zero toforty 4004 h. The Cardinality between the GDT Address 4000 a andFunctionalTitleName 4004 a is zero or one 4004 i. FunctionalTitleNamemay be restricted (see 4004 j).

DepartmentName 4005 a contains the department of a contact person andcan be a part of the address of the contact person in the organization.For the DepartmentName 4005 a, the Category is Element 4005 b, theObject Class is Address 4005 c, the Property is Department Name 4005 d,the Representation/Association is Name 4005 e, the Type is CCT 4005 f,the Type Name is text 4005 g, and the Length is from zero to forty 4005h. The Cardinality between the GDT Address 4000 a and DepartmentName4005 a is zero or one 4005 i. DepartmentName may be restricted (see 4005j).

Office 4006 a contains information that describes the workingenvironment of a contact person as well as information for addressing oridentifying this person within the organization. For Office 4006 a, theCategory is Element 4006 b, the Object Class is Address 4006 c, theProperty is Office 4006 d, and the Representation/Association is Details4006 e. The Cardinality between the GDT Address 4000 a and Office 4006 ais zero or one 4006 f. Office can also comprise BuildingID 4007 a,FloorID 4008 a, RoomID 4009 a, InhouseMailID 4010 a, andCorrespondenceShortName 4011 a.

BuildingID 4007 a is the number or ID of the building in the address ofa contact person. For BuildingID 4007 a, the Category is Element 4007 b,the Object Class is Office 4007 c, the Property is BuildingIdentification 4007 d, the Representation/Association is Identifier 4007e, the Type is CCT 4007 f, the Type Name is identifier 4007 g, and theLength is from one to ten 4007 h. The Cardinality between the GDTAddress 4000 a and BuildingID 4007 a is zero or one 4007 i. BuildingIDmay be restricted (see 4007 j).

FloorID 4008 a refers to the floor of the building in the address of acontact person. For FloorID 4008 a, the Category is Element 4008 b, theObject Class is Office 4008 c, the Property is Floor Identification 4008d, the Representation/Association is Identifier 4008 e, the Type is CCT4008 f, the Type Name is Identifier 4008 g, and the Length is from oneto ten 4008 h. The Cardinality between the GDT Address 4000 a andFloorID 4008 a is zero or one 4008 i. FloorID may be restricted (see4008 j).

RoomID 4009 a specifies the room number in the address of a contactperson. For RoomID 4009 a, the Category is Element 4009 b, the ObjectClass is Office 4009 c, the Property is Room Identification 4009 d, theRepresentation/Association is Identifier 4009 e, the Type is CCT 4009 f,the Type Name is Identifier 4009 g, and the Length is from one to ten4009 h. The Cardinality between the GDT Address 4000 a and RoomID 4009 ais zero or one 4009 i. RoomID may be restricted (see 4009 j).

InhouseMailID 4010 a specifies an internal mail address. ForInhouseMailID 4010 a, the Category is Element 4010 b, the Object Classis Office 4010 c, the Property is Inhouse Identification 4010 d, theRepresentation/Association is Identifier 4010 e, the Type is CCT 4010 f,the Type Name is Identifier 4010 g, and the Length is from one to ten4010 h. The Cardinality between the GDT Address 4000 a and InhouseMailID4010 a is zero or one 4010 i. InHouseMailID may be restricted (see 4010j).

CorrespondenceShortName 4011 a is the short name of the contact personfor use in correspondence. This short name can be used both internallyand externally. For CorrespondenceShortName 4011 a, the Category isElement 4011 b, the Object Class is Office 4011 c, the Property isCorrespondence Short Name 4011 d, the Representation/Association is Name4011 e, the Type is CCT 4011 f, the Type Name is text 4011 g, and theLength is from zero to ten 4011 h. The Cardinality between the GDTAddress 4000 a and CorrespondenceShortName 4011 a is zero or one 4011 i.CorrespondenceShortName may be restricted (see 4011 j).

PhysicalAddress 4012 a contains the postal address data of a physicallocation. For the PhysicalAddress 4012 a, the Category is Element 4012b, the Object Class is Address 4012 c, the Property is Physical Address4012 d, and the Representation/Association is Details 4012 e. TheCardinality between the GDT Address 4000 a and PhysicalAddress 4012 a iszero or one 4012 f.

PhysicalAddress 4012 a also comprises CountryCode 4013 a, RegionCode4014 a, StreetPostalCode 4015 a, POBox PostalCode 4016 a,CompanyPostalCode 4017 a, CityName 4018 a, AdditionalCityName 4019 a,DistrictName 4020 a, POBoxID 4021 a, POBoxIndicator 4022 a,POBoxCountryCode 4023 a, POBoxRegionCode 4034 a, POBoxCityName 4035 a,StreetName 4036 a, StreetPrefixName 4037 a, StreetSuffixName 4038 a,HouseID 4039 a, AdditionalHouseID 4040 a, BuildingID 4041 a, FloorID4042 a, RoomID 4043 a, CareOfName 4044 a, and Description 4045 a. Foreach, the category is Element (4013 b-4045 b) and the Object Class isPhysical Address (4013 c-4045 c).

CountryCode 4013 a is the country code of the address in accordance withISO 3166-1. For the CountryCode 4013 a, the Property is CountryCode 4013d, the Representation/Association is Code 4013 e, the Type is GDT 4013f, and the Type Name is CountryCode 4013 g. The Cardinality between theGDT Address 4000 a and CountryCode 4013 a is zero or one 4013 h.

RegionCode 4014 a is the code for the region of the country in theaddress. This specification may be part of the address, e.g., in the US.For RegionCode 4014 a, the Property is RegionCode 4014 d, theRepresentation/Association is Code 4014 e, the Type is GDT 4014 f, andthe Type Name is RegionCode 4014 g. The Cardinality between the GDTAddress 4000 a and RegionCode 4014 a is zero or one 4014 h.

StreetPostalCode 4015 a is the zip code in the street address. The rulesfor zip codes are country-specific. For StreetPostalCode 4015 a, theProperty is Street Zip Code 4015 d, the Representation/Association isCode 4015 e, the Type is CCT 4015 f, the Type Name is Code 4015 g, andthe Length is from one to ten 4015 h. The Cardinality between GDTAddress 4000 a and StreetPostalCode 4015 a is zero or one 4015 i.StreetPostalCode 4015 a may be restricted (see 4015 j).

POBoxPostalCode 4016 a is the box zip code. For POBoxPostalCode 4016 a,the Property is PO Box Zip Code 4016 d, the Representation/Associationis Code 4016 e, the Type is CCT 4016 f, the Type Name is Code 4016 g,and the Length is from one to ten 4016 h. The Cardinality between GDTAddress 4000 a and POBoxPostalCode 4016 a is zero or one 4016 i.POBoxPostalCode 4016 a may be restricted (see 4016 j).

CompanyPostalCode 4017 a is the zip code of the company when thereceiver is an organization with its own zip code. For CompanyPostalCode4017 a, the Property is Company Zip Code 4017 d, theRepresentation/Association is Code 4017 e, the Type is CCT 4017 f, theType Name is Code 4017 g, and the Length is from one to ten 4017 h. TheCardinality between GDT Address 4000 a and CompanyPostalCode 4017 a iszero or one 4017 i. CompanyPostalCode 4015 a may be restricted (see 4017j).

CityName 4018 a is the name of the city in the address. For the CityName4018 a, the Property is City Name 4018 d, the Representation/Associationis Name 4018 e, the Type is CCT 4018 f, the Type Name is Text 4018 g,and the Length is from zero to forty 4018 h. The Cardinality between GDTAddress 4000 a and CityName 4018 a is zero or one 4018 i. CityName 4018a may be restricted (see 4018 j).

AdditionalCityName 4019 a is the name of the city of residence if itdiffers from the city in the postal address. AdditionalCityName may havedifferent semantics (field HOME_CITY in the ADRC) and therefore may notbe handled using Cardinality. It is analogous to AdditionalHouseID. ForAdditionalCityName 4019 a, the Property is Additional City Name 4019 d,the Representation/Association is Name 4019 e, the Type is CCT 4019 f,the Type Name is Text 4019 g, and the Length is from zero to forty 4019h. The Cardinality between the GDT Address 4000 a and AdditionalCityName4019 a is zero or one 4019 i. AdditionalCityName 4019 a may berestricted (see 4019 j).

DistrictName 4020 a is the name of the district. For DistrictName 4020a, the Property is District Name 4020 d, the Representation/Associationis Name 4020 e, the Type is CCT 4020 f, the Type Name is Text 4020 g,and the Length is from zero to forty 4020 h. The Cardinality between theGDT Address 4000 a and DistrictName 4020 a is zero or one 4020 i.DistrictName 4020 a may be restricted (see 4020 j).

POBoxID 4021 a is the number of the post-office box. For POBoxID 4021 a,the Property is PO Box Identification 4021 d, theRepresentation/Association is Identifier 4021 e, the Type is CCT 4021 f,the Type Name is Identifier 4021 g, and the Length is from one to ten4021 h. The Cardinality between the GDT Address 4000 a and POBoxID 4021a is zero or one 4021 i. CityName 4021 a may be restricted (see 4021 j).

POBoxIndicator 4022 a specifies whether the post-office box has a numberthat is unknown. For POBoxIndicator 4018 a, the Property is PO BoxIndicator 4018 d, the Representation/Association is Indicator 4018 e,the Type is CCT 4018 f, and the Type Name is Indicator 4018 g. TheCardinality between GDT Address 4000 a and POBoxIndicator 4022 is zeroor one 4018 h.

POBoxCountryCode 4023 a is the country code for the post-office box inthe address. For POBoxCountryCode 4023 a, the Property is PO Box CountryCode 4023 d, the Representation/Association is Code 4023 e, the Type isGDT 4023 f, and the Type Name is CountryCode 4023 g. The Cardinalitybetween GDT Address 4000 a and POBoxCountryCode 4023 a is zero or one4023 h.

POBoxRegionCode 4024 a is the code for the region of the country for thepost-office box in the address. For the POBoxRegionCode 4024 a, theProperty is PO Box Region Code 4024 d, the Representation/Association isCode 4024 e, the Type is GDT 4024 f, and the Type Name is Region Code4024 g. The Cardinality between GDT Address 4000 a and POBoxRegionCode4024 a is zero or one 4024 h.

POBoxCityName 4025 a is the name of the city for the post-office box inthe address. For the POBoxCityName 4025 a, the Property is PO Box Cityname 4025 d, the Representation/Association is Name 4025 e, the Type isCCT 4025 f, the Type Name is Text 4025 g, and the Length is from zero toforty 4025 h. The Cardinality between GDT Address 4000 a andPOBoxCityName 4025 a is zero or one 4025 i. POBoxCityName 4025 a may berestricted (see 4025 j).

StreetName 4026 a is the name of the street in the address. For theStreetName 4026 a, the Property is Street name 4026 d, theRepresentation/Association is Name 4026 e, the Type is CCT 4026 f, theType Name is Text 4026 g, and the Length is from zero to sixty 4026 h.The Cardinality between GDT Address 4000 a and StreetName 4026 a is zeroor one 4026 i. POBoxCityName 4026 a may be restricted (see 4026 j).

StreetPrefixName 4027 a is an additional prefix in the address andprecedes the street name in the previous line. For the StreetPrefixName4027 a, the Property is Street Prefix Name 4027 d, theRepresentation/Association is Name 4027 e, the Type is CCT 4027 f, theType Name is Text 4027 g, and the Length is from zero to forty 4027 h.The Cardinality between GDT Address 4000 a and StreetPrefixName 4027 ais from zero to two 4027 i. StreetPrefixName 4027 a may be restricted(see 4027 j)

StreetSuffixName 4028 a is an additional suffix in the address and comesafter the street name in the subsequent line. For the StreetSuffixName4028 a, the Property is Street Suffix Name 4028 d, theRepresentation/Association is Name 4028 e, the Type is CCT 4028 f, theType Name is Text 4028 g, and the Length is from zero to forty 4028 h.The Cardinality between GDT Address 4000 a and StreetSuffixName 4028 ais from zero to two 4028 i. StreetPrefixName 4028 a may be restricted(see 4028 j).

HouseID 4029 a is the house number for the street in the address. Forthe HouseID 4029 a, the Property is House Identification 4029 d, theRepresentation/Association is Identifier 4029 e, the Type is CCT 4029 f,the Type Name is Identifier 4029 g, and the Length is from one to ten4029 h. The Cardinality between GDT Address 4000 a and HouseID 4029 a iszero or one 4029 i. HouseID 4029 a may be restricted (see 4029 j).

AdditionalHouseID 4030 a is an addition to the house number, e.g.,apartment number. For the AdditionalHouseID 4030 a, the Property isAdditional House Identification 4030 d, the Representation/Associationis Identifier 4030 e, the Type is CCT 4030 f, the Type Name isIdentifier 4030 g, and the Length is from one to ten 4030 h. TheCardinality between GDT Address 4000 a and AdditionalHouseID is zero orone 4030 i. AdditionalHouseID 4030 a may be restricted (see 4030 j).

BuildingID 4031 a is the number or abbreviation for a building, e.g.,WDF03. For the BuildingID 4030 a, the Property is BuildingIdentification 4030 d, the Representation/Association is Identifier 4030e, the Type is CCT 4030 f, the Type Name is Identifier 4030 g, theLength is from one to twenty 4030 h. The Cardinality between GDT Address4000 a and BuildingID 4031 a is zero or one 4030 i. BuildingID 4030 amay be restricted (see 4030 j).

FloorID 4032 a is the number of the floor in the building. For theFloorID 4032 a, the Property is Floor Identification 4032 d, theRepresentation/Association is Identifier 4032 e, the Type is CCT 4032 f,the Type Name is Identifier 4032 g, and the Length is from one to ten4032 h. The Cardinality between GDT Address 4000 a and FloorID 4032 a iszero or one 4032 i. FloorID 4032 a may be restricted (see 4032 j).

RoomID 4033 a is the number of the room in the building. For the RoomID4033 a, the Property is Room Identification 4033 d, theRepresentation/Association is Identifier 4033 e, the Type is CCT 4033 f,the Type Name is Identifier 4033 g, and the Length is from one to ten4033 h. The Cardinality between GDT Address 4000 a and RoomID 4033 a iszero or one 4033 i. RoomID 4033 a may be restricted (see 4033 j).

CareOfName 4034 a is a different receiver when the receiver is not thesame as the addressee. For the CareofName 4034 a, the Property is Careof name 4034 d, the Representation/Association is Name 4034 e, the Typeis CCT 4034 f, the Type Name is Text 4034 g, and the Length is from zeroto ten 4034 h. The Cardinality between the GDT Address 4000 a andCareOfName 4034 a is zero or one 4034 i. CareofName 4034 a may berestricted (see 4034 j).

Description 4035 a is an addition to the address that refers to anyspecial details. For the Description 4030 a, the Property is Description4030 d, the Representation/Association is Text 4030 e, the Type is GDT4030 f, and the Type Name is Description 4030 g. The Cardinality betweenGDT Address 4000 a and Description 4035 a is unbounded 4030 h.

TaxJurisdictionCode 4036 a is the tax jurisdiction code belonging to theaddress. This code is used in various countries and can normally bederived uniquely from the address. However, it is dependent on the codelist of the provider. A country can have multiple code-list providers.For the TaxJurisdictionCode 4036 a, the Category is Element 4036 b, theObject Class is Address 4036 c, the Property is Tax Jurisdiction Code4036 d, the Representation/Association is Code 4036 e, the Type is GDT4046 f, and the Type Name is TaxJurisdictionCode 4036 g. The Cardinalitybetween the GDT Address 4000 a and TaxJurisdictionCode 4036 a is zero orone 4036 h.

TimeZoneDifferenceValue 4037 a is the difference (in hours) between thelocal time zone of the location defined by PhysicalAddress 4012 a andUTC (Coordinated Universal Time). For the TimeZoneDifferenceValue 4037a, the Category is Element 4037 b, the Object Class is Address 4037 c,the Property is Time Zone Difference Value 4037 d, theRepresentation/Association is Value 4037 e, the Type is GDT 4037 f, andthe Type Name is TimeZoneDifferenceValue 4037 g. The Cardinality betweenthe GDT Address 4000 a and TimeZoneDifference Value 4037 a is zero orone 4037 h.

GeoCoordinates 4038 a contains the geographic data, i.e., longitude andlatitude, specified in accordance with the WGS84 reference system, withwhich a location on the globe can be determined. LatitudeMeasure is thegeographic latitude in degrees. LongitudeMeasure is the Geographiclongitude in degrees. The measurement unit degrees for each is specifiedby the attribute “unitCode” Southern latitudes are generally negativeand northern latitudes are generally positive. Also, western longitudesare negative and eastern longitudes are positive. Positive values do notrequire a positive sign (+) for a prefix. However, negative values mayhave a negative sign (−) for a prefix. The unitCode “DD” corresponds tothe unit for the degree of an angle (UN/CEFACT Rec. #20). For theGeoCoordinates 4038 a, the Category is Element 4038 b, the Object Classis Address 4038 c, the Property is GeoCoordinates 4038 d, theRepresentation/Association is GeoCoordinates 4038 e, the Type is GDT4038 f, and the Type Name is GeoCoordinates 4038 g. The Cardinalitybetween the GDT Address 4000 a and GeoCoordinates 4038 a is zero or one4038 h.

Communication 4049 a contains information about communication paths withwhich a person or organization can be reached. For the Communication4049 a, the Category is Element 4049 b, the Object Class is Address 4049c, the Property is Communication 4049 d, and theRepresentation/Association is Details 4049 e. The Cardinality betweenthe GDT Address 4000 a and Communication 4049 is zero or one 4049 f.Communication 4049 a is comprised of CorrespondenceLanguageCode 4040 a,Telephone 4042 a, MobilePhone 4047 a, Facsimile 4052 a, email 4058 a,and Web 4063 a.

CorrespondenceLanguageCode 4040 a specifies the language for writtencorrespondence. For CorrespondenceLanguageCode 4040 a, the Category isElement 4040 b, the Object Class is Communication 4040 c, the Propertyis Correspondence Language Code 4040 d, the Representation/Associationis Code 4040 e, the Type is GDT 4040 f, and the Type Name isLanguageCode 4040 g. The Cardinality may be zero or one 4040 h.

Telephone 4042 a contains one telephone number in each instance. ForTelephone 4042 a, the Category is Element 4042 b, the Object Class isCommunication 4042 c, the Property is Telephone 4042 d, and theRepresentation/Association is Details 4042 e. The Cardinality betweenthe GDT Address 4000 a and Telephone 4042 a is unbounded 4042 f.Telephone is comprised of Number 4043 a, NumberDefaltIndicator 4044 a,NumberDescription 4045 a, and NumberUsageDenialIndicator 4046 a.

For Number 4043 a, the Category is Element 4043 b, the Object Class istelephone 4043 c, the Property is Phone Number 4043 d, theRepresentation/Association is Phone Number 4043 e, the Type is GDT 4043f, and the Type Name is Phone Number 4043 g. The Cardinality between theGDT Address 4000 a and Number 4043 a is one 4043 h.

NumberDefaultIndicator 4044 a indicates whether a telephone number isthe default number for the address. In certain variations, there may bea default telephone number, provided the address contains a telephonenumber. The default value is “false.” For NumberDefaultIndicator 4044 a,the Category is Element 4044 b, the Object Class is Telephone 4044 c,the Property is Number Default Indicator 4044 d, theRepresentation/Association is Indicator 4044 e, the Type is CCT 4044 f,and the Type Name is Indicator 4044 g. The Cardinality between the GDTAddress 4000 a and NumberDefaultIndicator 4044 a is one 4044 h.

NumberDescription 4045 a is an addition to the telephone number thatrefers to special details or that contains other unstructuredinformation. For NumberDescription 4045 a, the Category is Element 4045b, the Object Class is telephone 4045 c, the Property is NumberDescription 4045 d, the Representation/Association is Text 4045 e, theType is GDT 4045 f, and the Type Name is Description 4045 g. TheCardinality between the GDT Address 4000 a and NumberDescription 4045 ais unbounded 4045 h.

NumberUsageDenial 4046 a indicates whether the telephone number may beused or not. If this indicator is set to “true,” this means that, inaccordance with the legal requirements of the respective country, thetelephone number may not be used. There are exceptions, however. Forexample, return calls requested by the business partner or calls madefor service purposes may still be permitted. Furthermore, it isadvisable to save telephone numbers so that calls from business partnerscan still be identified, even if this indicator is set. The default is“false.” For NumberUsageDenial 4046 a, the Category is Element 4046 b,the Object Class is telephone 4046 c, the Property is Number UsageDenial Indicator 4046 d, the Representation/Association is Indicator4046 e, the Type is CCT 4046 f, and the Type Name is Indicator 4046 g.The Cardinality between the GDT Address 4000 a and NumberUsageDenial4046 a is one 4046 h.

MobilePhone 4047 a contains a mobile phone number in each instance. ForMobilePhone 4047 a, the Category is Element 4047 b, the Object Class isCommunication 4047 c, the Property is Mobile Phone 4047 d, and theRepresentation/Association is Details 4047 e. The Cardinality betweenthe GDT Address 4000 a and MobilePhone 4047 a is unbounded 4047 f.MobilePhone 4047 a is also comprised of Number 4048 a,NumberDefaultIndicator 4049 a, NumberDescription 4050 a, andNumberUsageDenialIndicator 4051 a.

For Number 4048 a, the Category is Element 4048 b, the Object Class isMobilephone 4048 c, the Property is Phone Number 4048 d, theRepresentation/Association is Phone Number 4048 e, the Type is GDT 4048f, and the Type Name is Phone Number 4048 g. The Cardinality between theGDT Address 4000 a and Number 4048 a is one 4048 h.

NumberDefaultIndicator 4049 a indicates whether a mobile phone number isthe default mobile phone number for the address. In certain variations,there may be a default mobile phone number, provided the addresscontains a mobile phone number. For NumberDefaultIndicator 4049 a, theCategory is Element 4049 b, the Object Class is Mobilephone 4049 c, theProperty is Number Default Indicator 4049 d, theRepresentation/Association is Indicator 4049 e, the Type is CCT 4049 f,and the Type Name is Indicator 4049 g. The Cardinality between the GDTAddress 4000 a and NumberDefaultIndicator 4049 a is one 4049 h.

NumberDescription 4050 a is an addition to the mobile phone number thatrefers to special details or that contains other unstructuredinformation. For NumberDescription 4050 a, the Category is Element 4050b, the Object Class is Mobilephone 4050 c, the Property is NumberDescription 4050 d, the Representation/Association is Text 4050 e, theType is GDT 4050 f, and the Type Name is Description 4050 g. TheCardinality between the GDT Address 4000 a and NumberDescription 4050 ais unbounded 4050 h.

NumberUsageDenialIndicator 4051 a indicates whether the mobile phonenumber may be used or not. If this indicator is set to “true,” thismeans that, in accordance with the legal requirements of the respectivecountry, the mobile phone number may not be used. There are exceptions,however. For example, return calls requested by the business partner orcalls made for service purposes may still be permitted. Further, mobilephone numbers may be saved so that calls from business partners and thelike can still be identified, even if the indicator is set. ForNumberUsageDenial 4051 a, the Category is Element 4051 b, the ObjectClass is Mobilephone 4051 c, the Property is Number Usage DenialIndicator 4051 d, the Representation/Association is Indicator 4051 e,the Type is CCT 4051 f, and the Type Name is Indicator 4051 g. TheCardinality between the GDT Address 4000 a andNumberUsageDenialIndicator 4051 a is one 4051 h.

Facsimile 4052 a contains a fax number in each instance. For Facsimile4052 a, the Category is Element 4052 b, the Object Class isCommunication 4052 c, the Property is Facsimile 4052 d, and theRepresentation/Association is Details 4052 e. The Cardinality betweenthe GDT Address 4000 a and Facsimile 4052 a is unbounded 4052 f.Facsimile 4052 a is also comprised of Number 4053 a,NumberDefaultIndicator 4054 a, NumberDescription 4055 a, andNumberUsageDenialIndicator 4056 a.

For Number 4053 a, the Category is E 4053 b, the Object Class isFacsimile 4053 c, the Property is Phone Number 4053 d, theRepresentation/Association is Phone Number 4053 e, the Type is GDT 4053f, the Type Name is Phone Number 4053 g, and the Cardinality between theGDT Address 4000 a and Number 4053 a is one 4053 h.

NumberDefaultIndicator 4054 a indicates whether a fax number is thedefault number for the address. In certain variations, there is adefault fax number, provided the address contains a fax number. ForNumberDefaultIndicator 4054 a, the Category is Element 4054 b, theObject Class is Facsimile 4054 c, the Property is Number DefaultIndicator 4054 d, the Representation/Association is Indicator 4054 e,the Type is CCT 4054 f, and the Type Name is Indicator 4054 g. TheCardinality between the GDT Address 4000 a and NumberDefaultIndicator4054 a is one 4054 h.

NumberDescription 4055 a is an addition to the fax number that refers tospecial details or that contains other unstructured information. ForNumberDescription 4055 a, the Category is Element 4055 b, the ObjectClass is Facsimile 4055 c, the Property is Number Description 4055 d,the Representation/Association is Text 4055 e, the Type is GDT 4055 f,and the Type Name is Description 4055 g. The Cardinality between the GDTAddress 4000 a and NumberDescription 4055 a is unbounded 4055 h.

NumberUsageDenial 4056 a indicates whether the fax number may be used ornot. If this indicator is set to “true,” this means that, in accordancewith the legal requirements of the respective country, the fax numbermay not be used. There are exceptions, however. For example, responsefaxes requested by the business partner or faxes sent for servicepurposes and the like may still be permitted. Furthermore, it isadvisable to save fax numbers so that faxes sent by business partnersand the like can still be identified, even if the indicator is set. ForNumberUsageDenial 4056 a, the Category is Element 4056 b, the ObjectClass is Facsimile 4056 c, the Property is Number Usage Denial Indicator4056 d, the Representation/Association is Indicator 4056 e, the Type isCCT 4056 f, and the Type Name is Indicator 4056 g. The Cardinalitybetween the GDT Address 4000 a and NumberUsageDenial 4056 a is one 4056h.

Email 4058 a contains an email address in each instance. For Email 4058a, the Category is Element 4058 b, the Object Class is Communication4058 c, the Property is Email 4058 d, and the Representation/Associationis Details 4058 e. The Cardinality between the GDT Address 4000 a andEmail 4058 a is unbounded 4058 h. Email 4058 also comprises Address 4059a, AddressDefaultIndicator 4060 a, AddressDescription 4061 a, andAddressUsageDenialIndicator 4062 a.

Address 4059 a specifies the email address. For Address 4059 a, theCategory is Element 4059 b, the Object Class is Email 4059 c, theProperty is Email Address 4059 d, the Representation/Association isEmail Address 4059 e, the Type is GDT 4059 f, and the Type Name is EmailAddress 4059 g. The Cardinality between the GDT Address 4000 a andAddress 4059 a is one 4053 h.

AddressDefaultIndicator 4060 a indicates whether an email address is thedefault email address for this address. There may be a default emailaddress, provided there are any email addresses for this address. ForAddressDefaultIndicator 4060 a, the Category is Element 4060 b, theObject Class is Email 4060 c, the Property is Email Address DefaultIndicator 4060 d, the Representation/Association is Indicator 4060 e,the Type is CCT 4060 f, and the Type Name is Indicator 4060 g. TheCardinality between the GDT Address 4000 a and AddressDefaultIndicator4060 a is one 4060 h.

AddressDescription 4061 a is an addition to the email address thatrefers to special details or that contains other unstructuredinformation. For AddressDescription 4061 a, the Category is Element 4061b, the Object Class is Email 4061 c, the Property is Email AddressDescription 4061 d, the Representation/Association is Text 4061 e, theType is GDT 4061 f, and the Type Name is Description 4061 g. TheCardinality between the GDT Address 4000 a and AddressDescription 4061 ais unbounded 4061 h.

AddressUsageDenialIndicator 4062 a indicates whether the e-mail addressmay be used or not. If this indicator is set to “true,” this means that,in accordance with the legal requirements of the respective country, theemail address may not be used. There are exceptions, for example,responses to email enquiries may still be permitted. Furthermore, emailaddresses may be saved so that emails sent by business partners and thelike can still be identified, even if the indicator is set. ForAddressUsageDenialIndicator 4062 a, the Category is Element 4062 b, theObject Class is Email 4062 c, the Property is Email address Usage DenialIndicator 4062 d, the Representation/Association is Indicator 4062 e,the Type is CCT 4062 f, and the Type Name is Indicator 4062 g. TheCardinality between the GDT Address 4000 a andAddressUsageDenialIndicator 4062 a is one 4062 h.

Web 4063 a contains a Web address in each instance. For Web 4063 a, theCategory is Element 4063 b, the Object Class is Communication 4063 c,the Property is Web 4063 d, and the Representation/Association isDetails 4063 e. The Cardinality between the GDT Address 4000 a and Web4063 a is unbounded 4063 f. Web 4063 a is also comprised of Address 4064a, AddressDefaultIndicator 4065 a, and AddressDescription 4066 a.

Address 4064 a specifies the URI of a Web site. The length is longenough to accommodate a generated URI. For Address 4064 a, the Categoryis Element 4064 b, the Object Class is Web 4064 c, the Property is WebAddress 4064 d, the Representation/Association is Address 4064 e, theType is GDT 4064 f, and the Type Name is Web Address 4064 g. TheCardinality between the GDT Address 4000 a and Address 4064 a is one4064 h.

AddressDefaultIndicator 4065 a indicates whether a Web address is thedefault Web address for this address. There may be a default Webaddress, provided the address contains a Web address. ForAddressDefaultIndicator 4065 a, the Category is Element 4065 b, theObject Class is Web 4065 c, the Property is Address Default Indicator4065 d, the Representation/Association is Indicator 4065 e, the Type isCCT 4065 f, and the Type Name is Indicator 4065 g. The Cardinalitybetween the GDT Address 4000 a and AddressDefaultIndicator 4065 a is one4065 h.

Address Description 4066 a is an addition to the Web address that refersto special details or that contains other unstructured information. ForAddressDescription 4066 a, the Category is Element 4066 b, the ObjectClass is Web 4066 c, the Property is Address Description 4066 d, theRepresentation/Association is Text 4066 e, the Type is GDT 4066 f, andthe Type Name is Description 4066 g. The Cardinality between the GDTAddress 4000 a and Address Description 4066 a is unbounded 4066 h.

An example of GDT Address 4000 a is:  <Address>  <OrganisationFormattedName>Systems, Applications   andProducts</OrganisationFormattedName>   <OrganisationFormattedName>inData Processing</OrganisationFormattedName>   <PersonName>   <FormattedName>Mr. Paul John Tester</FormattedName>   <LegalName>Paul John Tester</LegalName>    <GivenName></GivenName>   <PreferredGivenName>Paul</PreferredGivenName>   <MiddleName>John</MiddleName>    <Family>    <FamilyName>Tester</FamilyName>    <PrimaryIndicator>true</PrimaryIndicator>    <FamilyNamePrefix></FamilyNamePrefix>    </Family>    <Affix>    <AffixName>Mr.</AffixName>     <AffixCode>FormOfAddress</AffixCode>   </Affix>   </PersonName>   <FunctionalTitleName>SalesManager</FunctionalTitleName>   <DepartmentName>SalesDepartment</DepartmentName>   <Office>    <BuildingID>WDF01</BuildingID>   <FloorID>2</FloorID>    <RoomID>G2.01</RoomID>    <InhouseMailID>SCMIBD 2</ InhouseMailID >   <CorrespondenceShortName>TeP</CorrespondenceShortName>   </Office>  <PhysicalAddress>    <CountryCode>MX</CountryCode>   <RegionCode>DIF</RegionCode>   <StreetPostalCode>01210</StreetPostalCode>   <CityName>Mexico</CityName>    <DistrictName> Santa Fé</DistrictName>   <StreetName>Piso Col Pena Blanca</StreetName>   <StreetPrefixName>Edificio Plaza Reforma Santy Fé</StreetPrefixName>   <StreetPrefixName>Prologacion Paseo de la Reforma</StreetPrefixName>   <HouseID>No 600-2°</HouseID>   </PhysicalAddress>  <TaxJurisdictionCode listID=“,” listVersionID=“,” listAgencyID =“,” listAgencySchemeID=  “,”listAgencySchemeAgencyID=““>123456789101112 </TaxJurisdictionCode>  <TimeZoneDifferenceValue>+08:00</TimeZoneDifferenceValue>  <GeoCoordinates>    <LatitudeMeasureunitCode=“DD”>40.23232300000</LatitudeMeasure>    <LongitudeMeasureunitCode=“DD”>123.12121200000</LongitudeMeasure>   </GeoCoordinates>  <Communication>    <Telephone>     <TelephoneNumber>     <AreaID>6227</AreaID>      <SubscriberID>7</SubscriberID>     <ExtensionID>47474</ExtensionID>      <CountryCode>DE</CountryCode>     </TelephoneNumber>    <TelephoneNumberDefaultIndicator>1 </TelephoneNumberDefaultIndicator>     <Description></ Description>    <UsageDenialIndicator>0</UsageDenialIndicator>    </Telephone>   <MobilePhone>     <MobilePhoneNumber>      <AreaID>170</AreaID>     <SubscriberID>1234567</SubscriberID>     <ExtensionID></ExtensionID>      <CountryCode>DE</ CountryCode>    </MobilePhoneNumber>     <MobilePhoneNumberDefaultIndicator>1 </MobilePhoneNumberDefaultIndicator>     <Description></Description>    <UsageDenialIndicator>0</UsageDenialIndicator>    </MobilePhone>   <Facsimile>     <FacsimileNumber>      <AreaID>6227</AreaID>     <SubscriberID>78</SubscriberID>     <ExtensionID>99999</ExtensionID>      <CountryCode>DE</CountryCode >     </FacsimileNumber>    <FacsimileNumberDefaultIndicator>1 </FacsimileNumberDefaultIndicator>    <Description>Secretary</Description>    <UsageDenialIndicator>0</UsageDenialIndicator>    </Facsimile>   <EmailAddress>paul.tester@sap.com</EmailAddress> <EmailAddressDefaultIndicator>1</EmailAddressDefaultIndicator>    <Description></Description>    <UsageDenialIndicator>0</UsageDenialIndicator>    <Web>    <WebAddress>www.sap.com</WebAddress> <WebAddressDefaultIndicator>1</WebAddressDefaultIndicator>    <Description>Official information</Description>    </Web>  </Communication>  </Address>.

This example address produces the following result, which can be printedout for a label:

Systems, Applications and Products

in Data Processing

Mr. Paul John Tester

Sales Manager

Edificio Plaza Reforma Santa Fé

Prolongacion Paseo de la Reforma

No 600-2° Piso Col Pena Blanca

Santa Fé 01210

Mexico, DIF.

Note that some fields, such as TaxJurisdictionCode andTimeZoneValueDifference, may not be used even if they have beencompleted. If BuyerParty is an organization then PersonName may beempty. If BuyerParty is a natural person then OrganisationFormattedNamemay be empty.

The addresses of technical objects, which describe a physical location,are represented by an appropriate field selection, e.g., the address ofthe organization without OrganisationFormattedName and Communication.

(f) AdjustmentReasonCode

The GDT AdjustmentReasonCode 4100 is a coded representation for thereason for an adjustment. An example of GDT AdjustmentReasonCode 4100is:

<AdjustmentReasonCode>CANCELED_PROMOTION</AdjustmentReasonCode>.

The structure of GDT AdjustmentReasonCode 4100 is depicted in FIG. 41.

The illustrative code is general and can be used in many contexts. Thestandard code list to be used in an interface depends on the particularcontext. In a variation, a standard code list is used. If an interfacesupports one of the lists or if the supported code lists aredisjunctive, none of the attributes may be required for identificationof the particular standard code lists.

For the use of GDTs in revisions of forecast time series, the possiblecode values are subsets of the “Adjustment Reason Code List” of the“EAN.UCC XML Business Message Standards, version 1.3 (July 2003).” Theseinclude CANCELED_PROMOTION, DISCONTINUED_PRODUCT, DISTRIBUTION_ISSUE,EXPANDED_PROMOTION, FORWARD_BUY, INVENTORY_POLICY_CHANGE, NEW_LOCATION,NEW_PRODUCT, NEW_PROMOTION, ORDER_POLICY_CHANGE, OVERSTOCK_CONDITION,PRICE_CHANGE, PRODUCT_CHANGEOVER, PRODUCTION_ISSUE, REDUCED_PROMOTION,REVISED_PLAN, REVISED_PROMOTION, STORE_CLOSURE, TRANSPORTATION_ISSUE andWEATHER_RELATED_EVENT. For each use of the above, the context and codelist used may be documented.

(g) AllowedIndicator

A GDT AllowedIndicator 4200 indicates whether something, such as aspecific procedure, operation or status, is allowed or not. An exampleof GDT AllowedIndicator 4200 is:<LowerCaseAllowedIndicator>true</LowerCaseAllowedIndicator>.

The structure of GDT Allowed Indicator 4200 is depicted in FIG. 42. Forthe GDT Allowed Indicator 4200, the Property is Allowed 4202, theRepresentation/Association is Indicator 4204, the Type is CCT 4206, andthe Type Name is Indicator 4208.

The GDT AllowedIndicator 4200 can have the values true or false. Truemeans that something is allowed while false means that something is notallowed. For each GDT AllowedIndicator 4200, what is allowed or notallowed may be indicated precisely. This is reflected in an appropriatename prefix. For example, a NegativeValueAllowedIndicator specifieswhether negative numeric values are allowed, while aLowerCaseAllowedIndicator specifies whether lower-case letters areallowed.

The GDT AllowedIndicator 4200 may be used to indicate whether a customeris allowed to submit an online purchase order in lower-case letters. Inthe context of an interface, the business significance of “what isallowed” may be described for the AllowedIndicator in addition to usingthe name prefix.

(h) Amount

A GDT Amount 4300 is an amount with the corresponding currency unit. Anexample of GDT Amount 4300 is: <OrderedAmount

currencyCode=“EUR”>777.95</OrderedAmount>.

The structure of GDT Amount 4300 is depicted in FIG. 43. For the GDTAmount 4300, the Property is Amount 4302, the Representation/Associationis Amount 4304, the Type is CCT 4306, and the Type Name is Amount 4308.

GDT Amount 4300 is used to represent amounts, costs, remunerations, andfees. The amount value in GDT Amount 4300 may be represented with amaximum of 22 predecimal places and 6 decimal places. Both positive andnegative amounts can be used. Amount 4300 may also include the attributecurrencyCode which refers to the currency unit in accordance with theISO 4217 three-character code. A currency may be specified.

(i) AmountBalanceIndicator

A GDT AmountBalanceIndicator 4400 indicates whether an amount is abalance or not. An example of GDT AmountBalanceIndicator 4400 is:

<AmountBalanceIndicator>true</AmountBalanceIndicator>.

The structure of GDT AmountBalanceIndicator 4400 is depicted in FIG. 44.For the GDT AmountBalanceIndicator 4400, the Property is Amount Balance4402, the Representation/Association is Indicator 4404, the Type is CCT4406, and the Type Name Indicator is 4408.

BalanceIndicator can have either the value true or false. True signifiesthat the amount specified is a balance. False signifies that the amountspecified is not a balance. GDT Amount 4400 can be used to indicatewhether the balance of all open receivables is transferred in a messageto a party or whether the amount transferred is an individualreceivable. A balance amount may also be positive or negative. In thecontext of an interface, the amount to which the GDT Amount 4400 refersand the business significance of the balance may be described.

(j) AspectID

A GDT AspectID 4500 is a unique identifier for an aspect. An aspectdetermines a selection of attributes relevant for the aspect for apredefined object type. An example of GDT AspectID 4500 is:<AspectID>DETAIL</AspectID>.

The structure of GDT AspectID 4500 is depicted in FIG. 45. For the GDTAspectID 4500, the Object Class is Aspect 4502, the Property isIdentification 4504, the Representation/Association is Identifier 4506,the Type is CCT 4508, the Type Name is Identifier 4510 and the length isfrom one to forty 4512.

In one variation, when a catalog is published, a GDT AspectID 4500 canbe used as the CatalogueItemAspectID to specify which properties (andtheir values) are to be displayed in the view for a catalog item. Forexample, in a product catalog, the “LIST” aspect contains those productproperties that are required to select a product from a list quickly.The “DETAIL” aspect contains all the properties, while the “COMPARISON”aspect contains those that are useful for comparing the details of twoproducts.

A distinction should also be made between an aspect and a “view.” A viewof a predefined object is a restriction of the object's attributes. Anaspect is a semantic criterion that is used to decide which attributesbelong to a particular object view. When a given aspect is applied tovarious object types, the result is a view. For this reason, an aspectusually has many different views.

(k) Attachment

A CCT Attachment 4600 is an arbitrary document type that is related toeither the whole message or just a particular part. An example of CCTAttachment 4600 is:

<Attachment id=“sampleAttachment.xml”>Some Attachment</Attachment>.

The structure of CCT Attachment 4600 is depicted in FIG. 46. The CCTAttachment 4600 includes attributes id 4612 and filename 4632. For theCCT Attachment 4600, the Property is Attachment 4602, theRepresentation/Association is Binary Object 4604, the Type is xsd 4606,the Type Name is normalizedString 4608. The CCT Attachment 4600 is Title4610.

Attribute id 4612 uniquely identifies the binary content within themessage that corresponds to the SOAP or ebXML messaging protocols. Forthe CCT Id 4612, the Category is Attribute 4614, the Object Class isAttachment 4616, the Property is Identification 4618, theRepresentation/Association is Identifier 4620, the Type is xsd 4622, theType Name is string 4624, the Length is from one to thirty five 4626,the Cardinality is one 4628. The CCT Id 4612 may be unique as used forreferences using the manifest 4630.

Attribute filename 4632 contains the relevant name or file name of thebinary content. The structure of CCT Filename 4632 is depicted in FIG.46. For the CCT Filename 4632, the Category is Attribute 4634, theObject Class is Attachment 4636, the Property is Filename 4638, theRepresentation/Association is Text 4640, the Type is xsd 4642, the TypeName is String 4644, the length is up to seventy 4646, and theCardinality is zero or one 4648.

The element value of CCT BinaryObject 4600 is based on theXML-scheme-specific built-in data type xsd: normalizedString and can beused to represent an intelligible title or name of the binary object.

The attachment may be sent in the same message in the form of a MIMEattachment. The technical referencing is done using the manifest of therespective message protocol (SOAP or ebXML messaging). The value fromthe “id” attribute is used as the referencing code. Every attachment mayhave this attribute and the identifiers may be unique in the samedocument instance.

Attachments are similar to the attachments in electronic messagetransfer (for example, STMP). The attachments may be documents that canbe read by humans, such as word-processing documents, spreadsheetdocuments, presentation documents, and the like. These documents can bein many different formats (e.g., doc, pdf, ppt, xls, and the like.).

The binary data streams of Attachment should not be stored on a Webserver as a file. The global data type “WebAddress” is available forthis purpose.

(l) AttachmentWebAddress

A CDT AttachmentWebAddress 4700 is a Web address for a document of anytype that is related to the transmitted message or part of the message,but is not itself transmitted as part of the message. An example of CDTAttachmentWebAddress 4700 is:

<AttachmentWebAddress>www.abc.com/Attachments/HelloWorld.txt</AttachmentWebAddress>.

The structure of CDT AttachmentWebAddress 4700 is depicted in FIG. 47.For the CDT Attachment Web Address 4700, the Object Class Qualificationis Attachment 4702, the Object Class is Web Address 4704, the Propertyis Address 4706, the Representation/Association is Electronic Address4708, the Type is GDT 4710, and the Type Name is Web Address 4712.

The specification of an CDT AttachmentWebAddress 4700 may support httpand https URI schemes. The CDT AttachmentWebAddress 4700 may also beused to transmit a link to an attachment, instead of transmitting theattachment itself. The recipient can use the transmitted link to accessthe attachment.

When using an CDT AttachmentWebAddress 4700 in an interface or GDT, howthe link is to be interpreted may be described. For example, as a simplelink to enable the user to display the attachment on the interface, as arequest to the recipient system to load the attachment from thespecified address as soon as possible, whether there are restrictions onhow long the attachment is available at the specified URL, or whetherand by whom the attachment can be changed.

(m) BatchID

A GDT BatchID 4800 is a unique identifier for one batch in the contextof a material number. Batches are non-reproducible, homogenous subsetsof a product, whose characteristics lie within the batch characteristicsdefined for the product. An example of GDT BatchID 4800 is:<BatchID>CH20021015</BatchID>.

The structure of GDT BatchID 4800 is depicted in FIG. 48. For the GDTBatchID 4800, the Category is Complex Type 4802, the Object Class isBatch 4804, the Property is Identification 4806, theRepresentation/Association is Identifier 4808, the Type is CCT 4810, theData Type is Identifier 4812, the Length is from one to ten 4814.

The GDT BatchID 4800 may comprise letters, numbers, and displayablespecial characters, with the possible exception of “*,” “&,” and “,”.The identifier may be uppercase and the GDT BatchID 4800 may not beginwith blank characters or contain consecutive blank characters. The GDTBatchID 4800 value range includes combinations of the permittedcharacters up to a maximum length of 10 characters.

SchemeID identifies an identification scheme. The identification schemerepresents the context that is used to identify an object. SchemeID maybe unique within the agency that manages this identification scheme. Thestructure of GDT schemeID 4816 is depicted in FIG. 48. For the GDTschemeID 4816, the Category is Attribute 4818, the Object Class isIdentification Scheme 4820, the Property is Identification 4822, theRepresentation/Association is Identifier 4824, the Type is xsd 3126, theData Type is Token 4828, the Cardinality is zero or one 4830. The GDTschemeID 4816 may be Optional 4832.

SchemeVersionID identifies the version of an identification scheme. Thestructure of GDT schemeVersionID 4834 is depicted in FIG. 48. For theGDT schemeVersionID 4834, the Category is Attribute 4836, the ObjectClass is Identification Scheme 4838, the Property is Version 4840, theRepresentation/Association is Identifier 4842, the Type is xsd 4844, theData Type is Token 4846, and the Cardinality is zero or one 4848. TheGDT schemeVersionID 4834 may be optional 4850.

SchemeAgencyID identifies the agency that manages an identificationscheme. The agencies from DE 3055 may be used as the default, but theroles defined in DE 3055 may not be used. GDT BatchID 4800 may be uniquewithin the identification scheme that is managed by schemeAgencyID. Forthe GDT schemeAgencyID 4852, the Category is Attribute 4854, the ObjectClass is IdentificationSchemeAgency 4856, the Property is Identification4858, the Representation/Association is Identifier 4860, the Type is xsd4862, the Data Type is Token 4864, and the Cardinality is zero or one4866. The GDT schemeAgencyID 4852 may be optional 4868.

SchemeAgencySchemeID identifies the identification scheme thatrepresents the context for agency identification. For the GDTschemeAgencySchemeID 4870, the Category is Attribute 4872, the ObjectClass is IdentificationSchemeAgency 4874, the Property is Scheme 4876,the Representation/Association is Identifier 4878, the Type is xsd 4880,the Data Type is Token 4882, and the Cardinality is zero or one 4884.The GDT schemeAgencySchemeID 4870 may be optional 4886.

SchemeAgencySchemeAgencyID identifies the agency that manages theSchemeAgencySchemeID. This attribute may contain values from DE 3055(excluding roles). For the GDT schemeAgencySchemeAgencyID 4888, theCategory is Attribute 4890, the Object Class isIdentificationSchemeAgency 4892, the Property is SchemeAgency 4894, theRepresentation/Association is Identifier 4896, the Type is xsd 4898, theData Type is Token 4899, and the Cardinality is zero or one 4801A. TheGDT schemeAgencySchemeAgencyID 4888 may be optional 4802A.

The GDT BatchID 4800 may be used to identify batches. Specifyingattributes may be optional. By default, the system may assume that thebatch identified by the GDT BatchID 4800 is a manufacturer batch andtherefore no attributes are required.

(n) BiddingConditionCode

The GDT BiddingConditionCode 4900 is a coded representation of thebidding conditions for a bid invitation property. An example of GDTBiddingConditionCode 4900 is:<QuoteQuantityBiddingConditionCode>01</QuoteQuantityBiddingConditionCode>.

The structure of GDT Bidding Condition Code 4900 is depicted in FIG. 49.For the GDT Bidding Condition Code 4900, the Object Class is Bidding4902, the Property is Condition 4904, the Representation/Association isCode 4906, the Type is CCT 4908, the Type Name is Code 4910, and theLength is two 4912.

The GDT BiddingConditionCode 4900 may have the values 01 through 04. 01means that a bid is mandatory for a bid invitation property, and theproperty valuation may not be changed. 02 means a bid is mandatory for abid invitation property, and the property valuation can be changed. 03means a bid may be optional for a bid invitation property, and theproperty valuation cannot be changed. 04 means a bid may be optional fora bid invitation property, and the property valuation can be changed

Illustrative bid invitation properties for which bidding conditions canbe specified may include quantity, price, and terms of delivery. Whenthe GDT BiddingConditionCode 4900 is applied to a bid invitationproperty, it is identified in the prefix, e.g.,QuoteQuantityBiddingConditionCode. A default procedure should bespecified for each usage of a GDT BiddingConditionCode 4900.

The GDT BiddingConditionCode 4900 may be a proprietary code list withfixed predefined values. Changes to the permitted values may involvechanges to the interface.

(o) BusinessDocumentMessageHeader

A GDT BusinessDocumentMessageHeader 5000 comprises business informationfrom the perspective of the sender application for identifying abusiness document within a message (if applicable, with a reference to aprevious instance of a business document within a previous message),information about the sender, and any information about the receiver. Anexample of GDT BusinessDocumentMessageHeader 5000 is: <PurchaseOrderRequest>   <MessageHeader>    <IDschemeID=“INVOIC”>00000000123456</ID>    <ReferenceIDschemeID=“ORDER”>00000000123455</ReferenceID>   <CreationDateTime>2003-10-21T12:21Z+01:00</ID>    <SenderParty>    <StandardID schemeAgencyID=“016”>4711</StandardID>    <ContactPerson>      <InternalID schemeID=“PartyID”schemeAgencyID=“MPL_002”>820</InternalID>      <Address>...</Address>    </ContactPerson>    </SenderParty>    <RecipientParty>    <InternalID schemeID=“PartyID”schemeAgencyID=“BPL_300”>747</InternalID>     <ContactPerson>     <InternalID schemeID=“PartyID”schemeAgencyID=“BPL_300”>737</InternalID>      <Address>...</Address>    </ContactPerson>    </RecipientParty>   </MessageHeader>   .... </PurchaseOrderRequest>.

The structure of GDT Business Document Message Header 5000 is depictedin FIG. 50. The GDT Business Document Message Header 5000 includeselements ID 5010, ReferenceID 5028, CreationDateTime 5046, SenderParty5062, and RecipientParty 5078. For the GDT Business Document MessageHeader 5000, the Object Class is Business Document Message 5002, theProperty is Header 5004, the Representation/Association is Details 5006,the Type is GDT 5008.

ID 5010 is the identifier for the instance of the business documentwithin a (technical) message that is generated by the businessapplication level at the sender. For the ID 5010, the Category isElement 5012, the Object Class is Business Document Message 5014, theProperty is Identification 5016, the Representation/Association isIdentifier 5018, the Type is GDT 5020, the Type Name is BusinessDocument Message ID 5022, the Length is from one to thirty-five 5024,and Cardinality is zero or one 5026.

ReferenceID 5028 is the identifier of another instance of a businessdocument in another (technical) message that the BusinessDocumentreferences (a BusinessDocument can link to anotherBusinessDocumentMessage to represent a business interrelation or adependency). For the Reference ID 5028, the Category is Element 5030,the Object Class is Business Document Message 5032, the Property isReference Identification 5034, the Representation/Association isIdentifier 5036, the Type is GDT 5038, the Type Name is BusinessDocument Message ID 5040, the Length is from one to thirty-five 5042,and the Cardinality is zero or one 5044.

CreationDateTime 5046 is a date and time stamp (to the second) for whena message is created for the business document within the businessapplication. For the GDT Creation Date Time 5046, the Category isElement 5048, the Object Class is Business Document Message 5050, theProperty is Creation Date Time 5052, the Representation/Association isDate Time 5054, the Type is GDT 5056, the Type Name is Date Time 5058,the Cardinality is one 5060.

SenderParty 5062 is the party that creates and sends theBusinessDocument at business application level. SenderParty contains aunique sender identification. The identifiers contained in SenderPartycan also be used for internal forwarding at application level. Thecontact person in it contains the necessary direct contact informationin case there are problems or errors during processing of the respectiveBusinessDocument. For the GDT Sender Party 5062, the Category is Element5064, the Object Class is Business Document Message 5066, the Propertyis Sender 5068, the Representation/Association is Party 5070, the Typeis GDT 5072, the Type Name is Business Document Message Header Party5074, the Cardinality is zero or one 5076.

RecipientParty 5078 is the party that receives and processes theBusinessDocument at business application level. RecipientParty maycontain a unique receiver identification. The identifiers contained inRecipientParty can also be used for internal forwarding at applicationlevel. The contact person in it contains the contact information in casethere are problems or errors during processing of the respectiveBusinessDocument. The structure of GDT Recipient Party 5078 is depictedin FIG. 50. For the GDT Recipient Party 5078, the Category is Element5080, the Object Class is Business Document Message 5082, the Propertyis Recipient 5084, the Representation/Association is Party 5086, theType is GDT 5088, the Type Name is Business Document Message HeaderParty 5090, the Cardinality is from zero to n 5092.

BusinessDocuments used for B2B scenarios may use the GDTBusinessDocumentMessageHeader 5000. If required, GDTBusinessDocumentMessageHeader 5000 can also be used in BusinessDocumentsintended for A2A scenarios.

GDT BusinessDocumentMessageHeader 5000 may be used for numerouspurposes. For example, GDT BusinessDocumentMessageHeader 5000 may beused for forwarding to the relevant position or target person within abusiness application, for tracing and monitoring of a BusinessDocumentand its processing status at business application level, and formanaging and monitoring business processes.

GDT BusinessDocumentMessageHeader 5000 may also be used foradministration and error handling. The unique identification can be usedfor referencing and in the case of errors at business application level,the contact person in SenderParty or RecipientParty can be contacteddirectly. The name, telephone number, e-mail address, fax number, andthe like. can be transmitted by the GDT BusinessDocumentMessageHeader5000 for this purpose.

GDT BusinessDocumentMessageHeader 5000 may also be used for convertinggeneral information to other standards, such as IDoc, UN/CEFACT, ANSIX.12, ODETTE, TRADACOMMS, xCBL, OAG BODs, and RosettaNet-PIPs. These arestandards that represent reference data for the business applicationlevel according to predefined conventions. In a variation, this may beguaranteed if the general header information of a BusinessDocument isidentical to the envelope or header information of the respectivedefault message.

The ReferenceID is used to represent references that originate from thesuccession of BusinessDocuments in the BusinessDocument choreography.This may include query/response or request/confirmation messages. Therespective interface document may identify the previous BusinessDocumentto which the ReferenceID refers, i.e., what the reference specified bythe BusinessDocument reference means.

Comparing GDT BusinessDocumentMessageHeader 5000 to the headerinformation from the message transfer protocols such as “ReliableMessaging,” “OASIS ebXML MSG,” “OASIS ebXML CPP/CPA,” and “Rosetta NetRNIF 2.0,” demonstrates that the GDT BusinessDocumentMessageHeader 5000may contain redundant information compared to these technical transferprotocols. However, the GDT BusinessDocumentMessageHeader 5000 may beused at business application level instead of at a technical level. Theinformation in this case is information that can be sent, received, andprocessed at this level.

GDT BusinessDocumentMessageHeader 5000 may be based on UN/CEFACTStandard BusinessDocumentMessage Header Technical Specification—WorkingDraft—Revision 2.2.5” dated 26 Nov. 2003. The ID(BusinessDocumentMessageID) of the GDT BusinessDocumentMessageHeader5000 may be distinguishable from the technical Messaged (the XImessage). Specifically the BusinessDocumentMessageID is issued by thebusiness application and is stable over the entire lifetime of theBusinessDocument. It also remains unchanged even when the message issent via multiple, successive middleware systems. The technical Messagedis issued at the level of the technical middleware system and generallychanges each time the BusinessDocument is resent or forwarded by amiddleware system and when the BusinessDocument is split into multipletechnical messages by a middleware system.

(p) BusinessDocumentMessageHeaderParty

A GDT BusinessDocumentMessageHeaderParty 5100 is information about aparty that is responsible for sending or receiving a BusinessDocument ata business application level. GDT BusinessDocumentMessageHeaderParty5100 contains the necessary general business information about aninvolved sender or receiver party. A party is typically a naturalperson, organization, or business partner group in which a company has abusiness or intra-enterprise interest. This could be a person,organization, or group within or outside of the company. An example ofGDT BusinessDocumentMessageHeaderParty 5100 is:  <PurchaseOrderRequest>  <MessageHeader>    <SenderParty>     <StandardIDschemeAgencyID=“016”>4711</StandardID>     <ContactPerson>     <InternalID schemeID=“PartyID”schemeAgencyID=“MPL_002”>820</InternalID>      <Address>...</Address>    </ContactPerson>    </SenderParty>    <RecipientParty>    <InternalID schemeID=“PartyID”schemeAgencyID=“BPL_300”>747</InternalID>     <ContactPerson>     <InternalID schemeID=“PartyID”schemeAgencyID=“BPL_300”>737</InternalID>      <Address>...</Address>    </ContactPerson>    </RecipientParty>    ...   </MessageHeader>  ....  </PurchaseOrderRequest>.

In the above example, for SenderParty, schemeAgencyID=“016” cancorrespond to Dun & Bradstreet according to the code list DE 3055. ForRecipientParty: schemeID=“PartyID” specifies that the scheme “PartyID”was used to identify the party. schemeAgencyID=“BPL_(—)300” specifiesthat the scheme was assigned by the SAP CMDM system “BPL_(—)300.”

The structure of GDT Business Document Message Header Party 5100 isdepicted in FIG. 51. For the GDT Business Document Message Header Party5100, the Object Class is Business Document Message Header Party 5102and the Property is Details 5104.

InternalID 5106 refers to the proprietary identifier used whenSenderParty or RecipientParty use common master data (ExtendedEnterprise) or when they are in alignment with regard to the semanticsand use of InternalID. For the GDT Internal ID 5106, the Category isElement 5108, the Object Class is Business Document Message Header Party5110, the Property is Internal Identification 5112, theRepresentation/Association is Identifier 5114, the Type is GDT 5116, theType Name is Party Internal ID 5118, and the Cardinality is zero or one5120.

StandardID 5122 refers to the standardized identifier for SenderParty orRecipientParty of the organization based on the code list DE 3055. Forthe GDT Standard ID 5122, the Category is Element 5124, the Object Classis Business Document Message Header Party 5126, the Property is StandardIdentification 5128, the Representation/Association is Identifier 5130,the Type is GDT 5132, the Type Name is Party Standard ID 5134, and theCardinality is from zero to n 5136.

ContactPerson refers to the contact person of the party. For the GDTContact Person 5138, the Category is Element 5140, the Object Class isBusiness Document Message Header Party 5142, the Property is ContactPerson 5144, the Representation/Association is Contact Person 5146, theType is GDT 5148, the Type Name is Contact Person 5150, and theCardinality is zero or one 5152.

The GDT BusinessDocumentMessageHeaderParty 5100 may be used in theBusinessDocumentMessageHeader of a BusinessDocument. This GDT is meantfor defining the SenderParty or RecipientParty. The different IDs of aGDT BusinessDocumentMessageHeaderParty 5100 may identify the same party.

A party may be identified using an InternalID or Standard ID. InternalIDis when SenderParty and RecipientParty use common master data or are inalignment with regard to the semantics and use of InternalID. StandardIDis when SenderParty and RecipientParty can manage standardizedidentifiers. Of all of the IDs available to the SenderParty, generallythose IDs the RecipientParty is expected to understand are used in aBusinessDocument. Either company-internal ID or a standardized ID can beused for identification.

GDT BusinessDocumentMessageHeaderParty 5100 can be used for the detailsand identification of the sender or recipient of a BusinessDocument.Furthermore, additional information about the contact person, includingaddress, can be defined, which makes it possible to contact this persondirectly should any problems or errors occur when validating orprocessing the inbound BusinessDocument.

(q) BusinessDocumentMessageID

A GDT BusinessDocumentMessageID 5200 may be a unique identifier of abusiness document in a message that is issued by the sender businessapplication. An example of GDT BusinessDocumentMessageID 5200 is:<PurchaseOrderRequest>    <MessageHeader>       <ID         schemeID=“ORDER”          schemeAgencyID=“124224”         schemeAgencySchemeAgencyID=“12232344”>          00000000000001      </ID>       ...    </MessageHeader>    ....</PurchaseOrderRequest>.

The structure of GDT Business Document Message ID 5200 is depicted inFIG. 52. For the GDT Business Document Message ID 5200, the Category isComplex Type 5202, the Object Class is Business Document Message 5204,the Property is Identification 5206, the Representation/Association isIdentifier 5208, the Type is CCT 5210, the Type Name is Identifier 5212,the Length is from one to thirty-five 5214. The GDT Business DocumentMessage ID 5200 may be a restricted GDT.

SchemeID 5218 identifies an identification scheme. These identificationschemes may be provided by a code list, such as the SAP MessageTypes.The “schemeID” attribute is not required if the GDTBusinessDocumentMessageID 5200 is unique within a schemeAgencyID. Forthe GDT Scheme ID 5218, the Category is Attribute 5220, the Object Classis Identification Scheme 5222, the Property is Identification 5224, theRepresentation/Association is Identifier 5226, the Type is xsd 5228, theType Name is Token 5230, the Length is from one to sixty 5232, and theCardinality is zero or one 5234.

SchemeAgencyID 5236 may be covered by the agency ID of the sender. Ifthis agency manages multiple business systems, the schemeAgencyIDcontains the unique identification of the respective business systemfrom which the BusinessDocument was sent. For the GDT Scheme Agency ID5236, the Category is Attribute 5238, the Object Class is IdentificationScheme Agency 5240, the Property is Identification 5242, theRepresentation/Association is Identifier 5244, the Type is xsd 5246, theType Name is Token 5248, and the Length is from one to sixty 5250. TheCardinality between the GDT BusinessDocumentMessageID 5200 andSchemeAgencyID is zero or one 5252.

SchemeAgencySchemeAgencyID contains the unique identification of theagency that manages the schemeAgencyID. This attribute may containvalues from DE 3055 (excluding roles). This attribute is not required ifthis information comes unequivocally from the sender.

The format of GDT BusinessDocumentMessageID 5200 identification is asequential number comprising a maximum of 35 characters. The number maybe positive. This representation complies with the UN/EDIFACTconventions (see DE 0340 (Interactive Message Reference Number)).

The GDT BusinessDocumentMessageID 5200 is a unique identification for atleast the entire lifetime of a BusinessDocument. The identification isgenerated by the respective business application of the creator and, ina variation, may not be created or interpreted by the technical messagetransfer systems.

The technical MessageID depends on the respective technical transferprotocol and may not be associated with the GDTBusinessDocumentMessageID 5200. When a technical message is sent, theBusinessDocument is the payload in the message. The MessageID can changeas a result of the forwarding mechanisms of the respective middlewaresystems or the different transfer protocols used.

In the inbound direction, mapping can be performed to the in-housemessage code. In the outbound direction, there are various scenarios. Ifa Sender is known because it is given by SenderParty, schemeID 5202identifies the message type. If a Sender is unknown because it is notgiven by SenderParty and Identification of business level at the senderis standardized, then schemeID 5202 identifies the message type,schemeAgencyID 5204 identifies the standardized ID for the agency thatgenerates the MessageID, and schemeAgencySchemeAgencyID 5206 identifiesthe agency from DE 3055 that manages the standardized ID schemeAgencyId.If a Sender is unknown because it is not given by SenderParty andidentification of business level at the sender is proprietary, thenschemeID 5202 identifies the message type, schemeAgencyID 5204identifies the proprietary ID for the agency that generates theMessageID, and schemeAgencySchemeAgencyID 5206 identifies ‘ZZZ’ which ismutually defined from DE 3055.

If a Sender has multiple business systems that are unique within anagency (for example: System Landscape Directory), then schemeID 5202identifies the message type and schemeAgencyID 5204 identifies theunique ID of the business system that may be unique within an agency. Inthis scenario, uniqueness is ensured by the sender and the Sender is notrequired in internal communication.

(r) BusinessTransactionBlockedIndicator

A GDT BusinessTransactionBlockedIndicator 5300 indicates whether or notthe execution of a business transaction is blocked. An example of GDTBusinessTransactionBlockedIndicator 5300 is:

<DeliveryExecutionBlockedIndicator>true</DeliveryExecutionBlockedIndicator>.

The structure of GDT Business Transaction Blocked Indicator 5300 isdepicted in FIG. 53. For the GDT Business Transaction Blocked Indicator5300, the Object Class is Business Transaction 5302, the Property isBlocked Indicator 5304, the Representation/Association is Indicator5306, the Type is CCT 5308, and the Type Name is Indicator 5310.

GDT BusinessTransactionBlockedIndicator 5300 may have the value true orfalse. True indicates that the execution of a business transaction isblocked. False indicates that the execution of a business transaction isnot blocked.

The GDT BusinessTransactionBlockedIndicator 5300 can be used in variousenvironments, such as in delivery and in billing. In a deliveryenvironment, this data type is used by a requesting application (e.g.,Sales) to send a delivery request to Supply Chain Execution (e.g., forplanning purposes) at an early stage, but, at the same time, to informSupply Chain Execution that the delivery should not be executed yetsince several points still have to be clarified with the customer,necessary papers are missing, or the customer's credit limit has beenexceeded or has not yet been checked.

In a billing environment, this data type is used by a requestingapplication (e.g., Sales) to set up a billing due list in billing but,at the same time, to specify that billing may not yet be executed. It ispossible that the requesting application first executes a releaseprocedure, that the customer-specific prices have not yet beendetermined, that certain necessary documents have not yet been received(letter of credit procedure), or that the customer's credit limit hasbeen exceeded.

(s) CompletedIndicator

A GDT CompletedIndicator 5400 indicates whether an object is completedin a business sense or not. GDT CompletedIndicator 5400 may relate tobusiness translations (for example, invoice creation, delivery,sourcing) or to objects that have the character of a transaction (forexample, product catalog transfer in multiple steps). An example of GDTCompletedIndicator 5400 is:<CompletedIndicator>false</CompletedIndicator>.

The structure of GDT CompletedIndicator 5400 is depicted in FIG. 54. ForGDT CompletedIndicator 5400, the Property is Completed Indicator 5402,the Representation/Association is Indicator 5404, the Type is CCT 5406,and the Type Name is Indicator 5408.

The GDT CompletedIndicator 5400 can have the values true or false. Trueindicates that an object is completed. False indicates that an object isnot completed.

The GDT CompletedIndicator 5400 is used to indicate that the processingof an object has been completed, even if further processing steps arebeing run in a different context (for example, sourcing for arequirement may be completed but procurement of the requirement callsfor further process steps). In various variations, for various objects aCompletedIndicator or a CancelledIndicator can be used depending onwhether it is desired to emphasize that processing of the object hasbeen completed properly (CompletedIndicator) or that the object has beencanceled in the sense of an exception situation (CancelledIndicator).

From the context of the interface in which a GDT CompletedIndicator 5400is used, the object to which the CompletedIndicator refers is described,its business significance is described, and whether a setCompletedIndicator can be undone in a follow-on message is described.

(t) BusinessTransactionDocumentGroupID

A GDT BusinessTransactionDocumentGroupID 5500 may uniquely identify agroup of business documents that are to be considered as one groupwithin a business process. An example of GDTBusinessTransactionDocumentGroupID 5500 is:

<DeliveryGroupID>4711</DeliveryGroupID>.

The structure of GDT Business Transaction Document Group ID 5500 isdepicted in FIG. 55. For the GDT Business Transaction Document Group ID5500, the Object Class is Business Transaction Document 5502, theProperty is Group Identification 5504, the Representation/Association isIndicator 5506, the Type is CCT 5508, the Type Name is Identifier 5510,the Length is from one to ten 5512. The GDT Business TransactionDocument Group ID 5500 may be a restricted GDT.

GDT BusinessTransactionDocumentGroupID 5500 is used to identifydocuments that belong together to enable them to be processed togetherby the application. “BusinessTransactionDocument” is replaced by thedescription of each document in the XML instance, e.g., “PurchaseOrder”for a purchase order, “Delivery” for a delivery, and the like.

(u) BusinessTransactionDocumentID

A GDT BusinessTransactionDocumentID 5600 is a unique identifier for adocument in a business transaction. An example for GDTBusinessTransactionDocumentID 5600 is:

<OrderID schemeID=‘Orders’

schemeAgencyID=‘123456789’schemeAgencySchemeAgencyID=‘16’>5400000012</OrderID>whichassigns the identifier 5400000012 to the OrderID having an “Orders”identification scheme, “123456789” as the agency managing theidentification scheme, and 16 as the identification scheme thatrepresents the context that is used to identify the agency.

The structure of GDT Business Transaction Document ID 5600 is depictedin FIG. 56. For the GDT Business Transaction Document ID 5600, theObject Class is Business Transaction Document 5602, the Property isIdentification 5604, the Representation/Association is Identifier 5606,the Type is CCT 5608, the Type Name is Identifier 5610, and the Lengthis from one to thirty-five 5612. The GDT Business Transaction DocumentID 5600 may be a restricted GDT.

For the GDT Scheme ID 5616, the Category is Attribute 5618, the ObjectClass is Identification Scheme 5620, the Property is Identification5622, the Representation/Association is Identifier 5624, the Type is xsd5626, the Type Name is Token 5628, and the Length is from one to sixty5630. The Cardinality is zero or one 5632.

For the GDT Scheme Agency ID 5634, the Category is Attribute 5636, theObject Class is Identification Scheme Agency 5638, the Property isIdentification 5640, the Representation/Association is Identifier 5642,the Type is xsd 5644, the Type Name is Token 5646, the Length is fromone to sixty 5648, and the Cardinality is zero or one 5650.

For the GDT Scheme ID 5616, the Category is Attribute 5618, the ObjectClass is Identification Scheme 5620, the Property is Identification5622, the Representation/Association is Identifier 5624, the Type is xsd5626, the Type Name is Token 5628, and the Length is from one to sixty5630. The Cardinality is zero or one 5632.

For the GDT Scheme Agency Scheme ID 5652, the Category is Attribute5654, the Object Class is Identification Scheme Agency 5656, theProperty is Scheme 5658, the Representation/Association is Identifier5660, the Type is xsd 5662, the Type Name is Token 5664, and the Lengthis from one to sixty 5666. The Cardinality is zero or one 5668.

For the GDT Scheme Agency ID 5670, the Category is Attribute 5672, theObject Class is Identification Scheme Agency 5674, the Property isScheme Agency 5676, the Representation/Association is Identifier 5678,the Type is xsd 5680, the Type Name is Token 5682, and the Length isthree 5684. The Cardinality is zero or one 5686.

A business process uses GDT BusinessTransactionDocumentID 5600 touniquely identify a document, such as a purchase order or an invoice ina business transaction. A partner uses a GDTBusinessTransactionDocumentID 5600 to inform another partner of theidentification of a business transaction document in an initial step,e.g., when creating data for the business transaction or sending it forthe first time. The second partner can use this identifier to referencethe business transaction document in the subsequent process.

In a variation, there may be no standardized IDs for transaction data.The attributes schemeID, schemeAgencyID, schemeAgencySchemeID, andschemeAgencySchemeAgencyID are used in the same way as for the CCTIdentifier to define the context for which a GDTBusinessTransactionDocumentID 5600 is guaranteed to be unique.

In the XML instance, “BusinessTransactionDocument” is replaced by thedescription of the respective document, e.g., “PurchaseOrder” for apurchase order, “Delivery” for a delivery, and the like.

(v) BusinessTransactionDocumentItemGroupID

A GDT BusinessTransactionDocumentationGroupID 5700 uniquely identifies agroup of business document items that are to be characterized as a groupwithin a business document. An example of GDTBusinessTransactionDocumentationGroupID 5700 is:

<DeliveryItemGroupID>123</DeliveryItemGroupID>.

The structure of GDT Business Transaction Document Item Group ID 5700 isdepicted in FIG. 57. For the GDT Business Transaction Document ItemGroup ID 5700, the Object Class is Business Transaction Document Item5702, the Property is Group Identification 5704, theRepresentation/Association is Identifier 5706, the Type is CCT 5708, theType Name is Identifier 5710, and the Length is three 5712. The GDTBusiness Transaction Document Item Group ID 5700 may be restricted.

A freely-definable numeric sequence may be used for display purposes. Ina variation, it is a 3-digit, numeric text field. Leading zeros are alsodisplayed. However, according to the current definition in R/3 in theprocessing applications “order” and “delivery,” a 3-figure, numeric textfield (NUMC3) having a freely-definable 3-character string using thecharacter set {“0,” “1,” “2,” “3,” “4,” “5,” “6,” “7,” “8,” “9”} may beused. Otherwise, a corresponding mapping may be necessary, but it mightnot be unique due to the use of a larger number of characters. In thiscase, the uniqueness may have to be ensured explicitly. Thisrequirement, however, may not be ensured explicitly per definition/datatype and therefore may be documented.

The GDT BusinessTransactionDocumentationGroupID 5700 is used to indicatethe items of a business document that belong together for a uniqueidentification of this item grouping in subsequent steps. For example,delivery groups are used to check the availability of materials that maybe delivered together. Items that belong to the same delivery group maybe delivered at the same time. Therefore, from the point of view of theavailability check, the products/materials selected in the highlighteditems may be available in sufficient quantities at the same time on therequested date so that the requirement can be fulfilled.

In the XML instance, the “BusinessTransactionDocument” is replaced bythe description of the respective document, e.g., “PurchaseOrder” for apurchase order, “Delivery” for a delivery, and the like.

(w) BusinessTransactionDocumentItemHierarchyRelationshipTypeCode A CDTBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 5800 is acoded representation of the business type of a hierarchical relationshipbetween items of a BusinessTransactionDocument. An example of CDTBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 5800 in thecontext of a purchase order item is:

<HierarchyRelationshipTypeCode>001</HierarchyRelationshipTypeCode>.

The structure of CDT Business Transaction Document Item HierarchyRelationship Type Code 5800 is depicted in FIG. 58. For the CDT BusinessTransaction Document Item Hierarchy Relationship Type Code 5800, theObject Class Qualification is Business Transaction Document ItemHierarchy 5802, the Object Class is Relationship 5804, the Property isType Code 5806, the Representation/Association is Code 5808, the Type isGDT 5810, the Type is Relationship Type Code 5812, and the Length isthree 5814. The CDT Business Transaction Document Item HierarchyRelationship Type Code 5800 may be restricted.

The GDT BusinessTransactionDocumentItemHierarchyRelationshipTypeCode5800 is based on the GDT ObjectStructureRelationshipTypeCode. Elementsof type BusinessTransactionDocumentItemHierarchyTypeCode can have values001, 002, 003, or 006. 001 means that the relationship is a bill ofmaterial relationship, 002 means the relationship is a groupingrelationship (one object in this relationship is part of a logicalgrouping to another object), 003 means the relationship is a discount inkind relationship, and 006 means the relationship is a substitutionproduct relationship.

The CDT BusinessTransactionDocumentItemHierarchyRelationshipTypeCode5800 is used together with a ParentItemID to map item hierarchies. Anitem hierarchy is a tree of subordinated items, where theBusinessTransactionDocumentHierarchyRelationshipTypeCode 5800 describesthe meaning of the hierarchical level of an item.

When using the CDTBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 5800, whichtypes of lower-level items are permitted in each use context and whichintegrity conditions apply to items in a hierarchy of a particular CDTBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 5800 may beexplicitly defined. In particular, it may be specified how hierarchieswith differentBusinessTransactionDocumentItemHierarchyRelationshipTypeCodes can becombined with each other. For example: When a bill of material hierarchyand a grouping hierarchy exist for one item, and when a groupinghierarchy exists for an item.

In a variation, there may be one hierarchy for each item, that is, thesame CDT BusinessTransactionDocumentItemHierarchyRelationshipTypeCode5800 is specified for lower-level items. However, there are exceptionsto this rule. A purchase order can contain items that have both a billof material hierarchy and a discount in kind hierarchy. In a variation,the CDT BusinessTransactionDocumentItemHierarchyRelationshipTypeCode5800 may be a proprietary code list with fixed predefined values. Inthat case, changes to the permitted values may involve changes to theinterface.

In the XML instance, “BusinessTransactionDocument” is replaced by thedescription of the specific business transaction document, for example“PurchaseOrder” for a purchase order, “Delivery” for a delivery, and thelike.

(x) BusinessTransactionDocumentItemID

A GDT BusinessTransactionDocumentItemID 5900 is a unique identifier ofan item or sub item of a document within a business transaction and isunique in the context of the business transaction. An example ofBusinessTransactionDocumentItemID is:

<ItemID>13</ItemID>.

The structure of GDT Business Transaction Document Item ID 5900 isdepicted in FIG. 59. For the GDT Business Transaction Document Item ID5900, the Object Class is Business Transaction Document Item 5902, theProperty is Identification 5904, the Representation/Association isIdentifier 5906, the Type is CCT 5908, the Type Name is Identifier 5910,and the Length is from one to ten 5912. The GDT Business TransactionDocument Item ID 5900 may be restricted 5914.

GDT BusinessTransactionDocumentItemID 5900 is a sequence of numbers witha maximum of ten characters. Leading zeros may not be significant at therecipient and may not be sent.

Business transactions, such as purchase orders or invoices, may bedivided into items and sub items. GDT BusinessTransactionDocumentItemID5900 is used in a business process to identify uniquely an item or subitem within a business transaction. A partner uses its GDTBusinessTransactionDocumentItemID 5900 to inform the other partner ofits identification of the item in an initial step, for example, whencreating an item or transmitting it for the first time. The secondpartner can then use this identifier to reference the respective item ofthe document in the subsequent process.

In the XML instance, “BusinessTransactionDocument” is replaced by thedescription of the respective document, e.g., “PurchaseOrder” for apurchase order, “Delivery” for a delivery, and the like.

(y) BusinessTransactionDocumentItemScheduleLineID

A GDT BusinessTransactionDocumentItemScheduleLineID 6000 is a uniqueidentifier that uses a deadline to identify the schedule line of adocument item within a business transaction. An example of GDTBusinessTransactionDocumentItemScheduleLineID 6000 is:

<PurchaseOrderItemScheduleLineID>0001</PurchaseOrderItemScheduleLineID>.

The structure of GDT Business Transaction Document Item Schedule Line ID6000 is depicted in FIG. 60. For the GDT Business Transaction DocumentItem Schedule Line ID 6000, the Object Class is Business TransactionDocument Item Schedule Line 6002, the Property is Identification 6004,the Representation/Association is Identifier 6006, the Type is CCT 6008,the Type Name is Identifier 6010, the Length is from one to four 6012.The GDT Business Transaction Document Item Schedule Line ID 6000 may berestricted 6014.

Documents such as purchase orders, sales orders, or invoices are dividedinto items. Items are then further divided according to schedule lines.Each of these schedule lines specifies a deadline and relevant productquantities for this deadline.

“BusinessTransactionDocument” is replaced by the description of eachdocument in the XML instance, e.g., “PurchaseOrder” for a purchaseorder, “Delivery” for a delivery, and the like.

(z) ThirdPartyIndicator

A GDT ThirdPartyIndicator 6100 indicates whether or not a document itemis used in the context of a third-party deal. An example of GDTThirdPartyIndicator 6100 in the context of a document item is:<ThirdPartyDealIndicator>true</ThirdPartyDealIndicator>.

The structure of GDT Third Party Indicator 6100 is depicted in FIG. 61.For the GDT Third Party Indicator 6100, the Object Class is BusinessTransaction Document Item 6102, the Property is third Party DealIndicator 6104, the Representation/Association term is Indicator 6106,the Type is CCT 6108, and the Type Name is Identifier 6110. The GDTThirdPartyIndicator 6100 can have the values true or false. Trueindicates that the object is used in the context of a third-party deal.False indicates that the object is not used in the context of athird-party deal.

The GDT ThirdPartyIndicator 6100 is used to indicate that a documentitem is used in the context of a third-party deal. A third-party dealmay be a process in which a company processes a sales order via a thirdparty rather than fulfilling it directly itself. The context to whichthe BusinessTransactionDocumentItemThirdPartyDealIndicator refers may beclear from the usage of the GDT.

(aa) BusinessTransactionDocumentItemTypeCode

The GDT BusinessTransactionDocumentItemTypeCode 6200 is a codedrepresentation of the type of an item in a document that occurs inbusiness transactions. The document item type describes the businessnature of similar document items and defines the basic features of thedocument items of this type. An example of GDTBusinessTransactionDocumentItemTypeCode 6200 is:

<BusinessTransactionDocumentItemTypeCode>001</BusinessTransactionDocumentItemTypeCode>.

The structure of GDT Business Transaction Document Item Type Code 6200is depicted in FIG. 62. For the GDT Business Transaction Document ItemType Code 6200, the Object Class is Business Transaction Document Item6202, the Property is Type 6204, the Representation/Association is Code6206, the Type is CCT 6208, the Type Name is Code 6210, and the Lengthis three 6212. The GDT Business Transaction Document Item Type Code 6200may be restricted 6214.

GDT BusinessTransactionDocumentItemTypeCode 6200 can have a value from001 to 004. 001 identifies a purchase order item that specifies anordered product or additional information on ordered products. Thisincludes information on free goods, substitute products and valuelimits. 002 identifies an invoice item that specifies prices and taxesfor a delivered product (including completed work) and, if necessary,more information on this product. 003 identifies a credit memo item thatspecifies refunded prices and taxes for a delivered product (includingcompleted work) and, if necessary, more information on this product. 004identifies a delivery cost item that specifies delivery costs incurredby the purchaser on top of the actual product costs. There may be adifferentiation between shipping costs, customs duty costs, andmiscellaneous costs, such as packaging and insurance.

Certain combinations of a GDT BusinessTransactionDocumentItemTypeCode6200 and a BusinessTransactionDocumentTypeCode may be allowed. Forexample, if BusinessTransactionDocumentTypeCode is 001,BusinessTransactionDocumentItemTypeCode may be 001. IfBusinessTransactionDocumentTypeCode is 004,BusinessTransactionDocumentItemTypeCode may be 002, 003, or 004. IfBusinessTransactionDocumentTypeCode is 005,BusinessTransactionDocumentItemTypeCode may be 001.

The GDT BusinessTransactionDocumentItemTypeCode 6200 categorizes an itemin a document that is sent if the concrete semantic meaning of the itemor sub-item is not defined by the message itself or if semanticallydifferent items can occur in one message. In particular, there aredocuments in applications that contain items with different types sothat it may not be enough to specify the type of the complete document.For example, in addition to a “standard” invoice item for an orderedproduct, an invoice can contain a delivery costs item that is to beshown separately.

In an example, in R/3, the BusinessTransactionDocumentItemTypeCode 6200corresponds to VBTYP+POSAR in Sales or BSTYP in Purchasing orMRM_REFERENZBELEG in Invoice Verification, and the like, at a lessdetailed level.

(bb) BusinessTransactionDocumentLocation

A CDT BusinessTransactionDocumentLocation 6300 contains the informationthat is exchanged in business documents about a location relevant forbusiness transactions. This information identifies the location and itsaddress. The identification may be a company-internal ID, a standardizedID, or one or several partner-specific IDs. A location is a logical or aphysical place. An ID for a location assigned by a party identifies inthe name the role the assigning party plays in the business transaction.At present, the role descriptions are Buyer, Seller, ProductRecipient,Vendor, BillTo, and BillFrom. An example of CDTBusinessTransactionDocumentLocation 6300 is: <InventoryChange>    ...   <Location>       <StandardID schemeAgencyID=“016”>4711 </StandardID>      <BuyerID>9873</BuyerID>       <Address>...</Address>    <Location><InventoryChange>.

The structure of CDT Business Transaction Document Location 6300 isdepicted in FIG. 63. For the CDT Business Transaction Document Location6300, the Object Class is Business Transaction Document Location 6302and the Representation/Association is Details 6304.

For the Internal ID 6306, the Category is Element 6308, the Object Classis Business Transaction Document Location 6310, the Property Qualifieris Internal 6312, the Property is Identification 6314, theRepresentation/Association is Identifier 6316, the Type is CDT 6318, andthe Type Name is Location Internal ID 6320. The Cardinality is zero orone 6322.

For the Standard ID 6324, the Category is Element 6326, the Object Classis Business Transaction Document Location 6328, the Property Qualifieris Standard 6330, the Property is Identification 6332, theRepresentation/Association is Identifier 6334, the Type is CDT 6336, andthe Type Name is Location Standard ID 6338. The Cardinality is from zeroto n. 6340.

For the Buyer ID 6342, the Category is Element 6344, the Object Class isBusiness Transaction Document Location 6346, the Property Qualifier isBuyer 6363, the Property is Identification 6350, theRepresentation/Association is Identifier 6352, the Type is CDT 6354, andthe Type Name is Location Party ID 6356. The Cardinality is zero or one6358.

For the Seller ID 6360, the Category is Element 6362, the Object Classis Business Transaction Document Location 6364, the Property Qualifieris Seller 6366, the Property is Identification 6368, theRepresentation/Association is Identifier 6370, the Type is CDT 6372, andthe Type Name is Location Party ID 6374. The Cardinality is zero or one6376.

For the Seller ID 6360, the Category is Element 6362, the Object Classis Business Transaction Document Location 6364, the Property Qualifieris Seller 6366, the Property is Identification 6368, theRepresentation/Association is Identifier 6370, the Type is CDT 6372, andthe Type Name is Location Party ID 6374. The Cardinality is zero or one6376.

For the Product Recipient ID 6378, the Category is Element 6380, theObject Class is Business Transaction Document Location 6390, theProperty Qualifier is Product Recipient 6392, the Property isIdentification 6394, the Representation/Association is Identifier 6396,the Type is CDT 6398, and the Type Name is Location Party ID 6399. TheCardinality is zero or one 6301A.

For the Vendor ID 6302A, the Category is Element 6303A, the Object Classis Business Transaction Document Location 6304A, the Property Qualifieris Vendor 6305A, the Property is Identification 6306A, theRepresentation/Association is Identifier 6307A, the Type is CDT 6308A,and the Type Name is Location Party ID 6309A. The Cardinality is zero orone 6310A.

For the Bill To ID 6311A, the Category is Element 6312A, the ObjectClass is Business Transaction Document Location 6313A, the PropertyQualifier is Bill To 6314A, the Property is Identification 6315A, theRepresentation/Association is Identifier 6316A, the Type is CDT 6317A,and the Type Name is Location Party ID 6318A. The Cardinality is zero orone 6319A.

For the Bill From ID 6320A, the Category is Element 6321A, the ObjectClass is Business Transaction Document Location 6322A, the PropertyQualifier is Bill From 6323A, the Property is Identification 6324A, theRepresentation/Association is Identifier 6325A, the Type is CDT 6326A,and the Type Name is Location Party ID 6327A. The Cardinality is zero orone 6328A.

For the Bidder ID 6329A, the Category is Element 6330A, the Object Classis Business Transaction Document Location 6331A, the Property Qualifieris Bidder 6332A, the Property is Identification 6333A, theRepresentation/Association is Identifier 6334A, the Type is CDT 6335A,and the Type Name is Location Party ID 6336A. The Cardinality is zero orone 6337A.

For the Address 6338A, the Category is Element 6339A, the Object Classis Business Transaction Document Location 6340A, the Property is Address6341A, the Representation/Association is Address 6342A, the Type is GDT6343A, and the Type Name is Address 6344A. The Cardinality is zero orone 6345A.

For the Note 6346A, the Category is Element 6347A, the Object Class isBusiness Transaction Document Location 6348A, the Property is Note6349A, the Representation/Association is Text 6350A, the Type is GDT6351A, and the Type Name is Note 6352A. The Cardinality is zero or one6353A.

InternalID refers to a proprietary identifier that is used when bothsender and recipient can access shared master data (extendedenterprise). Standard ID refers to a standardized identifier, whoseidentification schemes may be managed by an agency from the DE 3055 codelist. Buyer ID refers to an identifier that is used by the BuyerPartyproprietarily for this location. SellerID refers to an identifier thatis used by the SellerParty proprietarily for this location.ProductRecipientID refers to an identifier that is used by theProductRecipientParty proprietarily for this location. VendorID refersto an identifier that is used by the VendorParty proprietarily for thislocation. BillToID refers to an identifier that is used by theBillToParty proprietarily for this location. BillFromID refers to anidentifier that is used by the BillFromParty proprietarily for thislocation. BidderID refers to an identifier that is used by theBidderParty proprietarily for this location. Address is an address thatdescribes the location by specifying information such as postal address,geographic coordinates, or any other information that specifies alocation. Note refers to an additional information such as direction.

When defining addresses, organization addresses may be supported. Thedifferent IDs of a CDT BusinessTransactionDocumentLocation 6300 identifythe same location. A location may be identified by the InternalID whensender and recipient can access shared master data, by the StandardIDwhen sender and recipient can manage standardized identifiers, or by thePartyIDs: when sender and recipient are interested in the PartyIDsassigned by the parties involved. From all of the IDs available to thesender, the IDs that the recipient is expected to understand may beused.

(cc) BusinessTransactionDocumentParty

A CDT BusinessTransactionDocumentParty 6400 contains the informationthat is exchanged—in accordance with common business understanding—inbusiness documents about a party involved in business transactions. Thisinformation is used to identify the party and the party's address, aswell as the party's contact person and the contact person's address.This identification can take place using an internal ID, a standardizedID, or IDs assigned by the parties involved. A party is a naturalperson, organization, or business partner group in which a company has abusiness or intra-enterprise interest. This could be a person,organization, or group within or outside of the company. An ID assignedby a party identifies in the name the role the assigning party plays inthe business transaction. At present, the roles are Buyer, Seller,ProductRecipient, Vendor, BillTo, BillFrom and Bidder. An example of CDTBusinessTransactionDocumentParty 6400 is: <PurchaseOrder>    ...   <BuyerParty>       <StandardID schemeAgencyID=“016”>4711</StandardID>      <BuyerID>9873</BuyerID>       <SellerID>487847</SellerID>      <Address>...</Address>       <ContactPerson>         <BuyerID>9874</BuyerID>          <SellerID>487848</SellerID>         <Address>...</Address>       </ContactPerson>    </BuyerParty></PurchaseOrder>.

In this example, schemeAgencyID=“016” corresponds to Dun&Bradstreetaccording to code list D3055 that means that the DUNS number is assignedby Dun&Bradstreet. The following is a second example ofBusinessTransactionDocumentParty: <PurchaseOrder>    ...    <BuyerParty>      <InternalID schemeID=“PartyID”schemeAgencyID=“BPL_300”>747</InternalID>       <Address>...</Address>      <ContactPerson>             <InternalID schemeID=“PartyID”schemeAgencyID=“BPL_300”>737</InternalID>             <Address>...</Address>          </ContactPerson>      </BuyerParty>    <PurchaseOrder>.

In this example, schemeID=“PartyID” indicates that the scheme “PartyID”was used to identify the party and schemeAgencyID=“BPL_(—)300” indicatesthat the scheme was assigned by the SAP CMDM system “BPL_(—)300.”

The examples above show the XML instance of the GDTBusinessTransactionDocumentParty within a purchase order for differentidentification types (standard ID, party IDs, internal ID). In thisscenario, the party assumes the role of Buyer.

The structure of CDT Business Transaction Document Party 6400 isdepicted in FIG. 64. For the CDT Business Transaction Document Party6400, the Category is Element 6408, the Object Class is BusinessTransaction Document Party 6402, and the Representation/Association isDetails 6404.

For the Internal ID 6406, the Category is Element 6408, the Object Classis Business Transaction Document Party 6470, the Property Qualifier isInternal 6412, the Property is Identification 6414, theRepresentation/Association is Identifier 6416, the Type is CDT 6418, andthe Type Name is Party Internal ID 6420. The Cardinality is zero or one6422.

For the Standard ID 6424, the Category is Element 6426, the Object Classis Business Transaction Document Party 6428, the Property Qualifier isStandard 6430, the Property is Identification 6432, theRepresentation/Association is Identifier 6434, the Type is CDT 6436, andthe Type Name is Party Standard ID 6438. The Cardinality is from zero ton. 6440.

For the Buyer ID 6442, the Category is Element 6444, the Object Class isBusiness Transaction Document Party 6446, the Property Qualifier isBuyer 6448, the Property is Identification 6450, theRepresentation/Association is Identifier 6452, the Type is CDT 6454, andthe Type Name is Party ID 6456. The Cardinality is zero or one 6458.

For the Seller ID 6460, the Category is Element 6462, the Object Classis Business Transaction Document Party 6464, the Property Qualifier isSeller 6466, the Property is Identification 6468, theRepresentation/Association is Identifier 6470, the Type is CDT 6472, andthe Type Name is Party Party ID 6474. The Cardinality is zero or one6476.

For the Product Recipient ID 6478, the Category is Element 6480, theObject Class is Business Transaction Document Party 6482, the PropertyQualifier is Product Recipient 6484, the Property is Identification6486, the Representation/Association is Identifier 6488, the Type is CDT6490, and the Type Name is Party Party ID 6492. The Cardinality is zeroor one 6494.

For the Vendor ID 6496, the Category is Element 6498, the Object Classis Business Transaction Document Party 6499, the Property Qualifier isVendor 6401A, the Property is Identification 6402A, theRepresentation/Association is Identifier 6403A, the Type is CDT 6404A,and the Type Name is Party Party ID 6405A. The Cardinality is zero orone 6406A.

For the Bill To ID 6407A, the Category is Element 6408A, the ObjectClass is Business Transaction Document Party 6409A, the PropertyQualifier is Bill To 6410A, the Property is Identification 6411A, theRepresentation/Association is Identifier 6412A, the Type is CDT 6413A,and the Type Name is Party Party ID 6414A. The Cardinality is zero orone 6415A.

For the Bill From ID 6416A, the Category is Element 6417A, the ObjectClass is Business Transaction Document Party 6418A, the PropertyQualifier is Bill From 6419A, the Property is Identification 6420A, theRepresentation/Association is Identifier 6421A, the Type is CDT 6422A,and the Type Name is Party Party ID 6423A. The Cardinality is zero orone 6424A.

For the Bidder ID 6425A, the Category is Element 6426A, the Object Classis Business Transaction Document Party 6427A, the Property Qualifier isBidder 6428A, the Property is Identification 6429A, theRepresentation/Association is Identifier 6430A, the Type is CDT 6431A,and the Type Name is Party Party ID 6432A. The Cardinality is zero orone 6433A.

For the Address 6434A, the Category is Element 6435A, the Object Classis Business Transaction Document Party 6436A, the Property is Address6437A, the Representation/Association is Address 6438A, the Type is GDT6440A, and the Type Name is Address 6441 A. The Cardinality is zero orone 6424A.

For the Contact Person 6443A, the Category is Element 6444A, the ObjectClass is Business Transaction Document Party 6445A, the Property isContact Person 6446A, the Representation/Association is Contact Person6447A, the Type is CDT 6448A, and the Type Name is Contact Person 6464A.The Cardinality is zero or one 6450A.

InternalID refers to a proprietary identifier that is used when bothsender and recipient can access shared master data (extendedenterprise). StandardID refers to a standardized identifier for thisparty, whose identification scheme may be managed by an agency from theDE 3055 code list. BuyerID refers to an identifier that is used by theBuyerParty for this party. SellerID refers to an identifier that is usedby the SellerParty for this party. ProductRecipientID refers to anidentifier that is used by the ProductRecipientParty for this party.VendorID refers to an identifier that is used by the VendorParty forthis party. BillToID refers to an identifier that is used by theBillToParty for this party. BillFromID refers to an identifier that isused by the BillFromParty for this party. BidderID refers to anidentifier that is used by the BidderParty for this party. Addressrefers to the address of the party. ContactPerson refers to a contactperson of the party.

The different IDs of a CDT BusinessTransactionDocumentParty 6400 mayidentify the same party. A party may be identified by InternalID whensender and recipient can access shared master data, by StandardID whensender and recipient can manage standardized identifiers, or byPartytPartyIDs when sender and recipient are interested in the PartyIDsassigned by the parties involved. Of the IDs available to the sender,IDs that the recipient is expected to understand may be used in amessage.

The parties involved in a business transaction assume a specific rolethat is also specified for them in the corresponding business documents.For example, BuyerParty is a party that buys goods or services,SellerParty is a party that sells goods or services, CreditorParty is aparty that is authorized to claim goods, services or payment for a debtowed to it, DebtorParty is a party that is obliged to provide goods,services or payment for a debt it owes, ProductRecipientParty is a partyto which goods are delivered or for which services are provided,VendorParty is a party that delivers goods or provides services,ManufacturerParty is a party that manufactures goods, PayerParty is aparty that pays for goods or services, PayeeParty is a party thatreceives a payment for goods or services, BillToParty is a party towhich the invoice for goods or services is sent, BillFromParty is aparty that creates the invoice for goods or services, CarrierParty is aparty that transports goods, RequestorParty is a party that requests theprocurement of goods or services, PortalProviderParty is a party thatruns a portal that brings business partners together for a businesstransaction, CatalogueProviderParty is a party that compiles acatalogue, BidderParty is a party that bids for goods or services, andOwnerParty is a party that has tangible or intangible assets asproperty.

The CDT BusinessTransactionDocumentParty 6400 is used in messages forinternal and external communication to transmit required informationabout the parties involved.

(dd) BusinessTransactionDocumentPricingIndicator

The GDT BusinessTransactionDocumentPricingIndicator 6500 indicateswhether pricing/price determination should be performed for all items orfor selected items in a business transaction. An example of GDTBusinessTransactionDocumentPricingIndicator 6500 is:

<BusinessTransactionDocumentPricingIndicator>true</BusinessTransactionDocumentPricingIndicator>.

The structure of GDT Business Transaction Document Pricing Indicator6500 is depicted in FIG. 65. For the GDT Business Transaction DocumentPricing Indicator 6500, the Object Class is Business TransactionDocument 6502, the Property is Pricing Indicator 6504, theRepresentation/Association is Indicator 6506, the Type is CCT 6508, andthe Type Name is Indicator 6510.

The GDT BusinessTransactionDocumentPricingIndicator 6500 can have thevalues true or false. True indicates that the pricing/pricedetermination should be performed. False indicates that thepricing/price determination should not be performed.

Business documents or items in business documents for whichpricing/price determination can be performed are linked to the purchaseor sale of products. Illustrative examples are order, delivery andtransport documents and their items.

(ee) BusinessTransactionDocumentProduct

A CDT BusinessTransactionDocumentProduct 6600 contains the informationthat is exchanged—for example, in accordance with common businessunderstanding—in business documents about a product. This informationidentifies the product and product type, and describes the product. Thisidentification can occur using an internal ID, a standardized ID, or IDsassigned by the parties involved. A product is either a tangible orintangible good, and is a part of the business activities of a company.It can be traded and contributes directly or indirectly to value added.An ID assigned by a party identifies in the name the role the assigningparty plays in the business transaction. At present, the roles areBuyer, Seller, ProductRecipient, Vendor, Manufacturer, BillTo, BillFromand Bidder. An example of CDT BusinessTransactionDocumentProduct 6600is:

Example 1) Standard ID, PartyIDs <PurchaseOrder>    ...    <Product>      <StandardID schemeAgencyID=“009”>4711</StandardID>      <BuyerID>A6B7915634654</BuyerID>      <SellerID>234532358B4</SellerID>      <ManufacturerID>6546</ManufacturerID>       <TypeCode>1</TypeCode>      <Note>SAP NetWeaver</Note>    </Product> </PurchaseOrder>.

In this example, schemeAgencyID=“009” corresponds to “EAN” according tocode list DE 3055, and TypeCode=“1” indicates it is the product type“Material.”

The following is a second example of CDTBusinessTransactionDocumentProduct 6600:

Example 2) Internal ID    <PurchaseOrder>       ...       <Product>         <InternalID schemeID=“ProductGUID” schemeAgencyID=“MPL_002”>1C743CEC501F6A4D8826C7EC5A8554B9</InternalID>         <TypeCode>1</TypeCode>          <Note>SAP NetWeaver</Note>      </Product>    </PurchaseOrder>.

In this example, schemeID=“PartyGUID” indicates that the scheme“ProductGUID” was used to identify the product andschemeAgencyID=“MPL_(—)002” indicates that the scheme was assigned bythe business system “MPL_(—)002.”

The structure of CDT Business Transaction Document Product 6600 isdepicted in FIG. 66. For the CDT Business Transaction Document Product6600, the Object Class is Business Transaction Document Product 6602,and the Representation/Association is Details 6604.

For the Internal ID 6606, the Category is Element 6608, the Object Classis Business Transaction Document Product 6610, the Property Qualifier isInternal 6612, the Property is Identification 6614, theRepresentation/Association is Identifier 6616, the Type is CDT 6618, andthe Type Name is Product Internal ID 6620. The Cardinality is zero orone 6622.

For the Standard ID 6624, the Category is Element 6626, the Object Classis Business Transaction Document Product 6628, the Property Qualifier isStandard 6630, the Property is Identification 6632, theRepresentation/Association is Identifier 6634, the Type is CDT 6636, andthe Type Name is Product Standard ID 6638. The Cardinality is from zeroto n. 6640.

For the Buyer ID 6642, the Category is Element 6644, the Object Class isBusiness Transaction Document Product 6646, the Property Qualifier isBuyer 6648, the Property is Identification 6650, theRepresentation/Association is Identifier 6652, the Type is CDT 6654, andthe Type Name is Product Party ID 6656. The Cardinality is zero or one6658.

For the Seller ID 6660, the Category is Element 6680, the Object Classis Business Transaction Document Product 6664, the Property Qualifier isSeller 6666, the Property is Identification 6668, theRepresentation/Association is Identifier 6670, the Type is CDT 6672, andthe Type Name is Product Party ID 6674. The Cardinality is zero or one6676.

For the Product Recipient ID 6678, the Category is Element 6680, theObject Class is Business Transaction Document Product 6682, the PropertyQualifier is Product Recipient 6684, the Property is Identification6686, the Representation/Association is Identifier 6688, the Type is CDT6690, and the Type Name is Product Party ID 6692. The Cardinality iszero or one 6694.

For the Vendor ID 6696, the Category is Element 6698, the Object Classis Business Transaction Document Product 6699, the Property Qualifier isVendor 6601A, the Property is Identification 6602A, theRepresentation/Association is Identifier 6603A, the Type is CDT 6604A,and the Type Name is Product Party ID 6605A. The Cardinality is zero orone 6606A.

For the Manufacturer ID 6607A, the Category is Element 6608A, the ObjectClass is Business Transaction Document Product 6609A, the PropertyQualifier is Manufacturer 6610A, the Property is Identification 6611A,the Representation/Association is Identifier 6612A, the Type is CDT6613A, and the Type Name is Product Party ID 6614A. The Cardinality iszero or one 6615A.

For the Bill To ID 6616A, the Category is Element 6617A, the ObjectClass is Business Transaction Document Product 6618A, the PropertyQualifier is Bill To 6619A, the Property is Identification 6620A, theRepresentation/Association is Identifier 6621A, the Type is CDT 6622A,and the Type Name is Product Party ID 6623A. The Cardinality is zero orone 6624A.

For the Bill From ID 6625A, the Category is Element 6626A, the ObjectClass is Business Transaction Document Product 6627A, the PropertyQualifier is Bill From 6628A, the Property is Identification 6629A, theRepresentation/Association is Identifier 6630A, the Type is CDT 6631A,and the Type Name is Product Party ID 6632A. The Cardinality is zero orone 6633A.

For the Bidder ID 6634A, the Category is Element 6635A, the Object Classis Business Transaction Document Product 6636A, the Property Qualifieris Bidder 6637A, the Property is Identification 6639A, theRepresentation/Association is Identifier 6639A, the Type is CDT 6640A,and the Type Name is Product Party ID 6641A. The Cardinality is zero orone 6642A.

For the Type Code 6643A, the Category is Element 6644A, the Object Classis Business Transaction Document Product 6645A, the Property is TypeName Code 6646A, the Representation/Association is Code 6647A, the Typeis GDT 6648A, and the Type Name is Product Type Code 6649A. TheCardinality is zero or one 6650A.

For the Note 6651A, the Category is Element 6652A, the Object Class isBusiness Transaction Document Product 6653A, the Property is Note 6654A,the Representation/Association is Note 6655A, the Type is GDT 6656A, andthe Type Name is Note 6657A. The Cardinality is zero or one 6658A.

For the Change ID 6659A, the Category is Element 6660A, the Object Classis Business Transaction Document Product 6661A, the Property is ChangeIdentification 6662A, the Representation/Association is Identifier6663A, the Type is GDT 6664A, and the Type Name is product Change ID6665A. The Cardinality is zero or one 6666A.

For the Discontinuation Indicator 6666A, the Category is Element 6667A,the Object Class is Business Transaction Document Product 6668A, theProperty is Discontinuation 6669A, the Representation/Association isIndicator 6670A, the Type is GDT 6671A, and the Type Name is productDiscontinuation Indicator 6672A. The Cardinality is zero or one 6673A.

For the Package Quantity 6674A, the Category is Element 6675A, theObject Class is Business Transaction Document Product 6676A, theProperty Qualifier is Package 6677A, the Property is Quantity 6678A, theRepresentation/Association is Quantity 6679A, the Type term is GDT6680A, and the Type Name term is Quantity 6681A. The Cardinality is zeroor one 6682A.

InternalID refers to a proprietary identifier for the product that isused when both sender and recipient can access shared master data(extended enterprise). StandardID refers to a standardized identifierfor this product, whose identification scheme may be managed by anagency from the DE 3055 code list. BuyerID refers to an identifier thatis used proprietarily by the BuyerParty for this product. SellerIDrefers to an identifier that is used proprietarily by the SellerPartyfor this product. ProductRecipientID refers to an identifier that isused proprietarily by the ProductRecipientParty for this product.VendorID refers to an identifier that is used proprietarily by theVendorParty for this product. ManufacturerID refers to an identifierthat is used proprietarily by the ManufacturerParty for this product.BillToID refers to an identifier that is used proprietarily by theBillToParty for this product. BillFromID refers to an identifier that isused proprietarily by the BillFromParty for this product. BidderIDrefers to an identifier that is used proprietarily by the BidderPartyfor this product. Type Code refers to coded representation of the typeof a product such as “1” for material and “2” for service product. Noterefers to a product description. ChangeID refers to an unique identifierfor a change to a product that has no effect on the properties that arerelevant for the user. DiscontinuationIndicator indicates whether theoffering of a product is to be discontinued, i.e., removed from theline. PackageQuantity refers to an amount per container (packageamount). The amount per container may be necessary if different packagequantities are relevant, but the same product ID can have differentpackage quantities depending on the item. This information is alsovariable movement data at time of the message.

The different IDs of a CDT BusinessTransactionDocumentProduct 6600 mayidentify the same product. Identification of a product can take place byan InternalID when sender and recipient can access shared master data,by a StandardID when sender and recipient can manage standardizedidentifiers, or by a ProductPartyIDs when sender and recipient areinterested in the ProductIDs assigned by the parties involved. Of all ofthe IDs available to the sender, IDs that the recipient is expected tounderstand may be used in a message.

(ff) BusinessTransactionDocumentProductCategory

A CDT BusinessTransactionDocumentProductCategory 6700 contains theinformation that is exchanged—for example, in accordance with commonbusiness understanding—in business documents about a product category.It identifies the product category using an internal ID, a standard ID,and IDs assigned by parties involved. A product category is a divisionof products according to objective criteria. An ID assigned by a partyidentifies in the name the role the assigning party plays in thebusiness transaction. At present, roles are Buyer, Seller,ProductRecipient, Vendor, BillTo, BillFrom and Bidder. An example of CDTBusinessTransactionDocumentProductCategory 6700 is:    <BusinessTransactionDocumentProductCategory>     <StandardIDschemeID=“UNSPSC” schemeVersionID=“11.0”schemeAgencyID=“257”>4711</StandardID>     <BuyerID>1234</BuyerID>    <SellerID>2345</SellerID>  </BusinessTransactionDocumentProductCategory>.

In this example, SchemeID=“UNSPSC” indicates that it is the scheme“United Nations Standard Product and Services Classification Code”,SchemeVersionID=“11.0” indicates the version of the scheme, andschemeAgencyID=“257” corresponds to the Agency “ECCMA” (ElectronicCommerce Code Management Association) according to the code list DE3055.

The structure of CDT Business Transaction Document Product Category 6700is depicted in FIG. 67. For the CDT Business Transaction DocumentProduct Category 6700, the Object Class is Business Transaction DocumentProduct Category 6702, and the Representation/Association term isDetails 6704.

For the Internal ID 6706, the Category is Element 6708, the Object Classis Business Transaction Document Product Category 6710, the PropertyQualifier term is Internal 6712, the Property is Identification 6714,the Representation/Association term is Identifier 6716, the Type term isCDT 6718, and the Type Name term is Product Category Internal ID 6720.The Cardinality is zero or one 6722.

For the Standard ID 6724, the Category is Element 6726, the Object Classis Business Transaction Document Product Category 6728, the PropertyQualifier term is Standard 6730, the Property is Identification 6732,the Representation/Association term is Identifier 6734, the Type term isCDT 6736, and the Type Name is Product Category Standard ID 6738. TheCardinality is from zero to n 6740.

For the Buyer ID 6742, the Category is Element 6744, the Object Class isBusiness Transaction Document Product Category 6746, the PropertyQualifier term is Buyer 6748, the Property is Identification 6750, theRepresentation/Association term is Identifier 6767, the Type term is CDT6754, and the Type Name is Product Category Party ID 6756. TheCardinality is zero or one 6758.

For the Seller ID 6760, the Category is Element 6762, the Object Classis Business Transaction Document Product Category 6764, the PropertyQualifier term is Seller 6766, the Property is Identification 6768, theRepresentation/Association term is Identifier 6770, the Type term is CDT6772, and the Type Name term is Product Category Party ID 6774. TheCardinality is zero or one 6776.

For the Product Recipient ID 6778, the Category is Element 6780, theObject Class is Business Transaction Document Product Category 6782, theProperty Qualifier term is Product Recipient 6784, the Property isIdentification 6786, the Representation/Association term is Identifier6788, the Type term is CDT 6790, and the Type Name term is ProductCategory Party ID 6792. The Cardinality is zero or one 6794.

For the Vendor ID 6796, the Category is Element 6798, the Object Classis Business Transaction Document Product Category 6799, the PropertyQualifier term is Vendor 6701A, the Property is Identification 6702A,the Representation/Association term is Identifier 6703A, the Type termis CDT 6704A, and the Type Name term is Product Category Party ID 6705A.The Cardinality is zero or one 6706A.

For the Bill To ID 6707A, the Category is Element 6708A, the ObjectClass is Business Transaction Document Product Category 6709A, theProperty Qualifier term is Bill To 6710A, the Property is Identification6711A, the Representation/Association term is Identifier 6712A, the Typeterm is CDT 6713A, and the Type Name term is Product Category Party ID6714A. The Cardinality is zero or one 6715A.

For the Bill From ID 6716A, the Category is Element 6717A, the ObjectClass is Business Transaction Document Product Category 6718A, theProperty Qualifier term is Bill From 6719A, the Property isIdentification 6720A, the Representation/Association term is Identifier6721A, the Type term is CDT 6722A, and the Type Name term is ProductCategory Party ID 6723A. The Cardinality is zero or one 6724A.

For the Bidder ID 6725A, the Category is E 6726A, the Object Class isBusiness Transaction Document Product Category 6727A, the PropertyQualifier term is Bidder From 6728A, the Property is Identification6729A, the Representation/Association term is Identifier 6730A, the Typeterm is CDT 6731 A, and the Type Name term is Product Category Party ID6732A. The Cardinality is zero or one 6733A.

InternalID refers to a proprietary identifier for the product categorythat is used when both sender and recipient can access shared masterdata (extended enterprise). StandardID refers to a standardizedidentifier for this product category whose identification scheme may bemanaged by an agency from the DE 3055 code list. BuyerID refers to anidentifier that is used proprietarily by the BuyerParty for this productcategory. SellerID refers to an identifier that is used proprietarily bythe SellerParty for this product category. ProductRecipientID refers toan identifier that is used proprietarily by the ProductRecipientPartyfor this product category. VendorID refers to an identifier that is usedproprietarily by the VendorParty for this product category. BillToIDrefers to an identifier that is used proprietarily by the BillToPartyfor this product category. BillFromID refers to an identifier that isused proprietarily by the BillFromParty for this product category.BidderID refers to an identifier that is used proprietarily by theBidderParty for this product category.

The different IDs of a CDT BusinessTransactionDocumentProductCategory6700 may identify the same product category. A product category may beidentified by the ProductCategoryInternalID when sender and recipientcan access shared master data, by the ProductCategoryStandardID whensender and recipient can manage standardized identifiers, or by theProductCategoryPartyIDs when sender or recipient are interested in theProductCategoryIDs assigned by the parties involved. Of the IDsavailable to the sender, IDs that the recipient is expected tounderstand may be used in a message. At least one ID may be specified.

The CDT BusinessTransactionDocumentProductCategory 6700 is used inmessages for internal and external communication to transmit requiredinformation about a product category.

(gg) BusinessTransactionDocumentPublicIndicator

A GDT BusinessTransactionDocumentPublicIndicator 6800 indicates whetheror not a business document is public. “Public” in this case means thataccess to the business document is not restricted in any way and thedocument is published in a standard place. An example of GDTBusinessTransactionDocumentPublicIndicator 6800 is:

<RFQPublicIndicator>true</RFQPublicIndicator>.

The structure of CDT Business Transaction Document Public Indicator 6800is depicted in FIG. 68. For the CDT Business Transaction Document PublicIndicator 6800, the Object Class is Business Transaction Document 6802,the Property is Public Indicator 6804, the Representation/Associationterm is Indicator 6806, the Type term is CCT 6808, and the Type Nameterm is Indicator.

GDT BusinessTransactionDocumentPublicIndicator 6800 may have the valuetrue or false. True indicates that the business document is public.False indicates that the business document is not public.

The GDT BusinessTransactionDocumentPublicIndicator 6800 may be used in abid invitation to indicate whether the bid invitation is open to thepublic or limited to an exclusive group of participants. It thereforeindicates to potential participants whether the group of fellow biddersmay be restricted in advance.

When the GDT is used, the name component “BusinessTransactionDocument”is replaced with an actual BusinessTransactionDocumentType, e.g.,PurchaseOrder, RFQ, and the like.

(hh) BusinessTransactionDocumentReference

A GDT BusinessTransactionDocumentReference 6900 is a unique reference toother business documents that are important within the respectivebusiness process. Furthermore, it is also possible to have references toone or more line items within the same business document. An example ofGDT BusinessTransactionDocumentReference 6900 is:<PurchaseOrderReference>    <ID>102321</ID>    <ItemID>1</ItemID></PurchaseOrderReference >.

The structure of CDT Business Transaction Document Reference 6900 isdepicted in FIG. 69. For the CDT Business Transaction Document Reference6900, the Object Class is Business Transaction Document Reference 6902,and the Representation/Association term is Details 6904.

For the ID 6906, the Category is Element 6908, the Object Class isBusiness Transaction Document Reference 6910, the Property isIdentification 6912, the Representation/Association term is Identifier6914, the Type term is GDT 6916, and the Type Name is BusinessTransaction Document ID 6918. The Cardinality is zero or one 6920.

For the Item ID 6922, the Category is Element 6924, the Object Class isBusiness Transaction Document Reference 6926, the Property is ItemIdentification 6928, the Representation/Association term is Identifier6930, the Type term is GDT 6932, and the Type Name is BusinessTransaction Document Item ID 6934. The Cardinality is from zero to n6936.

The business process role of the issuer of the referenced document doesnot occur in the GDT; rather, it is defined explicitly in the name, suchas PurchaseContractReference and SalesContractReference.“DocumentReference” can be used for referencing relevant documentswithin a business process. They are used as a reference asset for therespective business document. It is also possible to reference theindividual items of the respective documents. For example, within the“Order” document, references can be created to the business documents“Quote,” “Contract,” “PurchaseOrder,” as well as to their individualitem lines.

“BusinessTransactionDocument” may be replaced by the description of eachdocument in the XML instance, e.g., “PurchaseOrder” for a purchaseorder, “Delivery” for a delivery, and the like.

(ii) BusinessTransactionDocumentSettlementRelevanceIndicator

A GDT BusinessTransactionDocumentSettlementRelevanceIndicator 7000indicates whether a given Business Transaction document or one of itsitems should be settled or not. Settlement incorporates both billing andinvoice verification. An example of GDTBusinessTransactionDocumentSettlementRelevanceIndicator 7000 is:

<BusinessTransactionDocumentSettlementRelevanceIndicator>true</BusinessTransactionDocumentSettlementRelevanceIndicator>.

The structure of GDT Business Transaction Document Settlement RelevanceIndicator 7000 is depicted in FIG. 70. For the GDT Business TransactionDocument Settlement Relevance Indicator 7000, the Object Class isBusiness Transaction Document 7002, the Property is Settlement RelevanceIndicator 7004, the Representation/Association term is Indicator 7006,the Type term is CCT 7008, and the Type Name term is Indicator 7010.

The GDT BusinessTransactionDocumentSettlementRelevanceIndicator 7000 mayhave the value true or false. True indicates that the document or anitem in the document should be settled. False indicates that thedocument or an item in the document should not be settled.

The GDT BusinessTransactionDocumentSettlementRelevanceIndicator 7000 maybe applied to business documents that are created when products areordered, goods are delivered, or services are provided, or that transmitinformation from such business documents. It can be applied to theentire document or to individual items.

If it is transmitted with the value “true” for an entire document or oneof that document's items, the whole document or the marked item issettled. References are used to ensure that additional information istaken into account.

If the indicator is transmitted with the value “false” for an entiredocument or one of that document's items, then the whole document or themarked item is not settled. References can be used to ensure thattransmitted information is also taken into account during settlement ofdocuments/items that are transmitted with an indicator with value‘true’.

In one example, if an Order Management credit memo request prompts thecreation of a credit memo in billing, then the credit memo request willbe transferred with the indicator value set to “true.”

In another example, if an Order Management standard order needs to betaken into account during the billing of the deliveries that resultedfrom it, then that standard order is transferred with the indicator setto “false,” and the subsequent delivery document with the indicator setto “true.” The references in the delivery document to the items in thestandard order ensure that the standard order is then taken into accountduring settlement.

In an example, theBusinessTransactionDocumentSettlementRelevanceIndicator corresponds to“billing relevance” in R/3 or CRM, with which it is additionallypossible, however, to control which quantities should be settled when.

(jj) BusinessTransactionDocumentShipFromLocation

A CDT BusinessTransactionDocumentShipFromLocation 7100 contains theinformation that is exchanged in business documents about a locationrelevant for business transactions and from which goods or services areshipped. The information identifies the location, its address, and, ifnecessary, a different loading location. The identification may be acompany-internal ID, a standardized ID, or one or more partner-specificIDs. A location is a logical or a physical place. An ID assigned by aparty identifies in the name the role the assigning party occupies inthe business transaction. Roles may include Buyer, Seller,ProductRecipient, and Vendor. An example of CDTBusinessTransactionDocumentShipFromLocation 7100 is:<ReplenishmentOrder>    ...    <ShipFromLocation>       <StandardIDschemeAgencyID=“016”>4711</StandardID>       <BuyerID>9873</BuyerID>      <SellerID>487847</SellerID>       <Address>...</Address>      <LoadingLocation>...</LoadingLocation>    <ShipFromLocation><ReplenishmentOrder>.

The structure of CDT Business Transaction Document Ship From Location7100 is depicted in FIG. 71. For the CDT Business Transaction DocumentShip From Location 7100, Object Class is Business Transaction DocumentShip From Location 7102, and the Representation/Association term isDetails 7104.

For the Internal ID 7106, the Category is Element 7108, the Object Classis Business Transaction Document Ship From Location 7110, the PropertyQualifier term is Internal 7112, the Property is Identification 7114,the Representation/Association term is Identifier 7116, the Type term isCDT 7118, and the Type Name term is Location Internal ID 7120. TheCardinality is zero or one 7122.

For the Standard ID 7124, the Category is Element 7126, the Object Classis Business Transaction Document Ship From Location 7128, the PropertyQualifier term is Standard 7130, the Property is Identification 7132,the Representation/Association term is Identifier is 7134, the Type termis 7136, and the Type Name term is Location Standard ID 7138. TheCardinality is zero or one 7140.

For the Buyer ID 7142, the Category is Element 7144, the Object Class isBusiness Transaction Document Ship From Location 7146, the PropertyQualifier term is Buyer 7148, the Property is Identification 7150, theRepresentation/Association term is Identifier 7152, the Type term is CDT7154, and the Type Name term is Location Party ID 7156. The Cardinalityis zero or one 7158.

For the Seller ID 7160, the Category is Element 7162, the Object Classis Business Transaction Document Ship From Location 7164, the PropertyQualifier term is Seller 7166, the Property is Identification 7168, theRepresentation/Association term is Identifier 7170, the Type term is CDT7172, and the Type Name term is Location Party ID 7174. The Cardinalityis zero or one 7176.

For the Product Recipient ID 7178, the Category is Element 7180, theObject Class is Business Transaction Document Ship From Location 7182,the Property Qualifier term is Product Recipient 7184, the Property isIdentification 7186, the Representation/Association term is Identifier7188, the Type term is CDT 7190, and the Type Name term is LocationParty ID 7192. The Cardinality is zero or one 7194.

For the Vendor ID 7196, the Category is Element 7198, the Object Classis Business Transaction Document Ship From Location 7199, the PropertyQualifier term is Vendor 7101 A, the Property is Identification 7102A,the Representation/Association term is Identifier 7103A, the Type termis CDT 7104A, the and Type Name term is Location Party ID 7105A. TheCardinality is zero or one 7106A.

For the Address 7107A, the Category is Element 7108A, the Object Classis Business Transaction Document Ship From Location 7109A, the Propertyis Address 7110A, the Representation/Association term is Address 7111A,the Type term is GDT 7112A, and the Type Name term is Address 7113A. TheCardinality is zero or one 7114A.

For the Note 7115A, the Category is Element 7116A, the Object Class isBusiness Transaction Document Ship From Location 7117A, the Property isNote 7118A, the Representation/Association term is Text 7119A, the Typeterm is GDT 7120A, and the Type Name term is Note 7121A. The Cardinalityis zero or one 7122.

For the Loading Location 7123A, the Category is Element 7124A, theObject Class is Business Transaction Document Ship From Location 7125A,the Property is Loading Location 7126A, the Representation/Associationterm Business Transaction Document Location 7127A, the Type term is GDT7128A, and the Type Name term is Business Transaction Document Location7129A. The Cardinality is zero or one 7130A.

InternalID refers to a proprietary identifier that is used when bothsender and recipient can access shared master data (extendedenterprise). StandardID refers to a standardized identifier for thislocation, whose identification scheme may be managed by an agency fromthe DE 3055 code list. BuyerID refers to an identifier that is usedproprietarily by the BuyerParty for this location. SellerID refers to anidentifier that is used proprietarily by the SellerParty for thislocation. ProductRecipientID refers to an identifier that is usedproprietarily by the ProductRecipientParty for this location. VendorIDrefers to an identifier that is used proprietarily by the VendorPartyfor this location. Address refers to an address that describes thelocation by indicating postal address, geographic coordinates, and thelike. Note refers to an additional information such as directions.LoadingLocation refers to one loading location. The loading locations isa location itself and can be identified proprietarily orpartner-specifically.

When defining addresses, organization addresses are supported. Thedifferent IDs of a BusinessTransactionDocumentShipFromLocation mayidentify the same location. A location may be identified by theInternalID when sender and recipient can access shared master data, bythe StandardID when sender and recipient can manage standardizedidentifiers or by the PartyIDs when sender and recipient are interestedin the PartyIDs assigned by the parties involved. Of the IDs availableto the sender, those that the recipient is expected to understand may beused.

(kk) BusinessTransactionDocumentShipToLocation

A CDT BusinessTransactionDocumentShipToLocation 7200 contains theinformation that is exchanged in business documents about a locationrelevant for business transactions and to which goods or services areshipped. This information identifies the location, its address and, ifnecessary, a different unloading location. The identification may be acompany-internal ID, a standardized ID, or one or many partner-specificIDs. A location is a logical or a physical place. An ID assigned by aparty identifies in the name the role the assigning party plays in thebusiness transaction. Roles include Buyer, Seller, Product-Recipient,and Vendor. An example of CDT BusinessTransactionDocumentShipToLocation7200 is: <ReplenishmentOrder>    ...    <ShipToLocation>      <StandardID schemeAgencyID=“016”>4711</StandardID>      <SellerID>487847</SellerID>       <Address>...</Address>      <UnloadingLocation>...</UnloadingLocation>    </ShipToLocation></ReplenishmentOrder>.

The structure of CDT Business Transaction Document Ship To Location 7200is depicted in FIG. 72. For the CDT Business Transaction Document ShipTo Location 7200, Object Class is Business Transaction Document Ship ToLocation 7202, and the Representation/Association term is Details 7204.

For the CDT Internal ID 7206, the Category is Element 7208, the ObjectClass is Business Transaction Document Ship To Location 7210, theProperty Qualifier term is Internal 7212, the Property is Identification7214, the Representation/Association term is Identifier 7216, the Typeterm is CDT 7218, and the Type Name term is Location Internal ID 7220.The Cardinality is zero or one 7222.

For the CDT Standard ID 7224, the Category is Element 7226, the ObjectClass is Business Transaction Document Ship To Location 7228, theProperty Qualifier term is Standard 7230, the Property is Identification7232, the Representation/Association term is Identifier 7234, the Typeterm is CDT 7236, the Type Name term is Location Standard ID 7238, andthe Cardinality is zero or one 7240.

For the Buyer ID 7242, the Category is E 7244, the Object Class isBusiness Transaction Document Ship To Location 7246, the PropertyQualifier term is Buyer 7248, the Property is Identification 7250, theRepresentation/Association term is Identifier 7252, the Type term is CDT7254, the Type Name term is Location Party ID 7256, and the Cardinalityis zero or one 7258.

For the Seller ID 7260, the Category is Element 7262, the Object Classis Business Transaction Document Ship To Location 7264, the PropertyQualifier term is Seller 7266, the Property is Identification 7268, theRepresentation/Association term is Identifier 7270, the Type term is CDT7272, the Type Name term is Location Party ID 7274, and the Cardinalityis zero or one 7276.

For the Product Recipient ID 7278, the Category is Element 7280, theObject Class is Business Transaction Document Ship To Location 7282, theProperty Qualifier term is Product Recipient 7284, the Property isIdentification 7286, the Representation/Association term is Identifier7288, the Type term is CDT 7290, the Type Name term is Location Party ID7292, and the Cardinality is zero or one 7294.

For the Vendor ID 7296, the Category is Element 7298, the Object Classis Business Transaction Document Ship To Location 7299, the PropertyQualifier term is Vendor 7201A, the Property is Identification 7201A,the Representation/Association term is Identifier 7202, the Type term isCDT 7203A, the Type Name term is Location Party ID 7204, and theCardinality is zero or one 7205A.

For the Address 7206A, the Category is E 7207A, the Object Class isBusiness Transaction Document Ship To Location 7208A, the Property isAddress 7209A, the Representation/Association term is Address 7210A, theType term is GDT 7211, the Type Name term is Address 7212A, and theCardinality is zero or one 7213A.

For the Note 7214A, the Category is Element 7215A, the Object Class isBusiness Transaction Document Ship To Location 7216, the Property isNote 7217A, the Representation/Association term is 7218A, the Type termis GDT 7219A, the Type Name term is Note 7220A, and the Cardinality iszero or one 7221A.

For the Unloading Location 7222A, the Category is Element 7223A, theObject Class is Business Transaction Document Ship To Location E 7224A,the Property is Unloading Location 7225A, the Representation/Associationterm is Business Transaction Document Location 7226A, the Type term isGDT 7227A, the Type Name term is Business Transaction Document Location7228A, and the Cardinality is zero or one 7229A.

InternalID refers to a proprietary identifier that is used when bothsender and recipient can access shared master data. StandardID refers toa standardized identifier for this location, whose identification schememay be managed by an agency from the DE 3055 code list. BuyerID refersto an identifier that is used proprietarily by the BuyerParty for thislocation. SellerID refers to an iIdentifier that is used proprietarilyby the SellerParty for this location. ProductRecipientID refers to anidentifier that is used proprietarily by the ProductRecipientParty forthis location. VendorID refers to an identifier that is usedproprietarily by the VendorParty for this location. Address refers to anaddress that describes the location by indicating postal address,geographic coordinates, and the like. Note refers to an additionalinformation such as directions. UnLoadingLocation refers to an unloadinglocation. The unloading location is a location itself and therefore canbe identified proprietarily or partner-specifically.

When defining addresses, organization addresses may be supported. Thedifferent IDs of a CDT BusinessTransactionDocumentShipToLocation 7200may identify the same location. A location may be identified by theInternalID when sender and recipient can access shared master data, bythe StandardID when sender and recipient can manage standardizedidentifiers, or by the PartyIDs when sender and recipient are interestedin the IDs assigned by the parties involved. Of the IDs available to thesender, those that the recipient is expected to understand may be used.

(ll) BusinessTransactionDocumentTransshipmentLocation

A CDT BusinessTransactionDocumentTransshipmentLocation 7300 contains theinformation that is exchanged in business documents about a relevantlocation for business transactions where goods are transshipped(unloaded and reloaded). This information identifies the location, itsaddress, a loading location, and an unloading location. Theidentification may be a company-internal ID, a standardized ID, or oneor more partner-specific IDs. A location is a logical or a physicalplace. An ID assigned by a party identifies in the name the role theassigning party plays in the business transaction. Roles include Buyer,Seller, ProductRecipient, and Vendor. An example of CDTBusinessTransactionDocumentTransshipmentLocation 7300 is:<ReplenishmentOrder>    ...    <TransshipmentLocation>       <StandardIDschemeAgencyID=“016”>4711</StandardID>       <Address>...</Address>      <LoadingLocation>...</LoadingLocation>      <UnloadingLocation>...</UnloadingLocation>   <TransshipmentLocation> </ReplenishmentOrder>.

The structure of CDT Business Transaction Document TransshipmentLocation 7300 is depicted in FIG. 73. For the CDT Object Class is 7302,the Representation/Association term is Details 7304.

For the Internal ID 7306, the Category is Element 7308, the Object Classis Business Transaction Document Transship Location 7310, the PropertyQualifier term is Internal 7312, the Property is Identification 7314,the Representation/Association term is Identifier 7316, the Type term isCDT 7318, the Type Name term is Location Internal ID 7320, and theCardinality is zero or one 7322.

For the Standard ID 7324, the Category is Element 7326, the Object Classis Business Transaction Document Transship Location 7328, the PropertyQualifier term is Internal 7328, the Property is Identification 7330,the Representation/Association term is Identifier 7332, the Type term isCDT 7334, the Type Name term is Location Internal ID 7336, and theCardinality is zero or one 7338.

For the Buyer 7340, the Category is Element 7342, the Object Class isBusiness Transaction Document Transship Location 7344, the PropertyQualifier term is Buyer 7346, the Property is Identification 7348, theRepresentation/Association term is Identifier 7350, the Type term is CDT7352, the Type Name term is Location Party ID 7354, and the Cardinalityis zero or one 7356.

For the Seller ID 7358, the Category is Element 7360, the Object Classis Business Transaction Document Transship Location 7362, the PropertyQualifier term is Seller 7364, the Property is Identification 7366, theRepresentation/Association term is Identifier 7368, the Type term is CDT7370, the Type Name term is Location Party ID 7372, and the Cardinalityis zero or one 7374.

For the Product Recipient 7376, the Category is Element 7378, the ObjectClass is Business Transaction Document Transship Location 7380, theProperty Qualifier term is Product Recipient 7382, the Property isIdentification 7384, the Representation/Association term is Identifier7386, the Type term is CDT 7388, the Type Name term is Location Party ID7390, and the Cardinality is zero or one 7392.

For the Vendor ID 7394, the Category is Element 7396, the Object Classis Business Transaction Document Transship Location 7398, the PropertyQualifier term is Vendor 7399, the Property is Identification 7301A, theRepresentation/Association term is Identifier 7302A, the Type term isCDT 7303A, the Type Name term is Location Party ID 7304A, and theCardinality is zero or one 7305A.

For the Address 7306A, the Category is Element 7307A, the Object Classis Business Transaction Document Transship Location 7308A, the Propertyis 7309A, the Representation/Association term is Address 7310A, the Typeterm is GDT 7311A, the Type Name term is Address 7312A, and theCardinality is zero or one 7313A.

For the Note 7314A, the Category is Element 7315A, the Object Class isBusiness Transaction Document Transship Location 7316A, the Property isNote 7317A, the Representation/Association term is Text 7318A, the Typeterm is GDT 7319A, the Type Name term is Note 7320A, and the Cardinalityis zero or one 7321A.

For the Loading Location 7322A, the Category is Element 7323A, theObject Class is Business Transaction Document Transship Location 7324A,the Property is Loading Location 7325A, the Representation/Associationterm is Business Transaction Document Location 7326A, the Type term isGDT 7327A, the Type Name term is Business Transaction Document Location7328A, and the Cardinality is zero or one 7329A.

For the Unloading Location 7330A, the Category is Element 7331A, theObject Class is Business Transaction Document Transshipment Location7332A, the Property is Unloading Location 7333A, the.Representation/Association term is Business Transaction DocumentLocation 7334A, the Type is GDT 7335A, the Type Name is BusinessTransaction Document Location 7336A, and the Cardinality is zero or one7337A.

InternalID refers to a proprietary identifier that is used when bothsender and recipient can access shared master data. StandardID refers toa standardized identifier for this location, whose identification schememay be managed by an agency from the DE 3055 code list. BuyerID refersto an identifier that is used proprietarily by the BuyerParty for thislocation. SellerID refers to an iIdentifier that is used proprietarilyby the SellerParty for this location. ProductRecipientID refers to anidentifier that is used proprietarily by the ProductRecipientParty forthis location. VendorID refers to an identifier that is usedproprietarily by the VendorParty for this location. Address refers to anaddress that describes the location by indicating postal address,geographic coordinates, and the like. Note refers to an additionalinformation such as directions. LoadingLocation refers to one loadinglocation, which is a location itself and can be identified proprietarilyor partner-specifically. UnLoadingLocation refers to an unloadinglocation, which is also a location itself and therefore can beidentified proprietarily or partner-specifically.

When defining addresses, organization addresses may be supported. Thedifferent IDs of a CDT BusinessTransactionDocumentTransshipmentLocation7300 may identify the same location. A location may be identified by theInternalID when sender and recipient can access shared master data, bythe StandardID when sender and recipient can manage standardizedidentifiers, or by the PartyIDs when sender and recipient are interestedin the IDs assigned by the parties involved. Of the IDs available to thesender, those that the recipient is expected to understand may be used.

(mm) BusinessTransactionDocumentTypeCode

The GDT BusinessTransactionDocumentTypeCode 7400 is a codedrepresentation of the type of a document that occurs in businesstransactions. The document type describes the nature of similardocuments and defines the basic features of the documents of this type.An example of GDT BusinessTransactionDocumentTypeCode 7400 is:

<BusinessTransactionDocumentTypeCode>001</BusinessTransactionDocumentTypeCode

The structure of GDT Business Transaction Document Type Code 7400 isdepicted in FIG. 74. For the GDT Business Transaction Document Type Code7400, the Object Class is Business Transaction Document 7402, theProperty is Type 7404, the Representation/Association term is Code 7406,the Type term is CCT 7408, the Type Name term is Code 7410, the Lengthis three 7412. The GDT Business Transaction Document Type Code 7400 maybe restricted 7414.

GDT BusinessTransactionDocumentTypeCode 7400 may have a value from 001and 005. 001 indicates a purchase order. In an example, a PurchaseOrderis a request from a buying party to a seller to provide or delivercertain quantities of products on one or several dates. For the buyingparty, the commitments resulting from the request are legally bindingfor a certain period. On acceptance by the seller, they are binding forboth parties. 002 indicates a sales contract, which is a frameworkagreement with a customer concerning the supply of products in a certainperiod. 003 indicates a Quote, which is an offer from a selling party toa buying party to supply or deliver products at predefined conditions.004 indicates an invoice, which may be a legally binding notificationconcerning claims or liabilities for delivered products and servicesrendered. 005 indicates a credit memo, which is a notification to abeneficiary regarding an invoice that reduces the balance of the paymentor liabilities.

The GDT BusinessTransactionDocumentTypeCode 7400 is used, for example,to categorize business transaction documents into messages if thedocument type is not already apparent based on the message. Applicationsprovide “service-driven” interfaces—the messages of these interfaces canbe filled from various applications from different underlying documents.However, the “service” application has to know the type of businesstransaction document in question such as the document type from whichthe message arose. For example DeliveryExecutionRequest refers to aconsistent request to Logistics to prepare and execute goods receipts ordeliveries, BillingDueNotification refers to a creation of the billingdue list based on data from various applications and business documents,and PaymentDueNotification refers to a creation of payment dues based ondata from various applications and business documents.

Messages correspond to business documents. Such a business documentcontains a business document object. A business document object may be aBusiness Transaction Document or a Master Data Document. The GDTBusinessTransactionDocumentTypeCode 7400 categorizes the BusinessTransaction Document.

In an example, in R/3, the BusinessTransactionDocumentTypeCodecorresponds in principle, to VBTYP in Sales or BSTYP in Purchasing orMRM_REFERENZBELEG in Invoice Verification, and the like. The Code Namesdefined in the code list may also be used in the tag names of the XMLinstance for references to Business Transaction Documents.

(nn) BusinessTransactionExecutionStatusCode

The GDT BusinessTransactionExecutionStatusCode 7500 is an encodedrepresentation of the status of the execution of a business transaction.An example of GDT BusinessTransactionExecutionStatusCode 7500 is:

<GoodsIssueExecutionStatusCode>3</GoodsIssueExecutionStatusCode>.

The structure of GDT Business Transaction Execution Status Code 7500 isdepicted in FIG. 75. For the GDT Business Transaction Execution StatusCode 7500, the Object Class is Business Transaction 7502, the Propertyis Execution Status Code 7504, the Representation/Association term isCode 7506, the Type term is CCT 7508, the Type Name term is Code 7510,and the Length is one 7512. The GDT Business Transaction ExecutionStatus Code 7500 may be restricted 7514.

GDT BusinessTransactionExecutionStatusCode 7500 may have a proprietarycode of 1, 2, or 3. 1 indicates that the execution of a businesstransaction has not yet started, 2 indicates that a business transactionis currently being executed, and 3 indicates that the execution of abusiness transaction has been completed.

When using the GDT BusinessTransactionExecutionStatusCode 7500 for acertain business transaction, the part of the name “BusinessTransaction”of the GDT is replaced by the English description of the businesstransaction. In a variation, business transactions from the code list ofthe GDT BusinessTransactionTypeCode 7500 are allowed. For example, theexecution status of a “GoodsIssue” is specified by theGoodsIssueExecutionStatusCode and the execution status of a“GoodsPutaway” is specified by the GoodsPutawayExecutionStatusCode.

The execution status of a business transaction in Sales (Sales andDelivery) may be represented in R/3 by the data element STATV.

GDT BusinessTransactionBlockedIndicator 5300 indicates whether or notthe execution of a business transaction is blocked. While the GDTBusinessTransactionExecutionStatusCode 7500 indicates the currentexecution status of a business transaction, the GDTBusinessTransactionBlockedIndicator 5300 shows whether or not theexecution of a business transaction should start or be continued. Forexample, when a delivery is requested, it can also be requested that thedelivery not be executed.

GDT BusinessTransactionCompletedIndicator 5400 indicates whether or notthe execution of a business transaction has been completed. Thisindicator specifies whether or not a business transaction is regarded ascompleted, regardless of its execution status. For example, a deliverythat is being executed can be considered completed, even though theentire quantity has not been delivered.

(oo) BusinessTransactionPriorityCode

The GDT BusinessTransactionPriorityCode 7600 is a coded representationof the ranking of a business transaction in terms of its urgency. Theassignment of a priority always creates a sequence such that a uniquepredecessor-successor relationship exists between the individual valuesof a priority and they can be sorted uniquely. An example of GDTBusinessTransactionPriorityCode 7600 is: <PriorityCode>1</PriorityCode>.

The structure of GDT Business Transaction Priority Code 7600 is depictedin FIG. 76. For the GDT Business Transaction Priority Code 7600, theObject Class is Business Transaction 7602, the Property is Priority Code7604, the Representation/Association term is Code 7606, the Type term isCCT 7608, the Type Name term is Code 7608, and the Length is one 7610.The GDT Business Transaction Priority Code 7600 may be restricted 7612.

For example, business transactions that are assigned a higher priorityare more important, are required more urgent or have to be carried outfirst and are therefore considered first or are given preference duringselection and processing.

The codes that may be used for GDT BusinessTransactionPriorityCode 7600are 1, 2, 3, and 7. 1 means the transaction is to be done immediately, 2means it is to be performed before any non-urgent task, 3 means it is tobe done as routine work, and 7 means it is a low priority. The sequenceof urgency is: 1, 2, 3, 7.

Priorities are assigned in nearly all business areas such as to specifydelivery priorities, the urgency of an e-mail, posting priorities,deduction priorities, or urgency of a problem. For example, the deliveryof product ABC is of particular importance to customer 4711. Thereforeorders/order items containing this product are treated with preferenceand receive the delivery priority “immediate.”

Since information describing priorities can be communicated in manydifferent areas, the definition is kept general. In particular, incertain circumstances, the context determines which standard andtherefore with which code list the “PriorityCode” should be communicated(e.g., “very high,” “high,” “medium,” “low,” or “A,” . . . , “Z”). In avariation, proprietary code lists are used that were agreed upon by thecommunication partners individually.

For example, in the area of R/3 shipping, a delivery priority of thetype NUMC, length 2.0, is used with codes 01 (High), 02 (Normal) and 03(Low).

“BusinessTransaction” is replaced in the XML instance by the descriptionof the respective business transaction, e.g., “delivery” (see Use forBusinessTransactionPriorityCodeDelivery in DeliveryTerms).

(pp) BusinessTransactionTypeCode

The GDT BusinessTransactionTypeCode 7700 is a coded representation ofthe type of a business transaction. A business transaction is aself-sufficient, logical commercial transaction that results in a valuechange, a quantity change, or an event. An example of GDTBusinessTransactionTypeCode 7700 is:

<BusinessTransactionTypeCode>0001</BusinessTransactionTypeCode>.

The structure of BusinessTransactionTypeCode is depicted in FIG. 77. Forthe GDT Business Transaction Execution Status Code 7700, the ObjectClass is Business Transaction 7702, the Property is Execution StatusCode 7704, the Representation/Association term is Code 7706, the Typeterm is CCT 7708, the Type Name term is Code 7710, and the Length is one7712. The GDT Business Transaction Execution Status Code 6000 may berestricted 7714 GDT.

GDT BusinessTransactionTypeCode 7700 is based on a proprietary codelist. The data type is used for internal business processes or A2Ainterfaces. One possible value for BusinessTransactionTypeCode is 0001,which refers to Service Entry. A service entry is an entry for the typeand scope of services provided by a seller. The entry is the basis forcreating an invoice. A ServiceAcknowledgementRequest message can be sentbased on the entry.

A GDT BusinessTransactionTypeCode 7700 may be used to provide accountingwith information about the type of a business transaction, thequantities, amounts, and other data from this business transaction. Inaccounting, the business transaction type is a central control elementfor the document structure, account determination, and the like.

For a business application area (e.g., accounting), the GDTBusinessTransactionTypeCodes 7700 have the same level of detail. Thismeans that there may be no refinement or grouping relationships betweenthe codes of an area. The codes to be used from the code list in theinterface are defined for each interface that uses the GDTBusinessTransactionTypeCode 7700. For every interface that uses the GDTBusinessTransactionTypeCode 7700 the admissible codes may be specifiedin the interface documentation.

Business transactions create or change BusinessTransactionDocuments. Thedata types GDT BusinessTransactionTypeCode 7700 andBusinessTransactionDocumentTypeCode are therefore closely related. Sincecomplex business transactions (e.g., confirmation of a production order)create or change several business documents, however, in a variation, itmay not be possible to create a simple (1:1 or 1:n) relationship betweenthe code lists of these data types.

(qq) CashDiscount

A GDT CashDiscount 7800 is an agreement on the percentage of cashdiscount that is granted during a sales transaction when payment takesplace within a certain number of days after the baseline date forpayment has passed. An example of GDT CashDiscount 7800 is:<MaximumCashDiscount>    <DaysValue>15</DaysValue>   <Percent>1.75</Percent> </MaximumCashDiscount>.

The structure of GTD CashDiscount is depicted in FIG. 78. For the GDTCash Discount term 7802 and the Representation/Association term is Code7804.

GDT CashDiscount 7800 includes elements DaysValue and Percent from thecore component type ‘numeric’. DaysValue is the number of days after thebaseline payment date has passed. The number of days can be a wholenumber from 1 to 999.

For the Days Value Code 7806, the Category is Element, the Object Classis Cash Discount 7810, the Property is Days 6004, theRepresentation/Association term is Code 7814, the Type term is GDT 7816,the Type Name term is Code 7818, and the Length is from one to three7820. The Cardinality is zero or one 7822.

Percent is the cash discount percentage rate. It is a decimal numberwith a maximum of two places before the decimal point and three placesafter the decimal point. For the Percent Code 7806, the Category isElement, the Object Class is Cash Discount 7828, the Property is Percent6004, the Representation/Association term is Percent 783214, the Typeterm is GDT 783416, the Type Name term is Percent 7836, and the Lengthis maximum five digits with three places after the decimal point 7838.The Cardinality is zero or one 7840.

GDT CashDiscount 7800 is used in the Global Data Type CashDiscountTermsto define cash discount levels.

(rr) CashDiscountTerms

GDT CashDiscountTerms 7900 are payment conditions for goods andservices. An example of GDT CashDiscountTerms 7900 is:<CashDiscountTerms>    <MaximumCashDiscount>      <DaysValue>15</DaysValue>       <Percent>1.75</Percent>   </MaximumCashDiscount>    <NormalCashDiscount>      <DaysValue>30</DaysValue>       <Percent>0.50</Percent>   </NormalCashDiscount>   <FullPaymentDueDaysValue>40</FullPaymentDueDaysValue> </CashDiscountTerms >.

The structure of GDT CashDiscountTerms 7900 is depicted in FIG. 79. TheGDT Payment Baseline Date Terms 7900 includes elements scheme 7908, theCash Discount term is 7910, the Property Payment Baseline Date term is7912, the Representation/Association Date term is 7914, the Type term isGDT 7916, the Type Name term is Date 7918. The Cardinality is zero orone 7920.

For the GDT Maximum Cash Discount term is 7922 and includes elementscheme 7924, the Cash Discount term is 7926, the Property Maximum CashDiscount term is 7928, the Representation/Association Details term is7930, the Type term is GDT 7932, the Type Name term is Cash Discount7934. The Cardinality is zero or one 7936.

For the GDT Maximum Cash Discount term is 7938 and includes elementscheme 7940, the Cash Discount term is 7942, the Property Normal CashDiscount term is 7944, the Representation/Association Details term is7946, the Type term is GDT 7948, the Type Name term is Cash Discount7950. The Cardinality is zero or one 7952.

For the GDT Full Payment Due Days Value term is 7954 and includeselement scheme 7956, the Cash Discount term is 7960, the Property FullPayment Due Days term is 7928, the Representation/Association Value termis 7964, the Type term is GDT 7966, the Type Name term is Integer Value7934, the Length is from one and 7970. The Cardinality is zero or one7972.

PaymentBaselineDate refers to a payment baseline date such as the datefrom which the payment periods run. MaximumCashDiscount refers to themaximum cash discount for rapid payments. NormalCashDiscount refers tothe normal cash discount. FullPaymentDueDaysValue refers to the numberof days after the payment baseline date within which the full payment(e.g., of an invoice) should take place.

MaximumCashDiscount may be present when NormalCashDiscount is offered,as well. Therefore, NormalCashDiscount may be used if a cash discountpercentage rate is specified. If both MaximumCashDiscount andNormalCashDiscount are specified, MaximumCashDiscount.DaysValue may be<NormalCashDiscount.DaysValue, and MaximumCashDiscount.Percent may be >NormalCashDiscount.Percent.MaximumCashDiscount.DaysValue<=NormalCashDiscount.DaysValue<=FullPaymentDueDaysValuemay be true. The number of days in FullPaymentDueDaysValue can be awhole number from 1 to 999. PaymentBaselineDate is specified whenconditions for a concrete payment are transmitted, e.g., for an invoice.This element does not apply when the payment baseline date has not yetbeen set such as in the case of an order.

GDT CashDiscountTerms 7900 are used to establish payment conditions,e.g., for an order or when creating an invoice for goods and services.

(ss) CatalogueID

A GDT CatalogueID 8000 is a unique identifier for a catalog. A catalogis a systematically arranged directory of objects of a particular typethat are identified uniquely within the catalog. An example of GDTCatalogueID 8000 is: <CatalogueID schemeID=‘ProductCatalogues’schemeAgencyID=‘123456789’schemeAgencySchemeAgencyID=‘16’>MyProducts2002</CatalogueID>.

The structure of GDT CatalogueID 8000 is depicted in FIG. 80. For theGDT CatalogueID 8000 the Object Class Catalog term is 8002, the PropertyIdentification term is 8004, the Representation/Association Identifierterm is 8006, the Type term is CCT 8008, the Type Name term isIdentifier 8010, and the Length is from one to forty 8012. TheCatalogueID may be restricted 8014.

GDT schemeID 8016 includes attribute scheme 8018, the Object ClassCatalog term is 8020, the Property Identification term is 8022, theRepresentation/Association Identifier term is 8024, the Type term is xsd8026, the Type Name term is Token 8028, the Length is from one to 608030. The Cardinality is zero or one 8032.

GDT schemeAgencyID 8034 includes attribute scheme 8036, the Object ClassIndentificationSchemeAgency term is 8038, the Property Identificationterm is 8040, the Representation/Association Identifier term is 8042,the Type term is xsd 8044, the Type Name term is Token 8046, the Lengthis from 1 to 60 and 8048. The Cardinality is zero or one 8050.

GDT schemeAgencySchemeID 8052 includes attribute scheme 8054, the ObjectClass IdentificationSchemeAgency term is 8056, the Property Scheme termis 8058, the Representation/Association Identifier term is 8060, theType term is xsd 8062, the Type Name term is Token 8064, the Length isfrom 1 to 60 and 8066. The Cardinality is zero or one 8068.

GDT schemeAgencySchemeAgencyID 8070 includes attribute scheme 8072, theObject Class IdentificationSchemeAgency term is 8074, the PropertySchemeAgency term is 8076, the Representation/Association Identifierterm is 8078, the Type term is xsd 8080, the Type Name term is Token8082, the Length is three 8084. The Cardinality is zero or one 8086.

GDT CatalogueID 8000 is from the core component type (CCT) Identifier.CatalogueID is used to identify a catalog uniquely. Examples of typicalcatalogs are electronic product or vendor catalogs. The attributesschemeId, schemeAgencyID, schemeAgencySchemeID, andschemeAgencySchemeAgencyID are used in the same way as planned for theCCT Identifier, in order to define the context for which a CatalogueIDis guaranteed to be unique.

(tt) CatalogueItemID

A GDT CatalogueItemID 8100 is the unique identifier for an object withina catalog and is unique within the context of the catalog. An example ofGDT CatalogueItemID 8100 is:<CatalogueItemID>1AXX3332-0</CatalogueItemID>.

The structure of GDT CatalogueItemID 8100 is depicted in FIG. 81. Forthe GDT CatalogueItemId 8160, the Object Class CatalogueItem term is8102, the Property Identification term is 8104, theRepresentation/Association Identifier term is 8106, the Type term is CCT8108, the Type Name term is Identifier 8110, and the Length is from oneto forty 8112. The GDT CatalogueItemID 8100 is 8114.

GDT CatalogueItemID 8100 is from the CCT Identifier. CatalogueItemID isa character string that has a maximum length of 40 characters and thatconforms to the rules defined for xsd: token. CatalogueItemID is used toidentify an object uniquely within a catalog.

(uu) CatalogueReference

A GDT CatalogueReference 8200 is a unique reference to a catalog or toan object within a catalog. A catalog is a list of objects of aparticular type that are uniquely identified within the list and thathave access functions for this list. An example of GDTCatalogueReference 8200 is:    <CatalogueReference>       <CatalogueIDschemeID=‘ProductCatalogues’ schemeAgencyID=‘123456789’schemeAgencySchemeAgencyID=‘16’>MyProducts2002</CatalogueID>   <CatalogueItemID>1AXX3332-0</CatalogueItemID>    </CatalogueReference>.

The structure of GDT CatalogueReference 8200 is depicted in FIG. 82. Forthe GDT CatalogueReference 8200 the Object Class is CatalogueReference8202 and the Representation/Association is Details 8204.

For ID 8206, the Category is Element 8208, the Object Class isCatalogueReference 8210, the Property Identification term is 8212, theRepresentation/Association term is Identifier 8214, the Type term is GDT8216, the Type Name term is CatalogueID 8218, and the Cardinality is one8220.

For ItemID 8222, the Category is Element 8224, the Object ClassCatalogueReference term is 8226, the Property Item term isIdentification 8228, the Representation/Association Identifier term is8230, the Type term is GDT 8232, the Type Name term is CatalogueItemID8234, and the Cardinality is from 0 to n 8236.

GDT CatalogueReference 8200 can be used to reference a catalog or anitem within a catalog. For example, the “Order” document can containreferences to a vendor's product catalog.

(vv) CatalogueSchemaID

A GDT CatalogueSchemaID 8300 is a unique identifier for a catalogschema. A catalog schema defines the structure of a catalog by means ofsections which group together similar catalog objects, relationshipsbetween sections, and attributes which can be assigned to all thecatalog items or to catalog items within a particular section. Anexample of GDT CatalogueSchemaID 8300 is:<CatalogueSchemaID>UNSPC</CatalogueSchemaID>.

The structure of GDT CatalogueSchemaID 8300 is depicted in FIG. 83. Forthe GDT CatalogueSchemeID 8300, the Object Class Catalogue Schema termis 8302, the Property is Identification 8304, theRepresentation/Association term is Identifier 8306, the Type term is CCT8308, the Type Name term is Identifier 8310, the Length is from one to40 8312, and the Cardinality is unrestricted 8314.

Characters used for GDT CatalogueSchemaID 8300 may include upper andlowercase characters from A to Z (without German umlauts), digits from 0to 9, − (minus sign), _ (underscore), /, \, and . (period). Nodistinction is made between upper and lowercase characters.

GDT CatalogueSchemaID 8300 is used to identify a catalog schema uniquelywithin the catalog.

(ww) CatalogueSchemaTypeCode

The GDT CatalogueSchemaTypeCode 8400 is a coded representation of thetype of a catalog schema. An example of GDT CatalogueSchemaTypeCode 8400is:

<CatalogueSchemaTypeCode>01</CatalogueSchemaTypeCode>.

The structure of GDT CatalogueSchemaTypeCode 8400 is depicted in FIG.84. For the GDT CatalogueSchemeID 8400, the Object Class CatalogueSchema term is 8402, the Property is Type 8404, theRepresentation/Association term is Code 8406, the Type term is CCT 8408,the Type Name term is Code 8410, and the Length is two 8412. The GDTCatalogueSchemaTypeCode 8400 may be restricted 8414.

Valid values for GDT CatalogueSchemaTypeCode 8400 are 01 and 02. 01 is aneutral schema, which is a schema without identifying the businesssignificance. 02 is a schema for good groups.

(xx) CatalogueSectionID

A GDT CatalogueSectionID 8500 is a unique identifier for a catalogsection. A catalog section is a means of structuring the contents of acatalog using a particular system. A section can contain additionalsections, as well as catalog items and the attributes that describe thetypes of the items. An example of GDT CatalogueSectionID 8500 is:

<CatalogueSectionID>Bicycles</CatalogueSectionID>.

The structure of GDT CatalogueSectionID 8500 is depicted in FIG. 85. Forthe GDT CatalogueSectionID 8500 the Object Class Catalogue Section termis 8502, the Property is Identification 8504, theRepresentation/Association term is Identifier 8506, the Type term is CCT8510, the Type Name term is Identifier 8510, and the Length is from oneto forty 8512. The GDT CatalogueSectionID 8500 may be a restricted GDT.

The characters allowed for GDT CatalogueSectionID 8500 are upper andlowercase characters from A to Z (without German umlauts), digits from 0to 9, − (minus sign), _ (underscore), /, \, and . (period). Nodistinction is made between upper and lowercase characters.

GDT CatalogueSectionID 8500 is used to identify a section uniquelywithin a catalog schema.

(yy) CatalogueSectionTypeID

A GDT CatalogueSectionTypeID 8600 is a unique identifier for a catalogsection type. A catalog section type describes the nature of a catalogsections and defines a set of attributes that is assigned to a sectionof this type. An example of GDT CatalogueSectionTypeID 1700 is:

<CatalogueSectionTypeID>Vehicles<CatalogueSectionTypeID>.

The structure of GDT CatalogueSectionTypeID 8600 is depicted in FIG. 86.For the GDT CatalogueSectionTypeID 8600 the Object Class is CatalogueSection Type 8602, the Property is Identification 8604, theRepresentation/Association term is Identifier 6906, the Type term is CCT8608, the Type Name term is Identifier 8610, and the Length is one 8612.The GDT CatalogueSectionTypeID 8600 may be a restricted GDT.

The characters allowed for GDT CatalogueSectionTypeID 8600 are upper andlowercase characters from A to Z (without German umlauts), digits from 0to 9, − (minus sign), _ (underscore), /, \, and . (period). Nodistinction is made between upper and lowercase characters. Nodistinction is made between upper and lowercase characters.

The GDT CatalogueSectionTypeID 7100 may be unique in the context of thecatalog.

(zz) CatalogueTypeCode

The GDT CatalogueTypeCode 8700 is a coded representation of the type ofa catalog. This is determined by its business purpose, from which thebasic attributes are derived. An example of GDT CatalogueTypeCode 8700is:

<CatalogueTypeCode>01</CatalogueTypeCode>.

The structure of GDT CatalogueTypeCode 8700 is depicted in FIG. 87. Forthe GDT CatalogueTypeCode 8700 the Object Class is Catalog 8702, theProperty is Type 8704, the Representation/Association term is Identifier8706, the Type term is CCT 8708, the Type Name term is Code 8710, andthe Length is one 8712. The GDT CatalogueTypeCode 8700 may be arestricted GDT.

Valid values for GDT CatalogueTypeCode 8700 are 01, 02, and 03. 01refers to a catalog compiled by a company for its own use whenpurchasing products, 02 refers to a product catalog for one vendor for apurchasing company, and 03 refers to a purchase contract product catalogthat contains those products that are included in a special contractwith the conditions agreed in the contract. In one example, a purchasingcatalog (code 01) could be SAP-B2B, for example. The company uses thiscatalog for purchasing. The products contained in the catalog can comefrom different vendors.

(aaa) CatalogueViewID

A GDT CatalogueViewID 8800 is a unique identifier for a catalog view. Acatalog view is a subset of the information contained in the catalog.The view is determined by its catalog schemes, sections, and catalogitems. In addition, individual attributes can be excluded from a view.An example of GDT CatalogueViewID 8800 is:

<CatalogueViewID>ManagerView</CatalogueViewID>.

The structure of GDT CatalogueViewID 8800 is depicted in FIG. 88. Forthe GDT CatalogueViewID 8800, the Object Class is Catalogue View 8802,the Property is Identification 8804, the Representation/Association termis Identifier 8806, the Type term is CCT 8808, the Type Name term isIdentifier 8810, the Length is from one to forty 8812, andCatalogueViewID 8800 may be restricted 8814.

The characters allowed for GDT CatalogueViewID 8800 are upper andlowercase characters from A to Z (without German umlauts), digits from 0to 9, − (minus sign), _ (underscore), /, \, and . (period). Nodistinction is made between upper and lowercase characters. Nodistinction is made between upper and lowercase characters.

The GDT CatalogueViewID 8800 may be in the context of the catalog towhich the view belongs.

(bbb) CompleteTransmissionIndicator

The GDT CompleteTransmissionIndicator 8900 indicates whether an objecttransferred in a message or a transmitted list of similar objects istransmitted in its entirety or not. “Complete Transmission” means thecomplete transmission of data of the object that is relevant for themessage type. “Complete Transmission” is independent of whether the dataat the sender have changed since the last transmission. An example ofGDT CompleteTransmissionIndicator 8900 is:

<CompleteTransmissionIndicator>true</CompleteTransmissionIndicator>.

The structure of GDT CompleteTransmissionIndicator 8900 is depicted inFIG. 89. For the GDT CompleteTransmission Indicator 8900, the ObjectClass is Complete Transmission 8902, the Property is Indicator 8904, theRepresentation/Association term is Indicator 8906, the Type term is CCT8908, and the Type Name term is Indicator 8910.

The GDT CompleteTransmissionIndicator 8900 can have the value true orfalse. True indicates that the objects indicated by the indicator aretransmitted in their entirety. False indicates that the objectsindicated by the indicator are not transmitted in their entirety.

The GDT CompleteTransmissionIndicator 8900 is used for the businessdocument object or for lists of objects. The GDTCompleteTransmissionIndicator 8900 can be used in various ways. First,it can be used for the leading business object of a message data type(business document object), to display its complete or incompletetransmission. In this example, the GDT CompleteTransmissionIndicator8900 is an element of the business document object. If it is set to“true,” then a business document object that already exists at therecipient of the message is replaced completely by the transmittedbusiness document object. If it is set to “false,” then those elementsof the business document object that already exist at the recipient ofthe message for which data is transmitted are updated. All elements forwhich no data is transmitted remain unchanged.

In another example, GDT CompleteTransmissionIndicator 8900 may be usedfor a list of similar objects, to display the complete or incompletetransmission of the list. In this example, the GDTCompleteTransmissionIndicator 8900 is an element of the object thatcontains the list and has the name “xListCompleteTransmissionIndicator,”where “x” is the name of the listed objects. If the GDTCompleteTransmissionIndicator 8900 is set to “true,” the list istransmitted in its entirety with all objects. Objects that are nottransmitted are implicitly considered to be deleted. Transmitted objectsof the list can have an ActionCode, which may be fixed at the value “01”(Create). If the GDT CompleteTransmissionIndicator 8900 is set to“false,” the list is not transmitted in its entirety with all objects.Objects that are not transmitted are considered to be unchanged. Newobjects or objects to be changed or deleted are transmitted. The actionthat is to be taken for an object in the list is controlled by the valueof the assigned ActionCode, where either the hard or soft semantic maybe used exclusively.

A GDT CompleteTransmissionIndicator 8900 that exists in a message typebut is not filled is assumed by default to be “true.” This ensurescompatibility when enhancing interfaces to include a GDTCompleteTransmissionIndicator 8900. The GDTCompleteTransmissionIndicator 8900 can be used at different hierarchylevels within a message type. In order to ensure compatibility whenenhancing interfaces with additional CompleteTransmissionIndicators,higher-level and lower-level CompleteTransmissionIndicators are notinterdependent.

The following is one usage example of GDT CompleteTransmissionIndicator8900:  <BusinessTransactionDocumentChangeRequest>  <BusinessTransactionDocument>    <ID>4800000123</ID>    ... <ItemListCompleteTransmissionIndicator>false</ItemListCompleteTransmissionIndicator>    <Item>     <ID>10</ID>    <ActionCode>02</ActionCode>     ... <ScheduleLineListCompleteTransmissionIndicator>true</ScheduleLineListCompleteTransmissionIndicator>     <ScheduleLine>     <ID>1</ID>      <ActionCode>01</ActionCode>      ...    </ScheduleLine>     <ScheduleLine>      <ID>3</ID>     <ActionCode>01</ActionCode>      ...     </ScheduleLine>    </Item>   <Item>     <ID>30</ID>     <ActionCode>02</ActionCode>     ... <ScheduleLineListCompleteTransmissionIndicator>false</ScheduleLineListCompleteTransmissionIndicator>     <ScheduleLine>     <ID>3</ID>      <ActionCode>03</ActionCode>     </ScheduleLine>   </Item>   </BusinessTransactionDocument> </BusinessTransactionDocumentChangeRequest>

In the usage example above, the message requests a change to thebusiness transaction 4800000123. New or changed items in the businesstransaction, or items to be deleted, are transmitted in the message(ItemListCompleteTranmissionIndicator=“false”). Item 10 is to be changed(ActionCode=“02”). In item 10, all schedule lines are transmitted(ScheduleLineListCompleteTranmissionIndicator=“true”). The ActionCode isfixed at “01” (Create) in schedule lines 1 and 3 of item 10 becauseScheduleLineListCompleteTranmissionIndicator=“true.” Schedule line 2 isdeleted implicitly, because it is not transmitted. Item 20 remainsunchanged, because it is not transmitted. Item 30 is to be changed(ActionCode=“02”). In item 20, new or changed schedule lines, orschedule lines to be deleted are transmitted(ScheduleLineListCompleteTranmissionIndicator=“false”). Schedule lines 1and 2 of item 30 remain unchanged, because they are not transmitted.Schedule line 3 of item 30 is deleted (ActionCode=“03”).

The default case for a message is complete transmission and this may besupported by every system. A business process can thus be recreated inthe event of errors. To improve performance, support for the completetransmission at the segment level should detailed according to theperformance requirements.

Which objects the GDT CompleteTransmissionIndicator 8900 refers to maybe recognizable from the context of the interface in which aCompleteTransmissionIndicator is used. The meaning of a completetransmission of an object may be defined.

(ccc) ConsignmentIndicator

The GDT ConsignmentIndicator 9000 indicates whether the transaction formof the consignment is present or not. In an example, “Consignment” is atransaction form in which the vendor stores a material stock at theordering party at the vendor's expense. The vendor is the owner of thematerials until they are withdrawn from the consignment stores. Thevendor is notified of the withdrawals at regular time intervals and thewithdrawals are then settled accordingly. An example of GDTConsignmentIndicator 9000 is:

<ConsignmentIndicator>true</ConsignmentIndicator>.

The structure of ConsignmentIndicator is depicted in FIG. 90. For theGDT ConsignmentIndicator 9000, the Property term is ConsignmentIndicator 9002, the Representation/Association term is Indicator 9004,the Type term is CCT 9006, and the Type Name term is Indicator 9008.

The GDT ConsignmentIndicator 9000 can have the values true or false.True indicates that the transaction form of consignment is present.False indicates that the transaction form of consignment is not present.

(ddd) ContactPerson

A CDT ContactPerson 9100 is a natural person who is the contact personduring the execution of business processes. CDT ContactPerson 9100identifies the contact person and the contact person's address.Identification can occur using an internal ID and using IDs assigned bythe parties involved. An ID assigned by a party identifies in the namethe role the assigning party plays in the business transaction. Rolesinclude Buyer, Seller, ProductRecipient, Vendor, BillTo, BillFrom andBidder. An example of CDT ContactPerson 9100 is:

Example 1) PartyIDs <ContactPerson> <BuyerlD>9874</BuyerID><SelIerID>487848</SellerID> <Address>...</Address> </ContactPerson>

In the above examples, schemeID=“ContactPersonID” specifies that thescheme CDT ContactPersonID 9100 was used to identify the party, andschemeAgencyID=“BPL_(—)300” specifies that the scheme was assigned bythe SAP CMDM system “BPL_(—)300.”

The structure of CDT ContactPerson 9100 is depicted in FIG. 91. The CDTContactPerson 9100 includes elements InternalID 9106, BuyerID 9124,SellerID 9142, ProductRecipientID 9160, VendorID 9178, BillToID 9196,BillFromID 9107A, BidderID 9116A, and Address 9125A. For the CDTContactPerson 9100, the Object Class is Contact Person 9102 and theRepresentation/Association term is Details 9104.

For the InternalId 9106, the Category is Element 9108, the Object Classis Contact Person 9110, the Property Qualifier term is Internal 9112,the Property is Identification 9114, the Representation/Association termis Identifier 9116, the Type term is CDT 9118, and the Type Name isContactPersonInternalID 9120. The Cardinality between the CDTContactPerson 9100 and the InternalID 9106 is zero or one 9122.

For the BuyerID 9124, the Category is Element 9126, the Object Class isContact Person 9128, the Property Qualifier term is Buyer 9130, theProperty is Identification 9132, the Representation/Association term isIdentifier 9134, the Type term is CDT 9136, and the Type Name term isContactPersonPartyID 9138. The Cardinality between the CDT ContactPerson9100 and BuyerID 9124 is zero or one 9140.

For the SellerID 9142, the Category is Element 9144, the Object Class isContact Person 9146, the Property Qualifier term is Seller 9148, theProperty is Identification 9150, the Representation/Association term isIdentifier 9152, the Type term is CDT 9154, and the Type Name isContactPersonPartyID 9156. The Cardinality between the CDT ContactPerson9100 and SellerID 9142 is zero or one 9158.

For the ProductRecipientID 9160, the Category is Element 9162, theObject Class is Contact Person 9164, the Property Qualifier term isProduct Recipient 9166, the Property is Identification 9168, theRepresentation/Association term is Identifier 9170, the Type term is CDT9172, and the Type Name is ContactPersonPartyID 9174. The Cardinalitybetween the CDT ContactPerson 9100 and ProductRecipientID 9160 is zeroor one 9176.

For the VendorID 9178, the Category is Element 9180, the Object Class isContact Person 9182, the Property Qualifier term is Vendor 9184, theProperty is Identification 9186, the Representation/Association term isIdentifier 9188, the Type term is CDT 9190, and the Type Name term isContactPersonPartyID 9192. The Cardinality between the CDT ContactPerson9100 and VendorID 9178 is zero or one 9194.

For the BillToID 9196, the Category is Element 9198, the Object Class is9199, the Property Qualifier term is 9101A, the Property is 9102A, theRepresentation/Association term is Identifier 9103A, the Type term isCDT 9104A, and the Type Name is ContactPersonPartyID 9105A. TheCardinality between the CDT ContactPerson 9100 and BillToID 9196 is zeroor one 9106A.

For the BillFromID 9107A, the Category is Element 9108A, the ObjectClass is Contact Person 9109A, the Property Qualifier term is BillFrom9110A, the Property is Identification 9111A, theRepresentation/Association term is Identifier 9112A, the Type term isCDT 9113A, and the Type Name term is ContactPersonPartyID 9114A. TheCardinality between the CDT ContactPerson 9100 and BillFromID 9107A iszero or one 9115A.

For the BidderID 9116A, the Category is Element 9117A, the Object Classis Contact Person 9118A, the Property Qualifier term is Bidder 9119A,the Property is Identification 9120A, the Representation/Associationterm is Identifier 9121A, the Type term is CDT 9122A, and the Type Nameterm is ContactPersonPartyID 9123A. The Cardinality between the CDTContactPerson 9100 and BidderID 9116A is zero or one 9124A.

For the Address 9125A, the Category is Element 9126A, the Object Classis Contact Person 9127A, the Property is Address 9128A, theRepresentation/Association term is Address 9129A, the Type term is AGDT9130A, and the Type Name term is Address 9131A. The Cardinality betweenthe CDT ContactPerson 9100 and Address 9125A is zero or one 9132A.

InternalID refers to a proprietary identifier for the CDT ContactPerson9100 that is used when both sender and recipient can access sharedmaster data (extended enterprise). This may be a personnel number.BuyerID refers to an identifier that is used by the BuyerParty for thisCDT ContactPerson 9100. SellerID refers to an identifier that is used bythe SellerParty for this CDT ContactPerson 9100. ProductRecipientIDrefers to an identifier that is used by the ProductRecipientParty forthis CDT ContactPerson 9100. VendorID refers to an identifier that isused by the VendorParty for this CDT ContactPerson 9100. BillToID refersto an identifier that is used by the BillToParty for this ContactPerson.BillFromID refers to an identifier that is used by the BillFromParty forthis ContactPerson. BidderID refers to an identifier that is used by theBidderParty for this party. Address refers to a contact person's address

The different IDs of a BusinessTransactionDocumentParty may identify thesame CDT ContactPerson 9100. There is no StandardID for a CDTContactPerson 9100. A contact person can therefore be identified usingan internal ID, as well as by an ID assigned by an involved party. Thus,a CDT ContactPerson 9100 may be identified by the InternalID when senderand recipient can access shared master data or by theContactPersonPartyIDs when sender and recipient are interested in thePartyIDs assigned by the parties involved

Of the IDs available to the sender, IDs the recipient is expected tounderstand may be used in a message.

The address includes the elements of a personal address.

(eee) ContactPersonID

A GDT ContactPersonID 9200 is a unique identifier for a contact person.GDT ContactPersonID 9200 is a natural person who is the contact personduring the execution of business processes. GDT ContactPersonID 9200identifies the contact person and the contact person's address. Anexample of GDT ContactPersonID 9200 is:

<ContactPersonID schemeID=“PartyID” schemeAgencyID=“BPL_(—)300”schemeAgencySchemeAgencyID=“ZZZ”>

-   -   4711

</ContactPersonID>

In the above example, 4711 refers to a contact person in systemBPL_(—)300, and ZZZ refers to a proprietary Agency.

The structure of GDT ContactPersonID 9200 is depicted in FIG. 92. TheGDT ContactPersonID 9200 includes attributes schemeID 9216,schemeAgencyID 9234, schemeAgencySchemeID 9252 andschemeAgencySchemeAgencyID 9270. For the GDT ContactPersonID 9200, theObject Class is ContactPerson 9202, the Property is Identification 9204,the Representation/Association term is Identifier 9206, the Type term isCCT 9208, the Type Name term is Identifier 9210, the Length is from 1 to60 9212. The GDT ContactPersonID 9200 may be restricted 9214.

For the schemeID 9216, the Category is Attribute 9218, the Object Classis IdentificationScheme 9220, the Property is Identification is 9222,the Representation/Association term is Identifier 9224, the Type term isxsd 9226, the Type Name term is Token 9228, and the Length is from oneto sixty 9230. The Cardinality between the ContactPersonID 9200 and theschemeID 9216 is zero or one 9232.

For the schemeAgencyID 9234, the Category is Attribute A9273, the ObjectClass is IdentificationSchemeAgency 9238, the Property is Identification9240, the Representation/Association term is Identifier 9242, the Typeterm is xsd 9244, the Type Name term is Token 9246, and the Length isfrom one to sixty 9248. The Cardinality between the ContactPersonID iszero or one 9250.

For the schemeAgencySchemeID 9252, the Category is Attribute A9254, theObject Class is IdentificationSchemeAgency 9256, the Property is Scheme9258, the Representation/Association term is Identifier 9260, the Typeterm is xsd 9262, the Type Name term is Token 9264, and the Length isfrom one to sixty 9266. The Cardinality is zero or one 9268.

For the schemeAgencySchemeAgencyID 9270, the Category is AttributeA9272, the Object Class is IdentificationSchemeAgency 9274, the Propertyis SchemeAgency 9276, the Representation/Association term is Identifier9278, the Type term is xsd 9280, the Type Name term is Token 9282, andthe Length is three 9284. The Cardinality is zero or one 9286.

Contact persons may be used as contact persons for a party, not forproducts, and the like. ContactPerson also identifies a contact personfor a party. This can take place explicitly within the GDTBusinessTransactionDocumentParty or implicitly in a message. In thelatter case, the party for which the contact person is being specifiedmay be clear.

In an SAP MDM example, a contact person is a subtype of a party and canbe identified like a party using a GUID or a PartyID.

(fff) ContactPersonInternalID

A CDT ContactPersonInternalID 9300 is a proprietary identifier for acontact person. ContactPerson is a natural person who is the contactperson during the execution of business processes. An example of a CDTContactPersonInternalID 9300 is:

GUID of a contact person:

<ContactPersonInternalID schemeID=“PartyGUID”schemeAgencyID=“MPL_(—)002”>1C743CEC501F6A4D8826C7EC5A8554B9</ContactPersonInternalID>

In the above example, schemeID=“PartyGUID” indicates that the scheme“PartyGUID” was used to identify the contact person, andschemeAgencyID=“MPL_(—)002” indicates that the scheme was assigned bythe business system “MPL_(—)002.”

The following is another example of a CDT ContactPersonInternalID 9300:

Party ID of a contact person:     <ContactPersonInternalIDschemeID=“PartyID”schemeAgencyID=“MPL_002”>4711</ContactPersonInternalID>

The structure of CDT ContactPersonInternalID 9300 is depicted in FIG.93. The CDT ContactPersonInternalID 9300 includes attributes schemeID9318 and schemeAgencyID 9336. For the CDT ContactPersonInternalID 9300,the Object Class is ContactPerson 9302, the Property Qualifier term isInternal 9304, the Property is Identification 9306, theRepresentation/Association term is Identifier 9308, the Type term is GDT9310, the Type Name term is ContactPersonID 9312, and the Length is fromone to thirty-two 9314. The CDT ContactPersonInternalID 9300 may berestricted 9316.

For the schemeID 9318, the Category is Attribute 9320, the Object Classis IdentificationScheme 9322, the Property is Identification 9324, theRepresentation/Association term is Identifier 9326, the Type term is xsd9328, the Type Name term is Token 9330, and the length is from one tosixty 9332. The Cardinality is zero or one 9334.

For the schemeAgencyID 9336, the Category is Attribute 9338, the ObjectClass is IdentificationSchemeAgency 9340, the Property is Identification9342, the Representation/Association term is Identifier 9344, the Typeterm is xsd 9346, the Type Name term is Token 9348, and the Length isfrom one to sixty 9350. The Cardinality is zero or one 9352.

In an example, the attributes of a ContactPersonInternalID may be filledin as follows in an SAP MDM. Scheme ‘Part GUID’ identifies a contactperson using a Global Unique Identifier. SchemeID ‘PartyID’ identifies acontact person using an identification number. SchemeAgencyID is abusiness system in which the identifier was assigned.

The CDT ContactPersonInternalID 9300 represents a projection of the CDTContactPersonID 9300, in which the attributes ‘schemeID’ and‘schemeAgencyID’ are contained for describing an internally assigned ID.If an attribute is not explicitly assigned in the use of the CDT, it maybe determined through the context.

The InternalID is used when both sender and recipient can access sharedmaster data, e.g., during internal communication. In an SAP MDM example,a contact person is a subtype of a party and can be identified like aparty using a GUID or a PartyID.

(ggg) ContactPersonPartyID

A CDT ContactPersonPartyID 9400 is an identifier for a contact personand is assigned by a party. ContactPerson is a natural person who is thecontact person during the execution of business processes. ContactPersonidentifies the contact person and the contact person's address. Anexample of CDT ContactPersonPartyID 9400 is:

<ContactPersonSellerID>4711</ContactPersonSellerID>.

The structure of CDT ContactPersonPartyID 9400 is depicted in FIG. 94.For the CDT ContactPersonPartyID 9400, the Object Class is ContactPerson9402, the Property Qualifier term is Party 9404, the Property isIdentification 9406, the Representation/Association term is Identifier9408, the Type term is GDT 9410, the Type Name term is ContactPersonID9412, and the Length is from one to sixty 9414. The CDTContactPersonPartyID 9400 may be restricted 9416.

The ContactPersonPartyID is the proprietary identifier assigned by aparty. The party (in its role) that assigned this identifier may bederived from the context of the message that the ContactPersonPartyIDuses.

CDT ContactPersonPartyID 9400 limits the general identifier‘ContactPersonID’. In contrast to ‘ContactPersonInternalID’, the use of‘ContactPersonPartyID’ within ContactPerson is also role-dependent(e.g., as an ID assigned by the Buyer).

The party that assigns the ID is indicated by its role. The namecomponent ‘Party’ in ContactPersonPartyID is replaced with thecorresponding role (e.g., ContactPersonSellerID). SchemeID andschemeVersionID may also be included as attributes if there is a needfor differentiating between several schemes.

(hhh) CounterValue

A GDT CounterValue 9500 specifies a value that counts a number thatchanges in fixed increments. An example of GDT CounterValue 9500 is:

<CounterValue>42</CounterValue>.

The structure of GDT CounterValue 9500 is depicted in FIG. 95. For theGDT CounterValue 9500, the Representation/Association Qualifier term isCounter 9502, the Representation/Association term is Value 9504, theType term is xsd 9506, the Type Name term is nonNegativeInteger 9508,and the Length is from one to nine 9510.

GDT CounterValue 9500 is a qualified basic GDT that is based on thesecondary Representation/Association Value of the CCT Numeric and arestriction of xsd: decimal. Non-negative whole numbers less than onebillion may be permitted.

GDT CounterValue 9500 may be used to count dunning notices to a debtor,orders in a queue, or telephone calls that have to be billed. GDTCounterValue 9500 can count forwards and backwards. Changes to aCounterValue may be made in steps of +1 or −1. The permitted value rangecan be restricted depending on how the GDT CounterValue 9500 is used.

While GDT CounterValue 9500 focuses on dynamic changes to numbers,TotalNumberValue describes a static number at a given time or for agiven period. The incremental increase in a set by one element at atime, which can be counted using the CounterValue, can generate linearordering of the elements in the set, which is reflected in the itemnumbers of the elements (OrdinalNumberValue).

(iii) CountryCode

The GDT CountryCode 9600 is a coded representation of a country definedby either national or administrative/political borders. An example ofGDT CountryCode is:

<CountryCode>DE</CountryCode>.

The structure of GDT CountryCode 9600 is depicted in FIG. 96. For theGDT CountryCode 9600, the Property is Country 9602, theRepresentation/Association term is Code 9604, the Type term is CCT 9606,the Type Name term is Code 9608, and the Length is from two to three9610. The GDT CountryCode 9600 may be restricted 9612.

GDT CountryCode 9600 may be represented using an alphabeticaltwo-character code based on ISO 3166-1. ISO 3166-1 may be the defaultcode list.

GDT CountryCode 9600 is used to identify a country defined by nationalor administrative/political borders in a physical address, or toidentify a country of origin.

(jjj) CreditAgencyReportQueryReasonCode

The GDT CreditAgencyReportQueryReasonCode 9700 is the codedrepresentation of the reason for a query to a credit agency for creditinformation. An example of GDT CreditAgencyReportQueryReasonCode 9700is:

<CreditAgencyReportQueryReasonCode>01</CreditAgencyReportQueryReasonCode>.

The structure of GDT CreditAgencyReportQueryReasonCode 9700 is depictedin FIG. 97. For the GDT CreditAgencyReportQueryReasonCode 9700, theObject Class is Credit Agency Report Query 9702, the Property is Reason9704, the Representation/Association term is Code 9706, the Type term isCCT 9708, the Type Name term is Code 9710, and the Length is two 9712.

In an example, the value range of the GDTCreditAgencyReportQueryReasonCode 9700 consists of a proprietary codelist. Possible values are 01 and 02. 01 refers to a business initiationand 02 refers to an existing business connection.

(kkk) CreditAgencyReportRetrievalPermissionIndicator

A GDT CreditAgencyReportRetrievalPermissionIndicator 9800 indicateswhether a party has consented to have credit information about itobtained. An example of GDTCreditAgencyReportRetrievalPermissionIndicator 9800 is:

<CreditAgencyReportRetrievalPermissionIndicator>true</CreditAgencyReportRetrievalPermissionIndicator>

The structure of GDT CreditAgencyReportRetrievalPermissionIndicator 9800is depicted in FIG. 98. For the GDTCreditAgencyReportRetrievalPermissionIndicator 9800, the Object Class isCredit Agency Report 9802, the Property is RetrievalPermission 9804, theRepresentation/Association term is Indicator 9806, the Type term is CCT9808, the Type Name term is Indicator 9810.

GDT CreditAgencyReportRetrievalPermissionIndicator 9800 may have thevalue true or false. True indicates that a party has consented forcredit information about it to be obtained. False indicates that a partyhas not consented for credit information about it to be obtained.

Obtaining credit information from a credit agency such as Dun &Bradstreet or Schufa may be performed, particularly for new businesspartners or for transactions with larger volumes. To comply with thelegal requirements of the country concerned, explicit consent by thebusiness partner may be required. The existence of theCreditAgencyReportRetrievalPermissionIndicator indicates whether thisconsent has been provided.

(lll) CreditAgencyReportScoring

A GDT CreditAgencyReportScoring 9900 is the rating of a party for creditinformation using a scorecard. A scorecard is a scheme used by a creditagency for assessing a party using different characteristics. Severalindividual characteristics are examined for each scorecard, which meansthat several scorecards may be needed for a comprehensive rating. Thisresults in more scorings. An example of GDT CreditAgencyReportScoring9900 is:    <CreditAgencyReportScoring>  <ScoreCardID>5</ScoreCardID> <ResultValue>85</ResultValue>  <Description languageCode=“EN”>ScoreCardfor real  estate</Description> </CreditAgencyReportScoring>.

The structure of GDT CreditAgencyReportScoring 9900 is depicted in FIG.99. The GDT CreditAgencyReportScoring 9900 includes attributesScoreCardId 9908, ResultValue 9926 and Description 9946. For the GDTCreditAgencyReportScoring 9900, the Object Class is CreditAgencyReport9902, the Property is Scoring 9904, and the Representation/Associationterm is Details 9906.

For the ScoreCardID 9908, the Category is Attribute Element 9910, theObject Class is Credit Agency Reporting Scoring 9912, the Property isScore Card Identification 9914, the Representation/Association term isIdentifier 9916, the Type term is GDT 9918, the Type Name term isScoreCardID 9920, and the Length is from one to twenty 9922. TheCardinality is zero or one 9924.

For the ResultValue 9926, the Category is Attribute Element 9928, theObject Class is Credit Agency Report Scoring 9930, the Property isResult 9932, the Representation/Association term is Value 9934, the Typeterm is GDT 9936, the Type Name term is DecimalValue 9938, and theLength is maximum six predecimal digits with two decimal digits 9940.The Cardinality is one 9942. The GDT CreditAgencyReportScoring 9900 maybe restricted 9944.

ScoreCardID identifies the scorecard used by the credit agency.ResultValue is the rating result calculated by the credit agency usingthe scorecard. Description is the description of scoring. ResultValue isunique in the context of the scorecard. The element ScoreCardID may notbe required if this is already determined by the context.

(mmm) CreditCommitmentTypeCode

The GDT CreditCommitmentTypeCode 10000 is the coded representation ofthe type of a payment obligation (liability). An example of GDTCreditCommitmentTypeCode 10000 is:<CreditCommitmentTypeCode>001</CreditCommitmentTypeCode>.

The structure of GDT CreditCommitmentTypeCode 10000 is depicted in FIG.100. For the GDT CreditCommitmentTypeCode 10000, the Object Class isCredit Commitment 10002, the Property is Type 10004, theRepresentation/Association term is Code 10006, the Type term is CCT10008, the Type Name term is Code 10010, and the Length is three 10012.

The value range for the GDT CreditCommitmentTypeCode 10000 may consistof a proprietary code list. Possible values are 001 through 005. 001means liability from a sales order, 002 means liability from anaccounting open item (receivable from delivery and service), 003 meansliability from a special general ledger transaction (down payment,collateral), 004 means liability from a delivery, and 005 meansliability from a billing document.

GDT CreditCommitmentTypeCode 10000 may be used to inform central creditmanagement about the type of payment obligation. The GDTCreditCommitmentTypeCode 10000 may be a proprietary code list with fixedpredefined values. Changes to the permitted values involve changes tothe interface. This code list may correspond to the entries in tableUKM_COMM_TYPE in SAP FSCM Credit Management.

(nnn) CreditRatingCode

The GDT CreditRatingCode 10100 is the coded representation of the ratingof the creditworthiness of a party. An example of GDT CreditRatingCode10100 is:

<CreditRatingCode listAgencyID=“016”>5A1</CreditRatingCode>.

The structure of GDT CreditRatingCode 10100 is depicted in FIG. 101. TheGDT CreditRatingCode 10100 includes attributes listAgencyID 10116 andlistAgencySchemeAgencyID 10134. For the GDT CreditRatingCode 10100, theObject Class is Credit 10102, the Property is Rating 10104, theRepresentation/Association term is Code 10106, the Type term is CCT10108, the Type Name term is Code 10110, and the Length is from one toten 10112. The Cardinality is one 10114.

For the listAgencyID 10116, the Category is Attribute 10118, the ObjectClass is Code List Agency 10120, the Property is Identification 10122,the Representation/Association term is Identifier 10124, the Type termis xsd 10126, the Type Name term is Token 10128, and the Length is fromone to sixty 10130. The Cardinality is zero or one 10132.

For the listAgencySchemeAgencyID 10134, the Category is Attribute 10136,the Object Class is Code List Agency 10138, the Property is SchemeAgency 10140, the Representation/Association term is Identifier 10142,the Type term is xsd 10144, the Type Name term is Token 10146, and theLength is three 10148. The Cardinality is zero or one 10150.

The CreditRatingCode may be a proprietary code list of a credit agency,but may also be a company's credit management code list. The individualvalues of the code represent a score value, for example, a ranking usingGerman school report card grades (1=“very good” through6=“unsatisfactory”) or percentage points. However, there are also codeswhose meaning is explained separately. Code lists that may be used forCreditRatingCode include, for example, Dun & Bradstreet Rating Code,Schufa, Bürgel, Credireform, and Mutually agreed code lists.

For Dun & Bradstreet Rating Code, the ListAgencyID is 016. For Schufa,the ListAgency ID is 344149856 and the ListAgencySchemeAgencyID is 016.For Bürgel, the ListAgency ID is the DUNS number from Bürgel and theListAgencySchemeAgencyID is 016. For Creditreform, the ListAgency ID is325636231 and the ListAgencySchemeAgencyID is 016. For Mutually agreedcode lists, the ListAgencyID is ZZZ.

(ooo) CreditRiskClassCode

The GDT CreditRiskClassCode 10200 is the coded representation for therisk of non-payment. An example of GDT CreditRiskClassCode 10200 is:<CreditRiskClassCode listAgencyID=“016”>A</CreditRiskClassCode>.

The structure of GDT CreditRiskClassCode 10200 is depicted in FIG. 102.The GDT CreditRiskClassCode 10200 includes attributes listAgencyID 10216and listAgencySchemeAgencyID 10234. For the GDT CreditRiskClassCode10200, the Object Class is Credit 10202, the Property is RiskClass10204, the Representation/Association term is Code 10206, the Type termis CCT 10208, the Type Name term is Code 10210, and the Length is ten10212. The Cardinality is one 10214.

For the listAgencyID 10216, the Category is Attribute 10218, the ObjectClass is Code List Agency 10220, the Property is Identification 10222,the Representation/Association term is Identifier 10224, the Type termis xsd, the Type Name term is Token 10228, and the Length is from one tosixty 10230. The Cardinality is zero or one 10232.

For the listAgencySchemeAgencyID 10234, the Category is Attribute 10236,the Object Class is Code List Agency 10238, the Property is SchemeAgency 10240, the Representation/Association term is Identifier 10242,the Type term is xsd 10244, the Type Name term is Token 10246, and theLength is three 10248. The Cardinality is zero or one 10250.

The CreditRiskClassCode may be a proprietary code list of a creditagency, but may also be a company's credit management code list. Theindividual values of the code represent a risk class, for example,“high,” “medium,” or “low.” However, there are also codes whose meaningis explained separately. Codes that may be used for CreditRiskClassCodeinclude, for example, include Dun & Bradstreet Rating Code, Schufa,Bürgel, Credireform, and Mutually agreed code lists.

For Dun & Bradstreet Rating Code, the ListAgencyID is 016. For Schufa,the ListAgency ID is 344149856 and the ListAgencySchemeAgencyID is 016.For Bürgel, the ListAgency ID is the DUNS number from Bürgel and theListAgencySchemeAgencyID is 016. For Creditreform, the ListAgency ID is325636231 and the ListAgencySchemeAgencyID is 016. For Mutually agreedcode lists, the ListAgencyID is ZZZ.

GDT CreditRiskClassCode 10200 is used to represent the risk ofnon-payment involved in a business transaction. The risk of non-paymentrefers to the party involved in the business transaction concerned.

(ppp) CreditSegmentInternalID

A GDT CreditSegmentInternalID 10300 is a proprietary identifier for acredit segment. A credit segment groups a company's businesstransactions from the perspective of credit assignment and control. Anexample of GDT CreditSegmentInternalID 10300 is<CreditSegmentInternalID>2000</CreditSegmentInternalID>

The structure of GDT CreditSegmentInternalID 10300 is depicted in FIG.103. For the GDT Credit Segment Internal ID 10300, the Object Class isCredit Segment 10302, the Property is Internal Identification 10304, theRepresentation/Association term is Identifier 10306, the Type term isCCT 10308, the Type Name term is Identifier 10310, and the Length isfrom one to ten 10312. The GDT Credit Segment Internal ID 10300 may berestricted 10314.

In one variation, the credit segment ID is assigned by a company'scredit manager(s). For this reason, schemeID and schemeAgencyIDattributes may not be required.

A company's business transactions may be grouped into a small number ofcredit segments (from 1 to 5). In credit control, telecommunicationscompanies often distinguish between the product categories such as“fixed network” and “mobile business.” Other grouping criteria may bethe selling organization (SellerParty) or creditor (CreditorParty).

GDT CreditSegmentInternalID 10300 is used when both sender and recipientcan access shared master data.

(qqq) CreditWorthinessChangeReasonCode

The GDT CreditWorthinessChangeReasonCode 10400 is the codedrepresentation of the reason for a change in the creditworthiness of aparty. An example of GDT CreditWorthinessChangeReasonCode 10400 is:

<CreditWorthinessChangeReasonCode>CL</CreditWorthinessChangeReasonCode>.

The structure of GDT CreditWorthinessChangeReasonCode 10400 is depictedin FIG. 104. For the GDT Credit Worthiness Change Reason Code 10400, theObject Class is Credit Worthiness 10402, the Property is Change Reason10404, the Representation/Association term is Code 10406, the Type termis CCT 10408, the Type Name term is Code 10410, and the Length is two10412.

GDT CreditWorthinessChangeReasonCode 10400 may be represented by aproprietary code list. Possible values are 01 through 13. 01 means thecreditworthiness in Credit Management was changed. 02 means the validityperiod of the creditworthiness in Credit Management has expired. 03means the creditworthiness at a credit agency was changed. 04 means thevalidity period of the creditworthiness at a credit agency has expired.05 means the risk class in Credit Management was changed. 06 means thecredit limit was changed (manually or automatically). 07 means thevalidity period of the credit limit has expired. 08 means the creditlimit utilization has changed. 09 means the credit limit utilization hasfallen below 100%. 10 means the credit limit utilization has exceeded100%. 11 means the credit representative has requested a change to thecredit limit; this change is currently in the approval process. 12 meansthe rule governing the creditworthiness check that is defined in themaster data of a party was changed. 13 means a negative response wasreceived regarding the creditworthiness of a party. Changes to thepermitted values require changes to the interface.

(rrr) CreditWorthinessCheckingRuleCode

The GDT CreditWorthinessCheckingRuleCode 10500 is the codedrepresentation of the check procedure to be used to determinecreditworthiness. An example of GDT CreditWorthinessCheckingRuleCode10500 is:

<CreditWorthinessCheckingRuleCode>02</CreditWorthinessCheckingRuleCode>.

The structure of GDT CreditWorthinessCheckingRuleCode 10500 is depictedin FIG. 105. For the GDT Credit Worthiness Checking Rule Code 10500, theObject Class is Credit Worthiness 10502, the Property is Checking Rule10504, the Representation/Association term is Code 10506, the Type termis CCT 10508, the Type Name term is Code 10510, and the Length is two10512.

The value range of the GDT CreditWorthinessCheckingRuleCode 10500 maycomprise a proprietary code list. Possible values are 01 through 04. 01refers to a procedure for determining the creditworthiness of newbusiness customers. 02 refers to a procedure for determining thecreditworthiness of existing business customers. 03 refers to aprocedure for determining the creditworthiness of new private customers.04 refers to a procedure for determining the creditworthiness ofexisting private customers. Changes to the permitted values involvechanges to the interface.

GDT CreditWorthinessCheckingRuleCode 10500 is used, e.g., when queryingthe creditworthiness of a business partner, to define the procedure fordetermining the score and the credit limit.

(sss) CreditWorthinessCheckingSeverityCode

The GDT CreditWorthinessCheckingSeverityCode 10600 is the codedrepresentation of the severity of the checking procedure for determiningcreditworthiness. An example of GDT CreditWorthinessCheckingSeverityCode10600 is:

<CreditWorthinessCheckingSeverityCode>3</CreditWorthinessCheckingSeverityCode>.

The structure of GDT CreditWorthinessCheckingSeverityCode 10600 isdepicted in FIG. 106. For the GDT Credit Worthiness Checking SeverityCode 10600, the Object Class is Credit Worthiness 10602, the Property isChecking Severity 10604, the Representation/Association term is Code10606, the Type term is CCT 10608, the Type Name term is Code 10610, andthe Length is one 10612.

The value range of the GDT CreditWorthinessCheckingSeverityCode 10600may comprise a proprietary code list. Possible values are 1, 2 or 3. 1refers to checks with low severity. 2 refers to checks with mediumseverity. 3 refers to checks with high severity. Thus, the followinglinear order (from low to high severity) applies for the severity of thechecking procedure for determining creditworthiness: 1<2<3. Changes tothe permitted values may involve changes to the interface.

The GDT CreditWorthinessCheckingSeverityCode 10600 may be used whenquerying the creditworthiness of a business partner, in order to definethe severity of the creditworthiness check. For example, if a highseverity check is to be performed for a goods issue, but a low severitycheck is to be performed for a bid.

(ttt) CreditWorthinessIndicator

A GDT CreditWorthinessIndicator 10700 indicates whether a party iscreditworthy or not. An example of GDT CreditWorthinessIndicator 10700is:

<CreditWorthinessIndicator>true</CreditWorthinessIndicator>.

The structure of GDT CreditWorthinessIndicator 10700 is depicted in FIG.107. For the GDT Credit Worthiness Indictor 10700, the Object Class isCurrency 9302, the Property is Indicator 10704, theRepresentation/Association term is Indicator 10706, the Type term is CCT10708, and the Type Name term is Indicator 10710.

GDT CreditWorthinessIndicator 10700 may have the values true or false.True indicates that a party is creditworthy. False indicates that aparty is not creditworthy.

Prior to the sale, rental, or lease of a product, one may check abusiness partner's creditworthiness. The GDT CreditWorthinessIndicator10700 indicates whether or not the business partner is creditworthy.

(uuu) CurrencyCode

The GDT CurrencyCode 10800 is a coded representation of the currency. Anexample of GDT CurrencyCode 10800 is:

<PaymentCurrencyCode>EUR</PaymentCurrencyCode>.

The structure of GDT CurrencyCode 10800 is depicted in FIG. 108. For theGDT Currency Code 10800, the Object Class is Currency 10802, theProperty is Code 10804, the Representation/Association term is Code10806, the Type term is CCT 10808, the Type Name term is Code 10810, andthe Length is three 10812. The GDT Currency Code 10800 may be restricted10814.

GDT CurrencyCode 10800 represents a three-character code according toISO 4217. GDT Amount contains a currency. However, an additionalcurrency can be specified with GDT CurrencyCode 10800. This may be used,for example, for the specification of an alternative payment currency inthe message “Payment Due Notification.”

(vvv) DangerousGoods

GDT DangerousGoods 10900 are substances or objects that, due to theirproperties, present a danger to public safety, to the life and health ofpeople and animals, or to the safety of things. An example of GDTDangerousGoods 10900 is: < DangerousGoods >   <ClassID>1</ ClassID >  <SubClassID >3</SubClassID > </ DangerousGoods >.

The structure of DangerousGoods is depicted in FIG. 109. The GDTDangerousGoods 10900 includes elements ID, RegulationsCode, ClassID, andDivisionID. For the GDT Dangerous Goods 10900, the Object Class isDangerous Goods 10902 and the Representation/Association term is Details10904.

For the ID 10906, the Category is Element 10908, the Object Class isDangerous Goods 10910, the Property is Identification 10912, theRepresentation/Association term is Identifier 10914, the Type term isGDT 10916, the Type Name term is Dangerous Goods ID 10918, the Length isfour 10920, and the Cardinality is zero or one 10922.

For the GDT Regulations Code 10924, the Category is Element 10926, theObject Class is Dangerous Goods 10928, the Property is Regulations10930, the Representation/Association term is Code 10932, the Type termis GDT 10934, the Type Name term is Dangerous Goods Regulation Code10936, the Length is from one to three 10938 and the Cardinality is zeroor one 10940.

For the GDT Class ID 10942, the Category is Element 10944, the ObjectClass is Dangerous Goods 10946, the Property is Class 10948, theRepresentation/Association term is Identifier 10950, the Type term isCCT 10952, the Type Name term is Identifier 10954, the Length is fromone to three 10956, and the Cardinality is zero or one 10958.

For the GDT Division ID 10960, the Category is Element 10962, the ObjectClass is Dangerous Goods 10964, the Property is Division 10966, theRepresentation/Association term is Identifier 10968, the Type term isCCT 10970, the Type Name term is Identifier 10972, the Length is fromone to six 10974, and the Cardinality is zero or one 10976.

ID identifies a hazardous material using the United Nations DangerousGoods (UNDG) Identifier. RegulationsCode is a coded representation ofnational or international dangerous goods rules or regulations accordingto the UN/EDIFACT code list 8273 “Dangerous goods regulations code.”ClassID identifies a dangerous goods class, for example, class 2(Gases). DivisionID identifies a breakdown of the dangerous goods class,for example, division 3 (Toxic Gases). The value ranges and the use ofelements “ClassID” and “DivisionID” can differ from system to system andmay not have a standardized norm.

If the RegulationCode is specified, ClassID may be filled in and, ifnecessary, DivisionID of this RegulationCode may be filled in. In onevariation, dangerous goods rules or regulations can be used that have amaximum of a two steps in their classification scheme. The informationDangerousGoods may be a requirement for an appropriate andenvironmentally-friendly handling, transport, and storage of a product,that is or contains a dangerous good.

GDT DangerousGoods 10900 can be used with the GDTDangerousGoodsIndicator 10900 in that the GDT DangerousGoodsIndicator10900 displays that dangerous goods are contained in a delivery, whilethe GDT DangerousGoods 10900 provides more detail about the danger posedby a delivery item. “Dangerous Goods” is the usual name for dangerousgoods/materials at national and international level. In the USA,however, the term “Hazardous Materials” is also common. The terms“Dangerous Goods” and “Hazardous Materials” and variants of these twoare not used to differentiate between the transport of dangerous goodsand the storage of dangerous goods.

(www) DangerousGoodsID

A GDT DangerousGoodsID 11000 is the unique identifier for a dangerousgood, using the United Nations Dangerous Goods (UNDG) Number. An exampleof GDT DangerousGoodsID 11000 is:<DangerousGoodsID>2453</DangerousGoodsID>.

The structure of GDT DangerousGoodsID 11000 is depicted in FIG. 110. Forthe GDT Dangerous Goods ID 11000, the Object Class is Dangerous Goods11002, the Property is Identification 11004, theRepresentation/Association term is Identifier 11006, the Type term isCCT 11008, the Type Name term is Identifier 11010 and the Length is four11012.

(xxx) DangerousGoodsIndicator

A GDT DangerousGoodsIndicator 11100 indicates whether dangerous goodsare contained in a combination of products or not. An example of GDTDangerousGoodsIndicator 11100 is:<DangerousGoodsIndicator>true</DangerousGoodsIndicator>.

The structure of GDT DangerousGoodsIndicator 11100 is depicted in FIG.111. For the GDT Dangerous Goods Indicator 11100, the Object Class isDangerous Goods 11102, the Property is Indicator 11104, theRepresentation/Association term is Indicator 11106, the Type term is CCT11108, the Type Name term is Indicator 11110, the Length is one 11112,and the Cardinality is zero or one 11114.

GDT DangerousGoodsIndicator 11100 may have the values true or false.True indicates that a combination of products contains dangerous goods.False indicates that a combination of products contains no dangerousgoods.

If the indicator is set, the stipulations for the correspondingdangerous good are valid for the combination. These stipulations may bedetermined by analyzing the message using the GDT DangerousGoods 11100.

GDT DangerousGoodsIndicator 11100 may be used with the GDTDangerousGoods in that the GDT DangerousGoodsIndicator 11100 displaysthat dangerous goods are contained in a combination, and the GDTDangerousGoods provides more detail about the danger posed by a deliveryitem.

(yyy) DangerousGoodsRegulationsCode

The GDT DangerousGoodsRegulationsCode 11200 is the coded representationof a national or international dangerous goods rules or regulationsaccording to the UN/EDIFACT code list 8273 “Dangerous goods regulationscode” An example of GDT DangerousGoodsRegulationsCode 11200 is:

<DangerousGoodsRegulationsCode>GVS</DangerousGoodsRegulationsCode>.

The structure of GDT DangerousGoodsRegulationsCode 11200 is depicted inFIG. 112. For the GDT Dangerous Goods Regulation Code 11200, the ObjectClass is Dangerous Goods 11202, the Property is Regulations 11204, theRepresentation/Association term is Code 11206, the Type term is CCT11208, the Type Name is Code 11210 and the Length is from one to three11212.

In a variation, the possible values for GDTDangerousGoodsRegulationsCode 11200 are described in the UN/EDIFACT codelist 8273 “Dangerous goods regulations code.” These include ADR, ADS,ADT, ADU, AGS, ANR, ARD, CFR, COM, GVE, GVS, ICA, IMD, RGE, RID, UI, andZZZ.

(zzz) Date

A GDT Date 11300 is the specification of an exact day in the Gregoriancalendar. An example of GDT Date 11300 is:<OrderDate>2002-04-19</OrderDate>.

The structure of GDT Date 11300 is depicted in FIG. 113. For the GDTDate 11300, the Property is Date 11302, the Representation/Associationterm is Date 11304, the Type term is CCT 11306, and the Type Name termis Date 11308.

The GDT Date 11300 uses the W3C built-in data type xsd: date. This isstructured according to the extended representation of ISO 8601.

The extended representation of Date is CCYY-MM-DD, for example,2002-04-19. The extended representation uses the literals CC forcentury, YY for year, MM for month, and DD for day. There may also be ahyphen between the year, month, and day.

In a variation, years are represented by a four-character code and theyears 0001 to 9999 are supported. Leading positive or negative signsbefore the year are not supported. Time zones prefixed with thetime-zone-character “Z” may not be supported for the date.

GDT Date 11300 is used to represent points in time or time stamps inwhich the day may be exact.

(aaaa) DatePeriod

A GDT DatePeriod 11400 is a period that is defined by two points intime. These points in time are expressed in calendar days. This timeperiod is determined by a start time and an end time, a start time witha duration, or a duration with an end time. An example of GDT DatePeriod11400 is: <HolidayPeriod>   <StartDate>2003-07-01</StartDate>  <EndDate>2003-10-25</EndDate> </HolidayPeriod>.

The structure of GDT DatePeriod 11400 is depicted in FIG. 114. The GDTDatePeriod 11400 includes elements StartDate, EndDate, and Duration. Forthe GDT Date Period 11400, the Object Class is Date Period 11402 and theProperty is Details 11404.

For the GDT Start Date 11406, the Category is Element 11408, the ObjectClass is Time Period 11410, the Property is Start Date 11412, theRepresentation/Association term is Date 11414, the Type term is GDT11416, the Type Name term is Date 11418, and the Cardinality is zero orone 11420.

For the GDT End Date 11422, the Category is Element 11424, the ObjectClass is Date Period 11426, the Property is End Date 11428, theRepresentation/Association term is Date 11430, the Type term is GDT11432, the Type Name term is Date 11434, and the Cardinality is zero orone 11436.

For the GDT Duration 11438, the Category is Element 11440, the ObjectClass is Date Period 11442, the Property is Duration 11444, theRepresentation/Association term is Duration 11446, the Type term is GDT11448, the Type Name term is Duration 11450, and the Cardinality is zeroor one 11452.

GDT DatePeriod 11400 is an aggregation and includes the sub-elementsStartDate, EndDate, and Duration. StartDate represents the start date inthe time unit based on the extended representation of ISO 8601. EndDaterepresents the end date in the time unit based on the extendedrepresentation of ISO 8601. Duration represents the relative durationbased on convention ISO 8601. The following conventions may be used:years (nY), months (nM) and days (nD), hours (nH), minutes (nM) andseconds (n.nnnS). One example of Duration is<Duration>P1H7M9T</Duration>

The sub-elements in GDT DatePeriod 11400 are optional. However, therepresentation can include one of the following tuples: StartDate andEndDate, StartDate and Duration, or EndDate and Duration. EndDate may begreater than or equal to the StartDate. For example,<StartDate>2003-07-01</StartDate>, <EndDate>2003-10-25</EndDate>.

Period can be used to specify a time period that can be expressed usingtwo predefined dates or one date and one relative duration. This periodmay be the start and end dates of a holiday or the start date andduration in days of a temporary work contract.

The time of day is not specified in GDT DatePeriod 11400. For thisreason, two business partners may agree unambiguously when a date periodbegins and when it ends. For example, it can begin at 00:00:00 and endat 23:59:59. The term “Date” in the “Object Class” of the CDT isredundant. Therefore, it comprises the term “Period.” This is becausethe term “Date” is given by the “Property” of the sub-elements. As aresult, the semantic of this CDT is unique.

(bbbb) DateTime

A GDT DateTime 11500 is the specification of an accurate-to-the-secondtime stamp of a calendar day. An example of GDT DateTime 11500 is:

<ConstructionDateTime>2002-04-19T15:30:00+01:00</ConstructionDateTime>.

The structure of GDT DateTime 11500 is depicted in FIG. 115. For GDTDate Time 11500, the Property is Date Time 11502, theRepresentation/Association term is Date Time 11504, the Type term is CCT11506, the Type Name term is Date Time 11508.

The GDT DateTime 11500 core component may be based on the W3C “built-indatatype” xsd: dateTime. This is structured according to the extendedrepresentation of ISO 8601. The extended representation isCCYY-MM-DDThh:mm:ss(.sss)Z or CCYY-MM-DDThh:mm:ss(.sss)(+/−)hh:mm (forexample, 2002-04-19T15:30:00Z or 2002-04-19T10:30:00+05:00,respectively).

The extended representation uses the literals CC for century (00-99), YYfor year (00-99), MM for month (01-12), and DD for day (01-28 in month02; 01-29 in month 02 when the year is a leap year; 01-30 for months 04,06, 09, and 11; 01-31 for months 01, 03, 05, 07, 08, 10, and 12), hh forhours (00-23), mm for minutes (00-59), ss for seconds (00-59), and .sssfor fractions of a second (up to three decimal places after thedecimal). In addition, there may be a hyphen between the year, month,and day. A separator “T” may be used between the date and time. Zspecifies when the time represented is also UTC time. Also, +hh:mmspecifies when the represented time is a local time that is ahead of UTCtime, and −hh:mm specifies when the represented time is a local timethat is behind UTC time.

The time stamp can be specified without the additional specifications(Z, +hh:mm, −hh:mm) relating to the coordinated world time (UTC time).In a variation, this time stamp is not converted to the respective localtime and is therefore for information purposes.

The following value ranges are defined for DateTime: Day represents alldates from the Gregorian calendar, Time represents exactly 24 hours(0-23), Minutes represents exactly 60 minutes (0-59), Seconds representsexactly 60 seconds (0-59), and Time may be expressed in UTC.

Years are represented by a four-character code (0001 to 9999). In avariation, leading positive or negative signs before the year are notsupported. According to these constraints, the regular expressionrestricts the character pattern of date and time to the following:

[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}[0-9]{2}:[0-9]{2}[0-9]{2}:[0-9]{2}[0-9]{2}(.[0-9]*)?([Z+-][0-9]{2}[0-9]{2}:[0-9]{2}[0-9]{2})?

Nevertheless, meaningless data such as 0000-00-00T00:00Z can berepresented by this regular expression. However, explicit restrictionsmean that this is not possible for the built-in data type “xsd:dateTime”.

GDT DateTime 11500 is used for exact time stamps that contain the dayand time. For example, creation date/time, receipt date/time, processingdate/time, delivery date/time, expiry date/time, and the like.

The primary representation term for the CCT “DateTime” is DateTime.Additional secondary representation terms are Date, which represents acalendar value for a single day and has a built-in data type xsd: dateand a length of 10, and Time, which represents a to-the-second timevalue and has a built-in data type xsd: time.

In the case of a business transaction, DateTime may arise in a specificbusiness role. In the element name, these roles are placed in front ofthe term “DateTime”, whereby additional context-specific qualifiers mayalso be added. For example, PlannedArrivalDateTime is a date/time of aplanned arrival.

Times that are relevant in logistics execution are described in theirlogistical sequence in the table below. Further roles of DateTime arealso described in alphabetical order. DateTime Role English NameDefinition PositioningDateTime Material availability Date/time at whichgoods are made date/time available for packing and picking.IssueDateTime Issue date/time Date/time at which something is issued.PickingDateTime Picking date/time Date/time at which goods are picked.PackingDateTime Packing date/time Date/time at which goods are packed.CarrierHandoverDateTime Date/time of Date/time at which something ishanded handover to the over to the carrier. carrier PickupDateTimePickup date/time Date/time at which goods are picked up. LoadingDateTimeLoading date/time Date/time at which goods are loaded.YardDepartureDateTime Date/time when Date/time of departure of a closedarea something leaves the outside the warehouse in which vehicles yardare loaded and unloaded. ArrivalDateTime Arrival date/time Date/time atwhich something arrives. DeliveryDateTime Delivery date/time Date/timeat which a delivery takes place. ReceiptDateTime Receipt date/timeDate/time at which something is received. YardArrivalDateTime Date/timeof arrival Date/time of arrival in a closed area in the yard outside thewarehouse in which vehicles are loaded and unloaded. UnloadingDateTimeUnloading date/time Date/time at which goods are unloaded.UnpackingDateTime Unpacking date/time Date/time at which goods areunpacked. PutawayDateTime Putaway date/time Date/time at which goods areput away. AvailabilityDateTime Availability Date/time at which somethingis date/time available. AdvertisementDateTime Advertisement Date/time atwhich something is date/time advertised. ChangeDateTime Change date/timeDate/time at which something is changed. CreationDateTime Creationdate/time Date/time at which something is created. ExecutionDateTimeExecution date/time Date/time at which something is executed.OrderingDateTime Ordering date/time Date/time at which an order isexpected or takes place. PlannedDateTime Planned date/time Date/time forwhich something is planned. ValidityDateTime Validity date/timeDate/time at which something is valid.

The coordinated world time or coordinated universal time (UTC) is thestandardized basis for time specifications that are usedinternationally. It is based on solar time and is an extremely constanttime unit. The mean solar time at the Greenwich meridian can be taken asan approximate guide value for UTC. UTC replaced Greenwich Mean Time(GMT) in 1972 as it was more accurate.

The Gregorian calendar is used predominantly in the western world todayand is an approximation of the complicated calculation of a tropicalyear. The length of a mean tropical year is 365.2422 days. The Gregoriancalendar determines the rules for leap years and was introduced in 1582.

(cccc) DateTimePeriod

A GDT DateTimePeriod 11600 is a period that is defined by two points intime. These points in time are expressed by time stamps, accurate to thesecond, together with calendar days. The time period is determined by astart time and an end time, a start time with a duration, or a durationwith an end time. An example of GDT DateTimePeriod 11600 is:<ContractValidityPeriod>  <StartDateTime>2003-03-01T12:00:00</StartDateTime>  <EndDateTime>2005-06-15T12:00:00</EndDateTime></ContractValidityPeriod>.

The structure of GDT DateTimePeriod 11600 is depicted in FIG. 116. TheGDT DateTimePeriod 11600 includes elements StartDateTime 11606,EndDateTime 11622, and Duration 11638. For GDT Date Time Period 11600,the Object Class is Date Time Period 11602, and the Property is Details11604.

For GDT Start Date Time 11606, the Category is Element 11608, the ObjectClass is Date Time Period 11610, the Property term is Start Date Time11612, the Representation/Association term is Date Time 11614, the Typeterm is GDT 11616, the Type Name term is Date Time 11618, and theCardinality is zero or one 11620.

For GDT End Date Time 11622, the Category is Element 11624, the ObjectClass is Date Time Period 11626, the Property term is End Date Time11628, the Representation/Association term is Date Time 11630, the Typeterm is GDT 11632, the Type Name term is Date Time 11634, and theCardinality is zero or one 11636.

For GDT Duration 11638, the Category is Element 11640, the Object Classis Date Time Period 11642, the Property term is Duration 11644, theRepresentation/Association term is Duration 11646, the Type term is GDT11648, the Type Name term is Duration 11650, and the Cardinality is zeroor one 11652.

GDT DateTimePeriod 11600 is an aggregation and includes the sub-elementsStartDateTime, EndDateTime, and Duration. StartDateTime represents theaccurate-to-the-second start time on a calendar day based on theextended representation ISO 8601. EndDateTime represents theaccurate-to-the-second end time on a calendar day based on the extendedrepresentation ISO 8601.

Duration represents the relative duration based on convention ISO 8601.Other representation conventions for year (nY), month (nM), and day (nD)can be used. One example of duration is<Duration>P1H7M9T12H10M13.3S</Duration>.

The sub-elements in GDT DateTimePeriod 11600 are optional. However, therepresentation can include one of the following date sets: StartDateTimeand EndDateTime, StartDateTime and Duration, and EndDateTime andDuration.

The time stamp (EndDateTime) may be greater than or equal to the starttime stamp (StartDateTime) (both accurate to the second). For example,<StartDateTime>2003-03-01T12:00:00</StartDateTime>,<EndDateTime>2005-06-15T18:30:00</EndDateTime>or<StartDateTime>2003-03-01T12:00:00</StartDateTime>,<EndDateTime>2005-03-01T12:00:00</EndDateTime>.

Period can be used to specify a time period and can be expressed usingtwo time stamps (both accurate to the second) or oneaccurate-to-the-second time stamp and one relative duration. This periodmight be the validity of a contract, which is expressed by a start andend time.

In the case of a business transaction, DateTimePeriod arises in aspecific business role. In the element name, these roles are placed infront of the term Period, whereby additional context-specific qualifierscould also be added, for example, PlannedArrivalPeriod is a period of aplanned arrival.

The logistical sequence or the overlapping time periods, which may berelevant in logistical execution, are described in this sequence in thetable below. Further roles of DateTimePeriod are then shown inalphabetical order. Period Role English Name DefinitionTransportPlanningPeriod Transportation Period in which transportationplanning planning period takes place. PositioningPeriod Materialavailability Period in which goods are made available period for packingand picking. IssuePeriod Issue period Period in which something isissued. PickingPeriod Picking period Period in which goods are picked.PackingPeriod Packing period Period in which goods are packed.CarrierHandoverPeriod Period for handover Period in which something ishanded over to to the carrier the carrier. PickupPeriod Pickup periodPeriod in which goods are picked up. LoadingPeriod Loading period Periodin which goods are loaded. YardDeparturePeriod Period when Period ofdeparture of a closed area outside something leaves the the warehouse inwhich vehicles are loaded yard and unloaded. ShippingPeriod Shippingperiod Period in which goods are shipped (between ship-from location,ship-to location, and possibly transshipment location). ArrivalPeriodArrival period Period in which something arrives. DeliveryPeriodDelivery period Period in which a delivery takes place. ReceiptPeriodReceipt period Period in which something is received. YardArrivalPeriodPeriod of arrival in Period of arrival in a closed area outside the theyard warehouse in which vehicles are loaded and unloaded.UnloadingPeriod Unloading period Period in which goods are unloaded.UnpackingPeriod Unpacking period Period in which goods are unpacked.PutawayPeriod Putaway period Period in which goods are put away.AvailabilityPeriod Availability period Period in which something isavailable. AdvertisementPeriod Advertisement Period in which somethingis advertised. period ExecutionPeriod Execution period Period in whichsomething is executed. OrderingPeriod Ordering period Period in which anorder is expected/takes place. PlannedPeriod Planned period Period forwhich something is planned. PlanningPeriod Planning period Period inwhich something is planned. ValidityPeriod Validity period Period inwhich something is valid.

TransportPlanningPeriod can include PositioningPeriod, PickingPeriod,and PackingPeriod. IssuePeriod can include PickingPeriod, PackingPeriod,LoadingPeriod, and YardDeparturePeriod. PickupPeriod can includeLoadingPeriod and YardDeparturePeriod. CarrierHandoverPeriod can includeLoadingPeriod, YardDeparturePeriod, and ShippingPeriod. DeliveryPeriod,ArrivalPeriod, and ReceiptPeriod can include YardArrivalPeriod,UnloadingPeriod, UnpackingPeriod, and PutawayPeriod.

The term DateTime in Object Class Term may be obsolete in GDTs.Therefore, this term comprises Period. This is because the term DateTimeis given by the sub-elements using Property Term. As a result, thesemantic of these GDTs may be unique.

(dddd) DecimalValue

A GDT DecimalValue 11700 is a numeric value represented as a decimal. Anexample of GDT DecimalValue 11700 is: <PropertyValue> <DecimalValue>3.14159</DecimalValue> </PropertyValue>.

The structure of GDT DecimalValue 11700 is depicted in FIG. 117. For theGDT Decimal Value 11700, the Representation/Association Qualifier termis Decimal 11702, the Representation/Association term is Value 11704,the Type term is xsd 11706, and the Type Name term is Decimal 11708.

GDT DecimalValue 11700 is a qualified basic GDT that is based on thesecondary Representation/Association Value of the CCT Numeric. GDTDecimalValue 11700 is used if the reference to the decimalrepresentation of the element based on GDT DecimalValue 11700 is bothmeaningful and desired from a semantic perspective. This is the casewith mathematical/scientific and technical numeric values. The Decimalqualifier then forms part of the relevant element name.

Numeric business values may not be defined using their decimalrepresentation; rather, this representation is derived implicitly fromthe semantics of the numeric value. Examples of this include Price orExchangeRate. In this case, GDT DecimalValue 11700 is not used.

(eeee) DeletedIndicator

A GDT DeletedIndicator 11800 indicates whether an object has beenlogically deleted or not. An example of GDT DeletedIndicator 11800 is:

<DeletedIndicator>false</DeletedIndicator>.

The structure of GDT DeletedIndicator 11800 is depicted in FIG. 118. Forthe GDT Deleted Indicator 11800, the Property is Deleted Indicator11802, the Representation/Association term is Indicator 11804, the Typeterm is CCT 11806, and the Type Name term is Indicator 11808.

The GDT DeletedIndicator 11800 can have the values true or false. Trueindicates that the object has been logically deleted. False indicatesthat the object has not been logically deleted.

In the context of an interface, there may be a description of whichobject the GDT DeletedIndicator 11800 refers to, its business meaning,and whether a set DeletedIndicator can be canceled in a subsequentmessage.

(ffff) DeliveryScheduleTypeCode

The GDT DeliveryScheduleTypeCode 11900 is a coded representation of thetype of a delivery schedule. This type describes the (business)character of a delivery schedule and defines its fundamental properties.An example of GDT DeliveryScheduleTypeCode 11900 is: <DeliverySchedule>  <ID>4711</ID>   <TypeCode>2</TypeCode>   ... </DeliverySchedule>.

The structure of GDT DeliveryScheduleTypeCode 11900 is depicted in FIG.119. For GDT Delivery Schedule Type Code 11900, the Object Class isDelivery Schedule 11902, the Property is Type 11904, theRepresentation/Association term is Code 11906, the Type term is CCT11908, the Type Name term is Code 11910, and the Length is one 11912.

The value ranges of the GDT DeliveryScheduleTypeCode 11900 may consistof a proprietary code list. Possible values are 1 or 2. 1 refers to adelivery schedule for the short-, medium- and/or long-term area on thebasis of daily, weekly and/or monthly time specifications. 2 refers to adelivery schedule for just-in-time deliveries on the basis of timespecifications throughout the day, if necessary, in terms of minutes.

The GDT DeliveryScheduleTypeCode 11900 is used within thescheduling-agreement-based release ordering to communicate the businesscharacter of a delivery schedule to a vendor. It may be used, forexample, in the automotive industry.

(gggg) DeliveryTerms

The GDT DeliveryTerms 12000 summarizes conditions and agreementsformulated at the time of the order that apply for the execution of thedelivery and transport of ordered goods and the associated services andactivities. An example of GDT DeliveryTerms 12000 is:   <DeliveryTerms>   <DeliveryItemGroupID>123</DeliveryItemGroupID>   <DeliveryPriorityCode>1</DeliveryPriorityCode>    <Incoterms>    <ClassificationCode listID=“Incoterms” listVersionID=“2000”listAgencyID=“4”> FOB     </ClassificationCode >    <TransferLocationName langCode=“de”> Hamburg </TransferLocationName>   </Incoterms>    <PartialDelivery>    <MaximalNumber>9</MaximalNumber>    </PartialDelivery>   <QuantityTolerance>     <OverPercent>33.0</OverPercent>    <UnderPercent>1.0</UnderPercent>    </ QuantityTolerance>    <MaximumLeadTimeDuration> P2M5D    </ MaximumLeadTimeDuration>   <Transport>     <ServiceLevelCode listID=“DE 4219”listVersionID=“D.02B” listAgencyID=“6”> 1 </ ServiceLevelCode>    <ModeCode listID=“DE 8067” listVersionID=“D.02B” listAgencyID=“6”> 1</ ModeCode>     <MeansDescriptionCode listID=“DE 8179”listVersionID=“D.02B” listAgencyID=“6”> 4     </MeansDescriptionCode>   <Transport>    <Description langCode=“de”>     This is a Germandescription text.    </Description>   </DeliveryTerms >.

In the above example, ListAgencyID=“4” describes “ICC/WBO”,ListAgencyID=“6” describes “UN/ECE”, listVersionID=“D.02B” describesUN/EDIFACT standard directory Year 2002, Version B, listID=“DE 4219”describes UN/EDIFACT “Transport Service Priority Code”, listID=“DE 8067”describes UN/EDIFACT “Transport Mode Name Code”, listID=“DE 8179”describes UN/EDIFACT “Transport Means Description Code”, andMaximumLeadTimeDuration=P2M5D describes a duration of 2 months 5 days.

The structure of GDT DeliveryTerms 12000 is depicted in FIG. 120. ForGDT Delivery Terms 12000, the Object Class is Delivery Terms 12002 andthe Representation/Association term is Details 12004.

For GDT Delivery Item Group ID 12006, the Category is Element 12008, theObject Class is Delivery Terms 12010, the Property is Order Item GroupIdentification 12012, the Representation/Association term is Identifier12014, the Type term is GDT 12012, the Type Name term is BusinessTransaction Document Item Group ID 12014, and the Cardinality is zero orone 12016.

For GDT Delivery Priority Code 12018, the Category is Element 12020, theObject Class is Delivery Terms 12022, the Property is Delivery PriorityCode 12024, the Representation/Association term is Code 12026, the Typeterm is GDT 12028, the Type Name term is Business Transaction PriorityCode 12030 and the Cardinality is zero or one 12032.

For GDT Incoterms 12034, the Category is Element 12036, the Object Classis Delivery Terms 12038, the Property is Incoterms 12042, theRepresentation/Association term is Incoterms 12042, the Type term is GDT12044, the Type Name term is Incoterms 12046 and the Cardinality is zeroor one 12048.

For GDT Partial Delivery 12050, the Category is Element 12052, theObject Class is Delivery Terms 12054, the Property is Partial Delivery12056, the Representation/Association term is Partial Delivery 12058,the Type term is GDT 12060, the Type Name term is Partial Delivery12062, and the Cardinality is zero or one 12064.

For GDT Quantity Tolerance 12066, the Category is Element 12068, theObject Class is Delivery Terms 12070, the Property is Quantity Tolerance12072, the Representation/Association term is Quantity Tolerance 12074,the Type term is GDT 12076, the Type Name term is Quantity Tolerance12078, and the Cardinality is zero or one 12080.

For GDT Maximum Lead Time Duration 12082, the Category is Element 12084,the Object Class is Delivery Terms 12086, the Property is Maximum LeadTime 12088, the Representation/Association term is Duration 12090, theType term is GDT 12092, the Type Name term is Duration 12094, and theCardinality is zero or one 12096.

For GDT Transport 12098, the Category is Element 12099, the Object Classis Delivery Terms 12001A, the Property is Transport 12002A, theRepresentation/Association term is Details 12003A, and the Cardinalityis zero or one 12004A.

For GDT Service Level Code 12005A, the Category is Element 12006A, theObject Class is Transport 12007A, the Property is Service Level Code12008A, the Representation/Association term is Code 12009A, the Typeterm is GDT 12010A, the Type Name term is Transport Service Level Code12011A, and the Cardinality is zero or one 12012A.

For GDT Mode Code 12013A, the Category is Element 12014A, the ObjectClass is Transport 12015A, the Property is Mode Code 12016A, theRepresentation/Association term is Code 12017A, the Type term is GDT12018A, the Type Name term is Transport Mode Code 12019A, and theCardinality is zero or one 12020A.

For GDT Means Description Code 12021A, the Category is Element 12022A,the Object Class is Transport 12023A, the Property is Means DescriptionCode 12024A, the Representation/Association term is Code 12025A, theType term is GDT 12026A, the Type Name term is Transport MeansDescription Code 12027A, and the Cardinality is zero or one 12028A.

For GDT Description 12029A, the Category is Element 12030A, the ObjectClass is Delivery Terms 12031A, the Property is Description 12032A, theRepresentation/Association term is Description 12033A, the Type term isGDT 12034A, the Type Name term is Description 12035A, and theCardinality is zero or one 12036A.

DeliveryItemGroupID is a unique identifier for a group of items to bedelivered together. DeliveryPriorityCode is a priority/urgency of thedelivery/delivery item according to the requirements of the buyer.Incoterms is a standard contract formula for the terms of delivery.PartialDelivery is the maximum number of partial deliveries that may/canbe carried out to deliver the ordered quantity of an item.QuantityTolerance is the tolerated difference between a requestedquantity and an actual quantity.

MaximumLeadTimeDuration is the maximum lead time from the time of theorder to the receipt of the delivery. This duration can be specified ina contract award or can be agreed upon in a supply contract and definesthe binding basis for calculating the latest possible received deliverydate for a given order date.

Transport: ServiceLevelCode is in terms of delivery of goods,agreed/defined services concerning the speed of the delivery. Transport:ModeCode describes how the delivery is to be made and the transportationmode to be used for the delivery, but may not define a specific route ormeans of transport. Transport: MeansDescriptionCode is the means oftransport category to be used to move goods or persons. Description isthe natural readable text for providing additional information about adelivery/delivery item.

GDT DeliveryTerms 12000 contain detailed information on the agreeddelivery conditions (Incoterms), delivery modalities (accepted number ofpartial deliveries, delivery priority, grouping requests for deliveries,tolerances for quantity deviations) and transport modalities (such asshipping/transport type and means of transport to be used). Moreover,additional information can be specified as freeform text. Specifying anelement of the structure may be optional.

Using the information in GDT DeliveryTerms 12000, the involved businesspartners (buyer and seller) agree on outline conditions for purchaseorders regarding the delivery and transportation of the orderedproducts/goods. They determine and influence the flow of the subsequentlogistical processes.

GDT DeliveryTerms 12000 are used at header and item level. Aspecification at item level overwrites the corresponding specificationat header level.

(hhhh) Description

A GDT Description 12100 is natural-language text. An example of GDTDescription 12100 is: <OrderDescription langCode=“en”>   A characterstring with a specified language. </OrderDescription>.

The structure of GDT Description 12100 is depicted in FIG. 121. For GDTDescription 12100, the Object Class is Description 12102, theRepresentation/Association term is Text 12104, the Type term is CCT12106, the Type Name term is Text 12108. The GDT Description 12100 maybe restricted 12110.

GDT Description 12100 contains an attribute “languageCode” fordetermining the appropriate language of the element content. Thelanguage code is based on RFC 3066. For GDT Language Code 12112, theCategory is A 12114, the Object Class is Description 12116, the Propertyis Language Code 12118, the Representation/Association term is Code12120, the Type term is xsd 12122, the Type Name term is Language 12124,and the Cardinality is one 12126.

GDT Description 12100 may be used for handling information, readableadditional information on the structured information, or descriptions ofservices and products.

The character length of GDT Description 12100 may not defined and wouldtherefore be system-dependent. In a variation, GDT Description 12100 maynot be used for transmitting proprietary control information, coded andmutually agreed on values, detailed descriptions of values that couldotherwise be represented as coded values or identifiers, or numericalvalues.

(iiii) DigitNumberValue

A GDT DigitNumberValue 12200 is the number of digits used to represent areal value or whole number. An example of GDT DigitNumberValue 12200 is:

<DigitNumberValue>7</DigitNumberValue>.

The structure of GDT DigitNumberValue 12200 is depicted in FIG. 122. ForGDT Digit Number Value 12200, the Representation/Association Qualifierterm is Digit Number 12202, the Representation/Association term is Value12204, the Type term is xsd 12206, the Type Name term is non NegativeInteger 12208, and the Length is from one to two 12210.

GDT DigitNumberValue 12200 is a qualified basic GDT based on thesecondary Representation/Association Value of the CCT Numeric and arestriction of xsd: decimal. Non-negative whole numbers less than onehundred may be permitted.

GDT DigitNumberValue 12200 may be used to describe the format forrepresenting decimal values (e.g., total number of digits, number ofdecimal places) or floating point numbers (e.g., mantissa length).

(jjjj) DirectMaterialIndicator

A GDT DirectMaterialIndicator 12300 indicates whether a material is usedas a direct material in the context of a process or not. A directmaterial is a product of the type “material” that is used directly inthe production of products and that affects the value of the finishedproduct in terms of manufacturing costs. An example ofDirectMaterialIndicator is:<DirectMaterialIndicator>true</DirectMaterialIndicator>.

The structure of GDT DirectMaterialIndicator 12300 is depicted in FIG.123. For GDT Direct Material Indicator 12300, the Property is DirectMaterial Indicator 12302, the Representation/Association term isIndicator 12304, the Type term is CCT 12306 and the Type Name term isIndicator 12308.

The GDT DirectMaterialIndicator 12300 can have the values true or false.True indicates that a material is used as a direct material in thecontext of a process. False indicates that a material is not used as adirect material in the context of a process. The GDTDirectMaterialIndicator 12300 is to be used for products of type“material.”

The GDT DirectMaterialIndicator 12300 may be used to indicate whether amaterial or material type listed in a purchase order item is used as adirect material in the context of a process. In a variation, theDirectMaterialIndicator is not an attribute of a material. A materialcan be treated as a direct material in some processes and not in others.

The context to which the DirectMaterialIndicator refers may beidentified from the usage of the GDT.

(kkkk) DunningCounterValue

A GDT DunningCounterValue 12400 is the number of dunning notices sent.An example of GDT DunningCounterValue 12400 is:

<DunningCounterValue>2</DunningCounterValue>.

The structure of GDT DunningCounterValue 12400 is depicted in FIG. 124.For GDT Dunning Counter Value 12400, the Object Class is Dunning 12402,the Property is Counter 12404, the Representation/Association term isValue 12406, the Type term is GDT 12408 and the Type Name term isCounter Value 12410.

In a variation, non-negative, whole number values are permitted for GDTDunningCounterValue 12400.

GDT DunningCounterValue 12400 specifies the number of dunning noticesthat have been sent to one or more business partners in a specifiedperiod with regard to one or more receivables. In a company, forexample, this information is sent from Current Account Accounting toCredit Management.

Several dunning notices can exist for a receivable. These dunningnotices are also grouped by dunning level (DunningLevelValue). However,the dunning level does not have to increase automatically each time adunning notice is sent.

(llll) DunningLevelValue

A GDT DunningLevelValue 12500 is the level of intensity with which aparty is urged to pay existing receivables. An example of GDTDunningLevelValue 12500 is:

<DunningLevelValue>4</DunningLevelValue>.

The structure of GDT DunningLevelValue 12500 is depicted in FIG. 125.For GDT Dunning Level Value 12500, the Object Class is Dunning 12502,the Property is Level 12504, the Representation/Association term isValue 12506, the Type term is CCT 12508, the Type Name term is Numeric12510, and the Length is one 12512.

Non-negative, whole number values from 0 to a maximum value may bepermitted for GDT DunningLevelValue 12500. Also, the maximum value maynot exceed 9. For the dunning level, the following linear order applies:0<1<2< . . . <maximum value.

The GDT DunningLevelValue 12500 conveys the relative intensity of adunning notice based on a linear integer scale between zero and aspecified maximum value.

Dunning is a process for contacting customers to collect unpaid bills.It generally starts at the first level with a payment reminder andprogresses to dunning notices and even threats as payments become moreoverdue. Overall, dunning levels are first regulated and prescribed bycountry-specific laws. Within the scope of the statutory regulations,however, a dunning company can also define several additional dunninglevels that differ in the form of the dunning notice, e.g., a friendlypayment reminder at level 1 and a more abrupt payment reminder at level2.

The GDT DunningLevelValue 12500 may not define a DunningLevelCode thatis then used to define the semantics of individual dunning levels. Sincethese semantics can differ from country to country and company tocompany, a DunningLevelCode can be defined using additional attributessuch as schemeAgencyID. In contrast, the use of the GDTDunningLevelValue 12500 presupposes that the semantic of a conveyeddunning level is either known to the sender and recipient or is notrelevant in the given context.

(mmmm) Duration

A GDT Duration 12600 is a period of time of a particular length withouta fixed start or end time. This period of time is expressed in years,months, days, hours, minutes, seconds, and fractions of a second. Anexample of GDT Duration 12600 is:

<TravelDuration>PT23H12M</TravelDuration>.

The structure of GDT Duration 12600 is depicted in FIG. 126. For GDTDuration 12600, the Property is Duration 12602, theRepresentation/Association term is Date Time 12604, the Type term is xsd12606, and the Type Name term is Duration 12608.

GDT Duration 12600 is based on the “built-in data type” of W3C xsd:duration. This is structured according to the extended representation ofISO 8601. The representation of GDT Duration 12600 is PnYnMnDTnHnMnS,for example, P12Y12M2DT4H12M40S. The representation uses the literals Pfor the duration and may precede every duration value, nY for durationin years, nM for the duration in months, nD for the duration in days, Tfor the time period in hours, minutes, and seconds. nH for the durationin hours, nM for the duration in minutes, nS for the duration inseconds. nS may also be substituted with n.nnnS where the decimal pointprecedes fractions of seconds. Tenths (nS), hundredths (nS), andthousandths (nnnS) of a second can be shown. The number prefix (n) ineach case is the duration in fractions of a second.

Time values that are not required may not be represented. For example,P12Y1M. When hours, minutes, and/or seconds are represented, “T” mayprecede the time values. For example, PT23H12M or P3Y1MT9H.

GDT Duration 12600 describes a time period with a particular length ofan event or process. For instance, working time, duration of stay, orprocessing time. However, it may not be dependent on a fixed point intime.

(nnnn) EmailAddress

A GDT EmailAddress 12700 is the abbreviation for Electronic Mail Addressand represents a digital and unique address in a mailbox system. Anexample of GDT EmailAddress 12700 is: ><EmailAddress>  mailto:gunther.stuhec@sap.com </EmailAddress.

The structure of GDT EmailAddress 12700 is depicted in FIG. 127. The GDTEmailAddress 12700 includes attribute protocolCode 12714. For GDT EmailAddress 12700, the Object Class is Email 12702, the Property is Address12704, the Representation/Association term is Electronic Address 12706,the Type term is CCT 12708, the Type Name term is Electronic Address12710. The GDT Email Address 12700 may be restricted 12712.

For GDT Protocol Code 12714, the Category is Attribute 12716, the ObjectClass is Email 12718, the Property is Protocol 12720, theRepresentation/Association term is Code 12722, the Type term is xsd12724, the Type Name term is Token 12726, the Cardinality is zero or one12728. The GDT Protocol Code 12714 is in default: EM (smtp) 12730.

The element content for GDT EmailAddress 12700 is structured using URLconventions. The syntax is specified in the IETF RFC 2396recommendation. The additional attribute “protocolCode” is notnecessary. The scheme is the uriType “mailto:.” The part following thecolon is the scheme-specific part that represents the respective emailaddress.

If the email address is not based on the SMTP address, another URIscheme according to the IETF RFC 2717 specifications can be applied orthe relevant email address can be indicated by an additional“protocolCode” attribute.

Various codes may be used for protocolCode for specification of anaddress representation of a particular message protocol. For this emailaddress type, the codes from the UN/EDIFACT DE 3155 “CommunicationAddress Code Qualifier” code list may be used. It is not necessary tostate the attribute because “EM” is the default value for the SMTPprotocol. The main codes are AB (SITA), AD (AT&T mailbox), AF (U.S.Defense Switched Network), AN (ODETTE File Transfer Protocol), AO(Uniform Resource Location), EI (EDI transmission), EM (Electronic MailExchange of mail by electronic means), FT (File transfer access methodaccording to ISO), GM (General Electric Information Service), IM(Internal mail), SW (S.W.I.F.T.) and XF (X.400 address).

(oooo) EvaluatedReceiptSettlementIndicator

An GDT EvaluatedReceiptSettlementIndicator 12800 indicates whether theevaluated receipt settlement (ERS) procedure is to be used forsettlement or not. An example of GDT EvaluatedReceiptSettlementIndicator12800 is:

<EvaluatedReceiptSettlementIndicator>false</EvaluatedReceiptSettlementIndicator>.

The structure of GDT EvaluatedReceiptSettlementIndicator 12800 isdepicted in FIG. 128. For GDT Evaluated Receipt Settlement Indicator12800, the Property Qualifier term is Evaluated Receipt 12802, theRepresentation/Association term is Settlement 12804, the Type term isCCT 12806 and the Type Name term is Indicator 12808.

The GDT EvaluatedReceiptSettlementIndicator 12800 can have the valuestrue or false. True indicates that the evaluated receipt settlement(ERS) procedure is to be used for settlement. False indicates theevaluated receipt settlement (ERS) procedure shall not be used forsettlement.

In the ERS procedure, payment is made directly on receipt of the goods,without the need for an invoice.

(pppp) ExchangeRate

GDT ExchangeRate 12900 is the representation of an exchange rate betweentwo currencies. An example of GDT ExchangeRate 12900 is:  <ExchangeRate> <UnitCurrency>EUR</UnitCurrency><QuotedCurrency>USD</QuotedCurrency>  <Rate>1.1234</Rate></ExchangeRate>.

The structure of GDT ExchangeRate 12900 is depicted in FIG. 129. The GDTExchangeRate 12900 includes elements UnitCurrency 12906, QuotedCurrency12922, Rate 12938, and QuotationDateTime 12956. For GDT Exchange Rate12900, the Object Class is Exchange Rate 12902 and theRepresentation/Association term is Details 12904.

For GDT Unit Currency 12906, the Category is Element 12908, the ObjectClass is Exchange Rate 12910, the Property is Unit Currency 12912, theRepresentation/Association term is Code 12914, the Type term is GDT12916, the Type Name term is Currency Code 12918, and the Cardinality isone 12920.

For GDT Quoted Currency 12922, the Category is Element 12924, the ObjectClass is Exchange Rate 12926, the Property is Quoted Currency 12928, theRepresentation/Association term is Code 12930, the Type term is GDT12932, the Type Name term is Currency Code 12934, and the Cardinality isone 12936.

For GDT Rate 12938, the Category is Element 12940, the Object Class isExchange Rate 12942, the Property is Rate 12944, theRepresentation/Association term is Rate 12946, the Type term is xsd12948, the Type Name term is Decimal 12950, the Length is fourteen12952, and the Cardinality is one 12954.

For GDT Quotation Date Time 12956, the Category is Element 12958, theObject Class is Exchange Rate 12960, the Property is Quotation Date Time12962, the Representation/Association term is Date Time 12964, the Typeterm is GDT 12966, the Type Name term is Date Time 12968, and theCardinality is zero or one 12970.

UnitCurrency refers to the “Leading currency.” QuotedCurrency refers tothe “Following currency.” Rate refers to the exchange rate between thesecurrencies. This corresponds to the price at which one unit of thecurrency UnitCurrency can be changed into the currency QuotedCurrency.QuotationDateTime refers to the exchange rate date and time when theexchange rate was defined. Specifying an exchange rate date may beoptional.

One example use of GDT ExchangeRate 12900 is when an incoming invoicewas received with currency Dollar. A different currency is to be usedfor the payment. The GDT ExchangeRate 12900 between invoice and paymentcurrency may be transmitted to the Payment System. Another example iswhen current exchange rates are transmitted to an ERP system daily froma provider such as Reuters.

The exchange rate is calculated using the formula: 1UnitCurrency=Rate*QuotedCurrency.

(qqqq) ExponentialRepresentationTypeCode

The GDT ExponentialRepresentationTypeCode 13000 is a codedrepresentation for how a number is displayed in exponential form in base10. An example of GDT ExponentialRepresentationTypeCode 13000 is:

<ExponentialRepresentationTypeCode>1</ExponentialRepresentationTypeCode>.

The structure of GDT ExponentialRepresentationTypeCode 13000 is depictedin FIG. 130. For GDT Exponential Representation Type Code 13000, theObject Class is Exponential Representation Type 13002, theRepresentation/Association term is Code 13004, the Type term is CCT13006, the Type Name term is Code 13008, the Length is one 13010. TheGDT Exponential Representation Type Code 13000 may be restricted 13012.

An exponential form in base 10 comprises the mantissa, as a real numberwith predecimal and decimal places, and a whole number exponent for base10, where the mantissa and exponent are separated by “E-”. In English,the mantissa is specified with a decimal point and a comma is used forthousands.

GDT ExponentialRepresentationTypeCode 13000 can have the values 1, 2 or3. 1 means exactly one predecimal place in the mantissa. 2 means onefixed predefined exponent. 3 means a maximum of three predecimal placesin the mantissa. If the template is exceeded when code 3 is used, theexponent is increased by 3.

The GDT ExponentialRepresentationTypeCode 13000 regulates the format ofan exponential number (e.g., on a monitor or printout) but does notaffect the technical representation when data is transferred or stored.The format is not a function of the user, but of the purpose andconsequently of the instance of the data type.

The GDT ExponentialRepresentationTypeCode 13000 corresponds to thecoding for the exponential representation type in R/3 classification. Inthe case of code 2, the GDT PropertyDataType may also contain anadditional attribute, which contains the value of the exponent.

(rrrr) FixedIndicator

A GDT FixedIndicator 13100 indicates whether a value/object is fixed ornot. ‘Fixed’ means that the value/object is limited in its use, forexample, it may not be changed. An example of GDT FixedIndicator 13100is: <FixedIndicator>true</FixedIndicator>.

The structure of GDT FixedIndicator 13100 is depicted in FIG. 131. ForGDT Fixed Indicator 13100, the Property is Fixed 13102, theRepresentation/Association term is Indicator 13104, the Type term is CCT13106 and the Type Name is Indicator 13108.

GDT FixedIndicator 13100 can have the values true or false. Trueindicates a value/object is fixed. False indicates a value/object is notfixed. The business meaning of the fixing may be specified in thecontext of the interface.

(ssss) FloatValue

A GDT FloatValue 13200 is a numeric value represented as a floatingpoint number. An example of GDT FloatValue 13200 is: <PropertyValue>  <FloatValue>6.02214E+23</FloatValue> </PropertyValue>.

The structure of GDT FloatValue 13200 is depicted in FIG. 132. For GDTFloat Value 13200, the Representation/Association Qualifier term isFloat 13202, the Representation/Association term is Value 13204, theType term is xsd 13206, the Type Name term is Float 13208.

GDT FloatValue 13200 is a qualified basic GDT based on the secondaryRepresentation/Association Value of the CCT Numeric. GDT FloatValue13200 is used if the explicit reference to the floating pointrepresentation of the element based on GDT FloatValue 13200 is bothmeaningful and desired from a semantic perspective. This is the casewith mathematical and technical numeric values. The Float qualifier thenbecomes part of the element name.

Numeric business values are not generally defined using their floatingpoint representation. Instead, this representation derives implicitlyfrom the semantics of the numeric value. An example of this is Measure.FloatValue is not used if this is the case.

(tttt) FollowUpBusinessTransactionDocumentRequirementCode

The GDT FollowUpBusinessTransactionDocumentRequirementCode 13300 is acoded representation of the need for a follow-up document. An example ofGDT FollowUpBusinessTransactionDocumentRequirementCode 13300 is:

<FollowUpInvoiceRequirementCode>01</FollowUpInvoiceRequirementCode>.

The structure of GDT FollowUpBusinessTransactionDocumentRequirementCode13300 is depicted in FIG. 133. For GDT FollowUp Business TransactionDocument Requirement Code 13300, the Object Class Qualification term isFollow Up 13302, the Object Class is Business Transaction Document13304, the Property is Requirement 13306, the Representation/Associationterm is Code 13308, the Type term is CCT 13310, the Type Name term isCode 13312, and the Length is 2 13314. The GDT FollowUp BusinessTransaction Document Requirement Code 13300 Enumeration=“01 02 03 04 05”13316.

The GDT FollowUpBusinessTransactionDocumentRequirementCode 13300 canhave the values 01 through 05. 01 means the follow-up document isrequired in the subsequent process. 02 means the follow-up document isexpected in the subsequent process, but optional. 03 means the follow-updocument may be optional. 04 means the follow-up document is notexpected, but can be received and processed. 04 means the follow-updocument is forbidden, therefore it cannot be received or processed.

The GDT FollowUpDocumentRequirementCode 13300 is used to control theexchange of documents within a business process at runtime. It may referfrom the context in which it is used to a follow-up document. When theGDT is used in a document, “BusinessTransactionDocument” is replaced bythe respective follow-up document, for example, Invoice. A defaultprocedure may be specified every time a GDTFollowUpBusinessTransactionRequirementCode 13300 is used.

For example in an order process, the buyer uses a GDTFollowUpDocumentRequirementCode 13300 in the purchase order to specifythat an order confirmation is “unexpected.” This means that the buyerdoes not expect a confirmation as part of the business transaction butis able to receive and file a confirmation.

The GDT FollowUpBusinessTransactionDocumentRequirementCode 13300 may bea proprietary code list with fixed predefined values. Changes to thepermitted values involve changes to the interface.

In addition to the GDTFollowUpBusinessTransactionDocumentRequirementCode 13300, which refersto follow-up documents, there is also a GDTFollowUpMessageRequirementCode, which refers to follow-up messages. Whenused in a message, a check may be performed to determine which of theseGDTs may be used.

(uuuu) FollowUpMessageRequirementCode

The GDT FollowUpMessageRequirementCode 13400 is a coded representationof the necessity of a follow-up message. An example of GDTFollowUpMessageRequirementCode 13400 is:

<FollowUpInvoiceRequestRequirementCode>01</FollowUpInvoiceRequestRequirementCode>.

The structure of GDT FollowUpMessageRequirementCode is 13400 depicted inFIG. 134. For GDT FollowUp Message Requirement Code 13400, the ObjectClass Qualification term is Follow Up 13402, the Object Class is Message13404, the Property is Requirement 13406, the Representation/Associationterm is Code 13408, the Type term is CCT 13410, the Type Name term isCode 13412, and the Length is 2 13414. The GDT FollowUp MessageRequirement Code 13400 may be restricted 13416.

GDT FollowUpMessageRequirementCode 13400 can have the values 01 through05. 01 means the follow-up message is necessary in the subsequentprocess. 02 means the follow-up message is expected in the subsequentprocess, but is optional. 03 means the follow-up message may beoptional. 04 means the follow-up message is not expected, but can bereceived and processed. 05 means the follow-up message is forbidden,therefore it cannot be received or processed.

The GDT FollowUpMessageRequirementCode 13400 is used to control theexchange of messages within a business process at runtime. It may alwaysrefer from the context in which it is used to a follow-up message. Whenthe GDT is used in a document, “Message” is replaced by the respectivefollow-up message, for example, InvoiceRequest. The follow-up messagenames that are permitted are listed in the GDT: MessageTypeCode.

A default procedure may be specified every time a GDTFollowUpMessageRequirementCode 13400 is used. For example, in an orderprocess, the buyer uses a GDT FollowUpMessageRequirementCode 13400 inthe purchase order to specify that an order confirmation is“unexpected.” This means that the buyer does not expect an confirmationas part of the business transaction but is able to receive and file aconfirmation.

The GDT FollowUpMessageRequirementCode 13400 may be a proprietary codelist with fixed predefined values. Changes to the permitted valuesinvolve changes to the interface.

In addition to the GDT FollowUpMessageRequirementCode 13400, whichrefers to follow-up messages, there is also a GDTFollowUpBusinessTransactionDocumentRequirementCode, which refers tofollow-up documents. When used in a message, a check may be performed todetermine which of these GDTs may be used.

(vvvv) GeoCoordinates

GDT GeoCoordinates 13500 contain the geographic data, in other wordslongitude and latitude specified as per the WGS84 reference system,which enables one to determine a position on the globe. An example ofGDT GeoCoordinates 13500 is:   <GeoCoordinates>    <LatitudeMeasureunitCode=“DD”>40.23232300000    </LatitudeMeasure>    <LongitudeMeasureunitCode=“DD”>123.12121200000</LongitudeMeasure>   </GeoCoordinates>.

In the above example, the unitCode “DD” corresponds to the unit degreeof an angle.

The structure of GDT GeoCoordinates 13500 is depicted in FIG. 135. TheGDT GeoCoordinates 13500 includes elements LatitudeMeasure and LongitudeMeasure. For GDT GeoCoordinates 13500, the Object Class isGeoCoordinates 13502, the Representation/Association term is Details13504.

LatitudeMeasure refers to the geographic latitude in degrees. Thedegrees unit of measurement is specified by the attribute “unitCode.”For GDT Latitude Measure 13506, the Category is E 13508, the ObjectClass is GeoCoordinates 13510, the Property is Latitude 13512, theRepresentation/Association term is Measure 13514, the Type term is GDT13516, the Type Name term is Measure 13518, the Cardinality is one13520.

LongitudeMeasure refers to the Geographic longitude in degrees. Thedegrees unit of measurement is specified by the attribute “unitCode.”For GDT Longitude Measure 13522, the Category is E 13524, the ObjectClass is GeoCoordinates 13526, the Property is Longitude 13528, theRepresentation/Association term is Measure 13530, the Type term is GDT13532, the Type Name term is Measure 13534, the Cardinality is one13536.

In general, southern latitudes are negative and northern latitudes arepositive. Western longitudes are negative and eastern longitudes arepositive. It is also not necessary to use the positive sign (+) forpositive values. Negative values may have a negative sign (−) for aprefix.

The specification of longitude and latitude corresponds to sphericalcoordinates. The definition range for LatitudeMeasure is −90 to +90. Thedefinition range for LongitudeMeasure is −180 to +180. Specificationsoutside the definition range, for example, +190 for longitude or −100for latitude, may result in an error.

GDT GeoCoordinates 13500 may be used in the field of transport planning.The geodata are determined from the address data of a customer tocalculate the time required for transport, the distance to be covered,and the speed of the means of transport used.

Another usage is may be to locate suitable garages in the case of anaccident or breakdown in a specific area. The garages are geo-codedusing their addresses and are available for such an enquiry.

(wwww) HandlingUnit

A HandlingUnit 13600 is a physical unit of packaging materials (loadcarrier, additional packaging materials) and the packaged products (type“Material”). An example of HandlingUnit 13600 is:

Example 1: Handling Unit with a load of 10 boxes of a product<HandlingUnit> <ID>4711</ID> <LoadCarrier> <Product> <StandardIDschemeAgencyID=“DUNS”>123456789</StandardID> </Product> </LoadCarrier><Load> <BusinessTransactionDocumentReference> <ItemID>LF800001</ItemID></BusinessTransactionDocumentReference> <QuantityunitCode=“CT”>10</Quantity> </Load> </HandlingUnit>.

<HandlingUnit> <ID>4712</ID> <LoadCarrier> <Product>...</Product></LoadCarrier> <LowerLevelHandlingUnit> <ID>4711</ID></LowerLevelHandlingUnit> </HandlingUnit>.

The structure of HandlingUnit 13600 is depicted in FIG. 136. ForHandling Unit 13600, the Object Class is Handling Unit 13602, theRepresentation/Association term is Details 13604.

ID identifies the handling unit. For ID 13606, the Object Class isHandling Unit 13608, the Property is Identification 13610, theRepresentation/Association term is Identifier 13612, the Type term isGDT 13614, the Type Name term is Identifier 13616, the Length is fromone to twenty 13618, and the Cardinality is one 13620.

LoadCarrier refers to the device with which physical objects can bestored or transported. Examples of load carriers include crates,nestings, containers, mesh box pallets, and pallets. For Load Carrier13622 the Object Class is Handling Unit 13624, and the Cardinality isone 13626.

LoadCarrierProduct refers to the product ID of the load carrier. ForProduct 13626, the Object Class is Load Carrier 13628, the Property isProduct 13630, the Type term is GDT, the Type Name term is BusinessTransaction Document Production 13632, and the Cardinality is one 13634.The Product 13626 maybe restricted 13636.

HeightMeasure refers to the height of the handling unit. For HeightMeasure 13638, the Object Class is Handling Unit 13640, the PropertyQualifier term is Height 13642, the Property is Measure 13644, theRepresentation/Association term is Measure 13646, the Type term is GDT13648, the Type Name term is Measure 13650, the Length is maximum 19predecimal and 6 decimal digits 13652, and the Cardinality is zero orone 13654.

LengthMeasure refers to the length of the handling unit. For LengthMeasure 13656, the Object Class is Handling Unit 13658, the PropertyQualifier term is Length 13660, the Property is Measure 13662, theRepresentation/Association term is Measure 13664, the Type term is GDT13666, the Type Name term is Measure 13668, the Length is maximum 19predecimal and 6 decimal digits 13670, and the Cardinality is zero orone 13672.

WidthMeasure refers to the width of the handling unit. For Width Measure13674, the Object Class is Handling Unit 13676, the Property Qualifierterm is Width 13678, the Property is Measure 13680, theRepresentation/Association term is Measure 13682, the Type term is GDT13684, the Type Name term is Measure 13686, the Length is maximum 19predecimal and 6 decimal digits 13688, and the Cardinality is zero orone 13690.

HandlingUnit refers to the total volume of the load carrier for a closedload carrier (wire basket) or total of packaging material and thecontents for open packaging materials (pallets). For HandlingUnit 13692,the Object Class is Handling Unit 13694, the Property Qualifier term isLength 13696, the Property is Measure 13698, theRepresentation/Association term is Measure 13699, the Type term is GDT13601, the Type Name term is Measure 13602A, the Length is maximum 19predecimal and 6 decimal digits 13603A, and the Cardinality is zero orone 13604A.

GrossWeightMeasure refers to the total weight of packaging material andcomplete contents. For Gross Weight Measure 13605A, the Object Class isHandling Unit 13606A, the Property Qualifier term is Weight 13607A, theProperty is Measure 13608A, the Representation/Association term isMeasure 13609A, the Type term is GDT 13610A, the Type Name term isMeasure 13611A, the Length is maximum 19 predecimal and 6 decimal digits13612A, and the Cardinality is zero or one 13613A.

AdditionalPackaging refers to additional packaging materials. Togetherwith the load carrier used, these are intended for fulfilling therequirements of the materials to be packed in terms of fixing, securing,and filling. With the load carrier, they constitute the packaging of ahandling unit (examples: lid, intermediate layers, frames, shrink-wrap,padding material). For Additional Packaging 13614A, the Object Class isHandling Unit 13615A, and the Cardinality is from zero to n 13616A.

AdditionalPackaging Product refers to the product ID of a packagingmaterial/additional packaging material. For Product 13616A, the ObjectClass is Additional Packaging 13617A, the Property is Product 13618A,the Type term is GDT 13619A, the Type Name term is Business TransactionDocument Product 13620A, and the Cardinality is one 13621A. The Product13616A may be restricted 13622A.

For Quantity 13623A, the Object Class is Additional Packaging 13624A,the Property is Quantity 13625A, the Property/Association term isQuantity 13626A, the Type term is GDT 13627A, the Type Name term isQuantity 13628A, the Length is maximum 19 predecimal and 6 decimaldigits 13629A, and the Cardinality is one 13630A.

AdditionalPackaging Quantity refers to the quantity of a packagingmaterial/additional packaging material used in the specified handlingunit.

A handling unit can consist of an empty load carrier. It is thereforebeneficial to specify the HandlingUnitID and the load carrier, whereaspacked products (loads), lower-level handling units, packagingmaterials, and additional packaging materials are optional.LowerLevelHandlingUnit refers to a lower-level handling unit fordisplaying a hierarchy of handling units. For Lower Level Handling Unit13631A, the Object Class is Handling Unit 13632A, and the Cardinality isfrom zero to n 13633A.

For ID 13634A, the Object Class is Lower Level Handling Unit 13635A, theProperty is Identification 13636A, the Representation/Association termis Identifier 13637A, the Type term is GDT 13638A, the Type Name term isHandling Unit ID 13639A, the Length is from one to twenty 13640A, andthe Cardinality is one 13641A.

Load refers to the load (quantity of a product) packed in the specifiedhandling unit without lower-level handling units. The load in a handlingunit is characterized by referencing the item in a business documentthat contains information about the type and quantity of a product. ForLoad 13642A, the Object Class is Handling Unit 13643A, the Property isLoad 13644A, and the Cardinality is from zero to n 13645A.

LoadBusinessTransactionDocumentReference is a reference to the item in abusiness document that contains more specific details to the load packedin the handling unit. For Business Transaction Document Reference13645A, the Object Class is Load 13646A, the Property is BusinessTransaction Document 13647A, the Type term is GDT 13648A, the Type Nameterm is Business Transaction Document Reference 13649A, the Cardinalityis one 13650A.

For ID 13651A, the Object Class is Business Transaction Document 13652A,the Property is Identification 13653A, the Representation/Associationterm is Identifier 13654A, the Type term is GDT 13655A, the Type Nameterm is Business Transaction Document ID 13656A, the Length is from oneto thirty-five 13657A, and the Cardinality is zero or one 13658A.

For Item ID 13659A, the Object Class is Business Transaction DocumentItem 13660A, the Property is Identification 13661A, theRepresentation/Association term is Identifier 13662A, the Type term isGDT 13663A, the Type Name term is Business Transaction Document Item ID13664A, the Length is from one to ten 13665A, and the Cardinality is one13666A.

AdditionalPackaging Quantity refers to the quantity of a packagingmaterial/additional packaging material used in the specified handlingunit.

LoadQuantity refers to the quantity of the load packed in the specifiedhandling unit without lower-level handling units. For Quantity 13666A,the Object Class is Load 13667A, the Property is Quantity 13668A, theRepresentation/Association term is Quantity 13669A, the Type term is GDT13670A, the Type Name term is Quantity 13671A, the Length is frommaximum 19 predecimal and 6 decimal digits 13672A, and the Cardinalityis one 13673A.

In a variation, the product quantity in the referenced item is not lessthan the LoadQuantity specified in the HandlingUnit 13600. If thebusiness document referenced in the handling unit directly concerns thedocument in which the handling unit is used, the identification of thebusiness document (but not of the item) can be left out.

HandlingUnit 13600 maps the packaging/packaging hierarchy of products.The HandlingUnit 13600 simplifies logistics processes: It enables theproduction- or sales-controlled combination of various products/sameproducts with inconsistent packaging sizes in physical storage units ordelivery units; and, using the link to batch numbers and serial numbers,it enables an improved logistical check, which may be necessary foreffective processing.

The structure of the GDTs HandlingUnit 13600 is compatible with the“packaging” in the DELVRY03 IDoc. A handling unit has a unique scannableidentification number that can be used to call up data for the handlingunit.

(xxxx) Incoterms

GDT Incoterms 13700 are commercial contract formulae for the deliveryconditions that correspond to the rules compiled by the InternationalChamber of Commerce (ICC). An example of Incoterms is: <Incoterms>  <ClassificationCode>FOB</ClassificationCode>  <TransferLocationName>Hamburg</TransferLocationName> </Incoterms>.

The structure of GDT Incoterms 13700 is depicted in FIG. 137. The GDTIncoterms 13700 includes elements ClassificationCode andTransferLocationName. For GDT Incoterms 13700, the Object Class isIncoterms 13702 and the Representation/Association term is Details13704.

ClassificationCode refers to the coded representation of theinternationally used abbreviation for characterizing deliveryconditions. ClassificationCode is a three-character field and can acceptthe values EXW (Ex Works), FCA (Free Cargo), FAS (Free Alongside Ship),FOB (Free on Board), CFR (Cost & Freight), CIF (Cost, Insurance &Freight to named destination), CPT (Freight, Carriage paid todestination), CIP (Freight, Carriage, Insurance to destination), DAF(Delivery at frontier—Named place), DES (Delivered Ex Ship—Named port ofdestination), DEQ (Delivered Ex Quay—Duty paid, Named port), DDU(Delivered duty unpaid to destination), DDU (Delivered duty unpaid todestination). For Classification Code 13706, the Category is E 13708,the Object Class is Incoterms 13710, the Property is Classification13712, the Representation/Association term is Code 13714, the Type termis CCT 13716, the Type Name term is Code 13718, the Length is three13720, and the Cardinality is one 13722. The Classification Code 13706may be restricted 13724.

TransferLocationName refers to a place (place, port of shipment, port ofdestination, place of destination) to which the above code refers. Forexample, it may refer to the port of shipment in the case of FOB. ForTransfer Location Name 13726, the Category is Element 13728, the ObjectClass is Incoterms 13730, the Property is Transfer Location Name 13732,the Representation/Association term is Name 13734, the Type term is GDT13736, the Type Name term is Name 13738, the Length is from one totwenty-eight 13740, and the Cardinality is zero or one 13742. TheTransfer Location Name 13726 may be restricted 13744.

GDT Incoterms 13700 are used in the transmission of an order toestablish the delivery conditions agreed upon by the business partners.

(yyyy) InformationOutdatedIndicator

A GDT InformationOutdatedIndicator 13800 indicates whether informationis outdated or not. An example of GDT InformationOutdatedIndicator 13800is:

<InformationOutdatedIndicator>false</InformationOutdatedIndicator>.

The structure of GDT InformationOutdatedIndicator 13800 is depicted inFIG. 138. For GDT Information Outdated Indicator 13800, the Object Classis Information 13802, the Property is OutdatedIndicator 13804, theRepresentation/Association term is Indicator 13806, the Type term is CCT13808, and the Type Name term is Indicator 13810.

The GDT InformationOutdatedIndicator 13800 can have the values true orfalse. True indicates that information contained in the message isoutdated. False indicates that information contained in the message isnot outdated.

One example is the purchase order information message, which alsocontains confirmed quantities and deadlines. TheInformationOutdatedIndicator indicates whether the confirmed quantitiesand deadlines relate to the current PO information or whether the PO hasbeen changed since the last confirmation was received.

It may be clear from the context of the interface which information isoutdated. This can be done by extending the name (e.g.,ConfirmationInformationOutdatedIndicator).

(zzzz) IntegerValue

An GDT IntegerValue 13900 is an integer. An integer can be regarded as anumerical decimal value without decimal places. An example of GDTIntegerValue 13900 is: <PropertyValue>  <IntegerValue>42</IntegerValue></PropertyValue>.

The structure of GDT IntegerValue 13900 is depicted in FIG. 139. For GDTIntegerValue 13900, the Representation/Association Qualifier term isInteger 13902, the Representation/Association term is Value 13904, theType term is xsd 13906, and the Type Name term is Integer 13908.

GDT IntegerValue 13900 is a qualified basic GDT based on the secondaryRepresentation/Association Value of the CCT Numeric. IntegerValue isused when the explicit reference to the integer representation of theelement based on IntegerValue is both meaningful and desired from asemantic perspective. This is the case with rounded or estimated values.The Integer qualifier then becomes part of the relevant element name.

Generally, numeric business values are not defined using their integerrepresentation. Instead, this representation is derived implicitly fromthe semantics of the numeric value. Examples of this includeOrdinalNumberValue or DunningCounterValue. In this case, GDTIntegerValue 13900 is not used.

(aaaaa) InterfaceElementID

An GDT InterfaceElementID 14000 is a unique identifier for an element inan interface. An example of GDT InterfaceElementID 14000 is:

<InterfaceElementID schemeID=‘Open Catalog Interface’

schemeAgencyID=‘123456789’ schemeAgencySchemeID=‘DUNS’

schemeAgencySchemeAgencyID=‘016’>NEW_ITEM-DESCRIPTION</InterfaceElementID>.

The structure of GDT InterfaceElementID 14000 is depicted in FIG. 140.For GDT InterfaceElementID 14000, the Object Class is Interface Element14002, the Representation/Association term is Identifier 14004, the Typeterm is CCT 14006, the Type Name term is Identifier 14008, and theLength is from one to forty 14010. The GDT Interface Element ID 14000may be restricted 14012.

For Scheme ID 14014, the Category term is Attribute 14016, the ObjectClass is Identification Scheme 14018, the Representation/Associationterm is Identifier 14020, the Type term is xsd 14022, the Type Name termis Token 14024, the Length is from one to sixty 14026, and theCardinality is zero or one 14028.

For Scheme Agency ID 14030, the Category term is Attribute 14032, theObject Class is Identification Scheme Agency 14034, theRepresentation/Association term is Identifier 14036, the Type term isxsd 14038, the Type Name term is Token 14040, the Length is from one tosixty 14042, and the Cardinality is zero or one 14044.

For Scheme Agency Scheme ID 14046, the Category term is Attribute 14048,the Object Class is Identification Scheme Agency 14050, the Property isScheme 14052, the Representation/Association term is Identifier 14054,the Type term is xsd 14056, the Type Name term is Token 14058, theLength is from one to sixty 14060, and the Cardinality is zero or one14062.

For Scheme Agency Scheme Agency ID 14064, the Category term is Attribute14066, the Object Class is Identification Scheme Agency 14068, theProperty is Scheme Agency 14070, the Representation/Association term isIdentifier 14072, the Type term is xsd 14074, the Type Name term isToken 14076, the Length is three 14078, and the Cardinality is zero orone 14080.

The permitted values depend on the corresponding interface and may betaken from its documentation. The attribute schemeID identifies theinterface, schemeAgencyID identifies the issuer of the interface, whichmay be unique in the context of the attributes schemeAgencySchemeID andschemeAgencySchemeAgencyID. For more information about the use of theattributes schemeID, schemeAgencyID, schemeAgencySchemeID, andschemeAgencySchemeAgencyID, see the discussion for the CCT Identifier.

In a variation, the GDT InterfaceElementID 14000 may not be used torefer to elements of XML interfaces. If necessary, there may be anexamination of how an element of an XML interface is identified and howthe attributes are to be used in this case. GDT InterfaceElementID 14000is used to assign references to interface elements of variouse-procurement systems to characteristics within a catalog. For example,the “Open Catalog Interface” can be used to link Web-based purchasingcatalogs to an e-procurement system. A user calls up a catalog from thee-procurement system, searches for products in this catalog, and makes aselection. When this is transmitted to the virtual shopping cart of thee-procurement system (user purchase order), characteristics of theproduct are transmitted to the e-procurement using the above-mentionedinterface. The GDT InterfaceElementID 14000 contains the interfaceelement identification of the calling e-procurement system for eachcharacteristic and enables the characteristics to be assigned correctlyto the elements of the e-procurement interface.

(bbbbb) IntervalBoundaryTypeCode

An GDT IntervalBoundaryTypeCode 14100 is a coded representation of aninterval boundary type. An example of GDT IntervalBoundaryTypeCode 14100is:

<IntervalBoundaryTypeCode>3</IntervalBoundaryTypeCode>.

The structure of GDT IntervalBoundaryTypeCode 14100 is depicted in FIG.141. For the GDT Interval Boundary Type Code 14100, the Property isInterval Boundary Type 14102, the Representation/Association is Code14104, the Type is CCT 14106, the Type Name is Code 14108, and theLength is one 14110. The GDT IntervalBoundaryTypeCode 14100 may be arestricted GDT.

An element of type GDT IntervalBoundaryTypeCode 14100 can have thevalues 1 through 9. 1 corresponds to a single value X. 2 corresponds toan interval with a closed lower interval boundary and an open upperinterval boundary; [X,Y). 3 corresponds to an interval with a closedupper and lower interval boundary; [X,Y]. 4 corresponds to an intervalwith an open upper and lower interval boundary; (X,Y). 5 corresponds toan interval with an open lower interval boundary and a closed upperinterval boundary; (X,Y]. 6 corresponds to an interval with an unlimitedlower boundary and an open upper boundary; <X. 7 corresponds to aninterval with an unlimited lower boundary and a closed upper boundary;<=x. 8 corresponds to an interval with an open lower boundary and anunlimited upper boundary; >X. 9 corresponds to an interval with a closedlower boundary and an unlimited upper boundary; >=X.

The values that are expressed by the interval relationship may belong tothe same ordinal scale. The meaning of scale values established by theGDT IntervalBoundaryTypeCode 14100 is used to describe intervals bytheir boundaries. One use relates to property values and propertyvaluations.

The GDT IntervalBoundaryTypeCode 14100 may be a proprietary code listwith fixed predefined values. Changes to the permitted values mayinvolve changes to the interface.

(ccccc) InventoryUsabilityStatusCode

The GDT InventoryUsabilityStatusCode 14200 is the encoded representationof the usability of a warehouse inventory for company-specific businessprocesses. An example of GDT InventoryUsabilityStatusCode 14200 is:

<InventoryUsabilityStatusCode>1</InventoryUsabilityStatusCode>.

The structure of GDT InventoryUsabilityStatusCode 14200 is depicted inFIG. 142. For the GDT Inventory Usability Status Code 14200, the ObjectClass is Inventory 14202, the Property is Usability Status 14204, theRepresentation/Association Code is 14206, the Type CCT is 14208, theType Name is Code 14210, and the Length is from one to two 14212. TheGDT InventoryUsabilityStatusCode 14200 may be a restricted GDT.

The value range of the GDT InventoryUsabilityStatusCode 14200 maycomprise a proprietary code list. Possible values are 1 through 6. 1means the stock can be used as necessary for business processes. 2 meansthe stock is blocked for business processes. 3 means the usage of stockis subject to certain restrictions. 4 means theInventoryUsabilityStatusCode of the stock is not defined more precisely,i.e., no other status is specified. 4 means the stock is in qualityinspection. 6 means the stock is a goods return. Depending on the codedvalue, certain business processes can be allowed for a warehouse stock,however, others may not be allowed.

The usage can be clarified using a concrete business process as anexample: At a goods receipt for a purchase order, the GDTInventoryUsabilityStatusCode 14200 “quality inspection” is assigned tothe stock delivered since Quality Control may inspect the quality of thereceived stock. Depending on this inspection, parts of the stock arethen posted to the GDT InventoryUsabilityStatusCode 14200 “unrestricteduse” or “blocked.” The GDT InventoryUsabilityStatusCode 14200 is usedfor transmitting stock changes from Inventory Management to Accountingand to Logistics Planning. Different InventoryUsabilityStatusCodes cancause a different stock valuation in Accounting and are handleddifferently in planning.

A warehouse inventory is a quantity of material at a certain location.For example, 17 pieces of material “42” at storage location “17-05-72”.

(ddddd) InvoiceCancellationInvoiceIndicator

An GDT InvoiceCancellationInvoiceIndicator 14300 indicates whether aninvoice is a cancellation invoice or not. An example of GDTInvoiceCancellationInvoiceIndicator 14300 is:<InvoiceCancellationInvoiceIndicator>true</InvoiceCancellationInvoiceIndicator>.

The structure of GDT InvoiceCancellationInvoiceIndicator 14300 isdepicted in FIG. 143. For the GDT Invoice Cancellation Invoice Indicator14300, the Object Class Invoice is 14302, the Property is CancellationInvoice Indicator 14304, the Representation/Association is Indicator14306, the Type is CCT 14308, and the Type Name is Indicator 14310.

The GDT InvoiceCancellationInvoiceIndicator 14300 can have the valuestrue or false. True indicates that the invoice is a cancellationinvoice. False indicates that the invoice is not a cancellation invoice.

A cancellation invoice is a newly created invoice that renders apreviously generated invoice or parts of it invalid. This is done bymarking the new invoice with the GDT InvoiceCancellationInvoiceIndicator14300 (value ‘true’). Marking an invoice using the GDTInvoiceCancellationInvoiceIndicator 14300 is specific to invoices. If aninvoice contains errors, is incorrect, or has been created for servicesthat have not been provided, it may not be canceled itself. Thecorrection may be made via an additional, appropriately marked invoice.A cancellation invoice may not be equated with a credit memo, even iffrom an accounting point of view the original invoiced amount can becredited using the invoice marked as a cancellation invoice.

For example, the distinction is made in R/3 using the sales documenttype. In particular, the distinction between ‘cancellation invoice’ and‘cancellation credit memo’ needs to be observed here.

(eeeee) InvoiceIntraCorporateIndicator

A GDT InvoiceIntraCorporateIndicator 14400 indicates whether or not aninvoice is between independent companies in a corporate group. Anexample of GDT InvoiceIntraCorporateIndicator 14400 is:<InvoiceIntraCorporateIndicator>true</InvoiceIntraCorporateIndicator>.

The structure of GDT InvoiceIntraCorporateIndicator 14400 is depicted inFIG. 144. For the GDT Invoice Corporate Indicator 14400, the ObjectClass is Invoice 14402, the Property is Intra Corporate Indicator 14404,the Representation/Association is Indicator 14406, the Type is CCT14408, the Type Name is Indicator 14410. The Indicator may have thevalues true or false. True indicates the invoice is between twocompanies within a corporate group. False indicates the invoice is to acompany that does not belong to the corporate group or is an invoice toan end customer.

The creation of invoices between companies in a corporate group issometimes also referred to as “Intercompany Billing.” For example, acustomer places an order with company C1, which also sends the invoiceto the customer. Delivery of goods, however, is performed by company C2of the same group. C1 gathers all revenue, while C2 incurs the costs.This makes a settlement between the two companies necessary, which mayrequire an invoice in the case of legally independent companies.

Therefore, two invoices may be created for one business transaction (inthe example of the customer order), whose differing semantics are madeexplicit by the indicator. Distinction between the two is necessary,since different prices are applied in invoicing and the invoice to thecustomer affects the status of the order item.

If more than two companies in one corporate group are involved in abusiness transaction, further invoices can result—this is known as ChainInvoicing. However, differentiation of invoices between these companiesmay not be required in that case.

In an example, the distinction is made in R/3 using the sales documenttype.

(fffff) LanguageCode

The GDT LanguageCode 14500 is a coded representation for the language.An example of GDT LanguageCode 14500 is:

<OrderLanguageCode>de</OrderLanguageCode>.

The structure of GDT LanguageCode 14500 is depicted in FIG. 145. The GDTLanguage Code 14500, the Object Class is Language 14502, the Property isIdentification 14504, the Representation is Code 14506, the Type is xsd14508, the Type Name is language 14510, the Length is from two to nine14512.

GDT LanguageCode 14500 is from the Core Component Type “Code.” GDTLanguageCode 14500 is based on the W3C “built-in” data type xsd:language. The language code of GDT LanguageCode 14500 is representedaccording to IETF RFC 3066. RFC 3066 includes two parts: a primarylanguage code and a series of sub-codes. The primary language code canbe an ISO 639-1-compliant (ISO 639:1988) two-character code or an ISO639-2-compliant (ISO 639:1998) three-character code. If the languagecode is to occur in both standards, the two-character language code (ISO639-1) may be used. The sub-codes can be used for differentiating thelanguage according to special criteria or for different dialects withina single country. If the ISO 639-1 or 639-2-compliant codes are notsufficient, the ISO 3166-1-compliant two-character code is usually usedas the first sub-code. Regional differences in a language within asingle country can be defined by using the second ISO 3116-2-complianttwo-character sub-code “Country Subdivision Code.”

A GDT LanguageCode 14500 is represented as aa, anm, aa-CC, aaa-CC,aa-CC-RR, aaa-CC-RR. The literal aa/aaa stands for ISO 639-1 or ISO639-2-compliant language code, CC stands for ISO 3166-1-compliantcountry code, and RR stands for ISO 3166-2-compliant “CountrySubdivision Code”.

GDTLanguageCode 14500 is used to identify the language for businessdocuments or business partners. Furthermore, it enables a businesspartner to request a particular language. There is also a differencebetween inbound and outbound in the implementation of “LanguageCode.”Outbound, mapping from, for example, the SAP language key to the ISO639-1-compliant two-character ISO language code always occurs withoutlanguage differentiation. Inbound, most SAP applications work internallywith the SAP language key. These applications support the ISO639-1-compliant two-character language code without a sub-code. Otherlanguage codes may be mapped to ISO 639-1 for these applications;otherwise an error may occur during inbound processing.

(ggggg) LanguageDependencyIndicator

A GDT LanguageDependencyIndicator 14600 indicates whether or not thereis a language dependency. An example of GDT LanguageDependencyIndicator14600 is:

<LanguageDependencyIndicator>true</LanguageDependencyIndicator>.

The structure of GDT LanguageDependencyIndicator 14600 is depicted inFIG. 146. The GDT Language Dependency Indicator 14600, the Property isLanguage Dependency 14602, the Representation/Association is Indicator14604, and the Type is CCT: Indicator 14606.

The GDT LanguageDependencyIndicator 14600 can have the values true(or 1) or false (or 0). True indicates language dependency. Falseindicates no language dependency.

The GDTLanguageDependencyIndicator 14600 is used in GDT PropertyDataTypeto indicate that values in character strings are language dependent.

(hhhhh) LegalEventTypeCode

The GDT LegalEventTypeCode 14700 is the coded representation of a legaltransaction or an official or legal event. An example of GDTLegalEventTypeCode 14700 is:   <LegalEvent>  <TypeCode>01</TypeCode></LegalEvent>.

The structure of GDT LegalEventTypeCode 14700 is depicted in FIG. 147.The GDT Legal Event Type Code 14700, the Object Class is Legal Event14702, the Property is Type 14704, Representation/Association is Code14706, the Type is CCT 14708, the Type Name is Code 14710, the Length istwo 14712.

Values permitted for GDT LegalEventTypeCode 14700 are 01-20 and ZZ. 01stands for foreclosure, 02 stands for Law suit, 03 stands forOutstanding Judgment, 04 stands for Tax Lien, 05 stands for SupportDebt, 06 stands for Bankruptcy, 07 stands for Garnishment, 08 stands forRepossession, 09 stands for Collection, 10 stands for Divorce Decree, 11stands for Custody Agreement, 12 stands for Financing Statement (SecuredLoan), 13 stands for Lien, 14 stands for Non-responsibility, 15 standsfor Financial Counseling, 16 stands for Fictitious Name, 17 stands forNotice of Default, 18 stands for Forcible Detainer, 19 stands forUnlawful Detainer, 20 stands for an other Public Record or ObligationType, and ZZ stands for a mutually defined code.

(iiiii) LocationID

A GDT LocationID 14800 is a unique identifier for a location. A locationis a logical or a physical place. An example of GDT LocationID 14800 is:<LocationID schemeID=“myLocations”     schemeAgencyID=“065055766”     schemeAgencySchemeID=“DUNS”      schemeAgencySchemeAgencyID=“016”>  LOC_4711 </LocationID>.

In the above example, 065055766 is the DUNS number for Bosch, and 016 isthe DUN & Bradstreet Corporation from code list UN/EDIFACT DE 3055.

The structure of GDT LocationID 14800 is depicted in FIG. 148. For GDTID 14800, the Object Class is Location 14802, the Property isIndemnification 14804, the Representation/Association is Identifier14806, the Type is CCT 14808, the Type Name is Identifier 14810, and theLength is twenty 14812. The GDT LocationID 14800 may be a restrictedGDT.

For the scheme ID 14816, the Category is Attribute 14818, the ObjectClass is Identification Scheme 14820, the Property is Identification14822, the Representation/Association is Identifier 14824, the Type isxsd 14826, the Type Name is Token 14828, and the Length is from zero tosixty 14830. The Cardinality is zero or one 14852.

For the scheme Agency ID 14834, the Category is Attribute 14836, theObject Class is Identification Scheme Agency 14838, the Property isIdentification 14840, the Representation/Association is Identifier14842, the Type is xsd 14844, the Type Name is Token 14846, and theLength is from zero to sixty 14850. The Cardinality is zero or one14852.

For the Scheme Agency-Scheme ID 14854, the Category is Attribute 14856,the Object Class is Identification Scheme Agency 14858, the Property isScheme 14860, the Representation/Association is Identifier 14862, theType is xsd 14864, the Type Name is Token 14866, and the Length is thee14868. The Cardinality is zero or one 14870.

For the Scheme Agency-Scheme Agency ID 14872, the Category is Attribute14874, the Object Class is Identification Scheme Agency 14876, theProperty is Scheme Agency 14878, the Representation/Association isIdentifier 14880, the Type is xsd 14882, the Type Name is Token 14884,the Length is three 14886. The Cardinality is zero or one 14888.

For standardized and proprietary GDT LocationID 14800, there is the CDT:LocationStandardID and CDT: LocationPartyID.

(jjjj) LocationInternalID

A CDT LocationInternalID 14900 is a proprietary identifier for alocation. A location is a logical or a physical place. An example of CDTLocationInternalID 14900 is:

GUID of a location:   <LocationInternalID schemeID=“LocationGUID”schemeAgencyID= “MPL_002”>1C743CEC501F6A4D8826C7EC5A8554B9</LocationInternalID>.

In the above example, schemeID=“LocationGUID” indicates that the scheme“LocationGUID” was used to identify the location, andschemeAgencyID=“MPL_(—)002” indicates that the scheme was assigned bythe business system “MPL_(—)002.”

The following is another example of LocationInternalID:

ID of a location:   <LocationInternalID schemeID=“LocationID”schemeAgencyID=“MPL_002”>CU0000000001</LocationInternalID>.

The structure of CDT LocationInternalID 14900 is depicted in FIG. 149.For GDT Location Internal ID 14902, the Object Class is Location 14904,the Property is Internal 14906, the Representation/Association isIdentifier 13308, the Type is GDT 14910, the Type Name is Location ID14912, and the Length is from one to thirty-two 14914. The CDTLocationInternalID 14900 may be a restricted CDT.

For the scheme ID 14918, the Category is Attribute 14320, the ObjectClass is Identification Scheme 14920, the Property is Identification14922, the Representation/Association is Identifier 14924, the Type isxsd 14926, the Type Name is Token 14928, the Length is from one to sixty14930. The Cardinality is zero or one 14932.

For the scheme Agency ID 14934, the Category is Attribute A 14936, theObject Class is Identification Scheme Agency 14936, the Property isIdentification 14938, the Representation/Association is Identifier14940, the Type is xsd 14942, the Type Name is Token 14944, the Lengthis from one to sixty 14946. The Cardinality is zero or one 14948.

LocationGUID and Location ID are both schemes provided for schemeID.LocationGUID identifies a location using a Global Unique Identifier, andLocationID identifies a location using an identifier. SchemeAgencyIDidentifies a business system in which the identifier was assigned.

The CDT LocationInternalID represents a projection of the GDTLocationID, in which the attributes “schemeID” and “schemeAgencyID” arecontained for describing an internally assigned ID. If an attribute isnot explicitly assigned in the use of the CDT, it may be clearlyspecified through the context.

The CDT LocationInternalID 14900 is used when both sender and recipientcan access shared master data.

(kkkkk) LocationPartyID

A CDT LocationPartyID 15000 is an identifier for a location assigned bya party. A location is a logical or a physical place. An example of CDTLocationPartyID 15000 is:

<LocationBuyerID>4711</LocationBuyerID>.

The structure of CDT LocationPartyID 15000 is depicted in FIG. 150. Forthe CDT Location Party ID 15000, the Object Class is location 15002, theProperty Quality is Party 15004, the Property is Identification 15006,the Representation/Association is Identifier 15008, the Type is GDT15010, the Type Name is Location ID 15012, the Length is from one totwenty 15014. The CDT LocationPartyID 15000 may be a restricted CDT.

The PartyPartyID is the proprietary identifier assigned by a party. Theparty that assigned this identifier may derive from the context of themessage that the LocationPartyID uses.

The CDT LocationPartyID 15000 represents a projection of the GDTLocationID, which may not contain attributes. In the XML instance,“Party” is replaced with “Partner Role Type” (e.g., LocationBuyerID, andthe like). In contrast to LocationStandardID, the use of the CDTLocationPartyID 15000 is role-dependent (e.g., as an ID assigned by theBuyer). SchemeID and VersionID may be included as attributes todifferentiate between several schemes.

(lllll) LocationStandardID

A CDT LocationStandardID 15100 is a standardized identifier for alocation, whereby the identification scheme used is controlled by anagency from the code list DE 3055. A location is a logical or a physicalplace. An example of CDT LocationStandardID 15100 is:<LocationStandardID   schemeAgencyID =“009”> 4012345678910</LocationStandardID>.

In the above example, 009 stands for EAN.UCC (International ArticleNumbering association) from the code list UN/EDIFACT DE 3055.

The structure of CDT LocationStandardID 15100 is depicted in FIG. 151.The CDT Location Standard ID 15100 includes attribute schemeAgencyID.For the CDT LocationStandardID 15100, the Object Class is Location15102, Property Quality is Standard 15104, the Property isIdentification 15106, the Representation/Association is Identifier15108, the Type is GDT 15110, the Type Name is Location ID 15112, andthe Length is thirteen 15114. The CDT LocationStandardID 15100 may be arestricted CDT.

For the Scheme Agency ID 15118, the Category is Attribute 15120, theObject Class is Identification Scheme Agency 15122, the Property isIdentification 15124, the Representation/Association is Identifier15126, the Type is xsd 15128, the Type Name is Token 15130, and theLength is three 15132. The Cardinality is one 15134. The schemeAgencyID15118 identifies the agency that manages an identification scheme. Theagencies from DE 3055 may be used as the default, but the roles definedin DE 3055 may not be used. In a variation, the supported codes are 009(EAN.UCC) for the 13-character Global Location Number (GLN), and 116(ANSI ASC X12) for the 13-character DUNS+4, an enhancement to DUNS (DataUniversal Numbering System from Dun & Bradstreet) for locationidentification.

The CDT LocationStandardID 15100 represents a projection of the GDTLocationID, in which the attribute schemeAgencyID is contained. Thisindicates the standardization organization that assigned the ID.

In a variation, the attribute schemeAgencyID is a mandatory attribute.SchemeID and VersionID may be included as attributes to differentiatebetween several schemes.

(mmmmm) LogItem

A GDT LogItem 15200 is a log message that is generated when anapplication is executed. An example of GDT LogItem 15200 is:   <LogItem>  <TypeID>001(/CCM/)</TypeID>   <SeverityCode>3</SeverityCode>  <Note>Catalog CAMERAS could not be published</Note>  <WebAddress>pgwdf0123.sap.corp:12345/sap/ccm/messagedetail&language=EN&i d=001(/CCM/)&param1=CAMERAS</WebAddress> </LogItem>.

The structure of GDT LogItem 15200 is depicted in FIG. 152. The GDTLogItem 15200 includes elements TypeID, SeverityCode, Note, andWebAddress. For the GDT LogItem 15200, the Representation/Association isDetails 15202. The GDT LogItemTypeID 15200 may not be confused withsequential numbering for the messages in a log. The GDT LogItemTypeID15200 does not require the attributes to be listed for the CCTIdentifier, since these are taken from the context.

TypeID is a unique identification of the type of a log entry (within theapplication that generates the log). For example, when a catalog ispublished, a log can be generated containing several items concerningthe successful publication of a catalog item. Since these log entriesmay be similar, they all have the same TypeID, although the respectivecatalog items are inserted dynamically in a text pattern thatcorresponds to the message type. For the Type ID 15204, the Category isElement 15206, the Object Class is Log Item 15208, the Property is TypeIdentification 15210, the Representation/Association is Identifier15212, the Type is CCT 15214, the Type Name is Identifier 15216, and theLength is from one to forty 15218. The Cardinality is zero or one 15220.The GDT LogItem 15200 may be a restricted 15222.

Severity Code is the severity of the log message. For the Severity Code,the Category is Element 15226, the Object Class is Log Item 15228, theProperty is Severity 15230, the Representation/Association is Code15232, the Type is GDT 15234, the Type Name is Log Item Severity Code15236, and the Cardinality is zero or one 15238.

Note is a short text for the log message. The GDT LogItemNote 15200restricts the length permitted in the GDT Note. For the Note 15240, theCategory is Element 15242, the Object Class is Log Item 15244, theProperty is Note 15246, the Representation/Association is Note 15248,the Type is GDT 15250, the Type Name is 15252, the Length is from one totwo-hundred 15254. The Cardinality is one 15256. The Remarks may berestricted 15258.

WebAddress is the address for a document available on the Internet thatcontains more information about the log entry. For the Web Address, theCategory is Element 15262, the Object Class is Log Item 15264, theProperty is Web Address 15266, the Representation/Association is WebAddress 15268, the Type is CCT 15270, the Type Name is Web Address15272, and the Cardinality is zero or one 15274.

The URI schemas, for example “http” and “https,” are permitted.

The use of the elements TypeID and WebAddress (with or without aspecified language) may be optional depending on the business context.It may not be useful to use the SeverityCode for all types of log. TheGDT LogItem 15200 can therefore be extended in the future by specifyingan attack level, for instance, in the area of Internet-security, or foruser interaction in the area of e-learning.

In ABAP applications, the element TypeID corresponds to the combinationof message class (also known as application area) and message number.These are listed consecutively in accordance with the pattern for theLogItemTypeID: <message number>(/<message class>/).

(nnnnn) LogItemSeverityCode

The GDT LogItemSeverityCode 15300 is the coded representation of theseverity in a log message on the execution of an application. An exampleof GDT LogItemSeverityCode 15300 is: <SeverityCode>2</SeverityCode>.

The structure of GDT LogItemSeverityCode 15300 is depicted in FIG. 153.The GDT Log Item Severity Code 15300, the Object Class is Log Item15302, the Property is Severity 15304, the Representation/AssociationCode is 15306, the Type is CCT 15308, the Type Name is Code 15310, andthe Length is one 15312.

The GDT LogItemSeverityCode 15300 can have the values 1 through 4. 1refers to a notification of the execution of an application or anapplication step if no errors or error possibilities have occurred. 2refers to a warning of the possibility of an error or an error source inthe execution of an application or an application step. 3 refers to anotification of the occurrence of an error during the execution of anapplication or an application step—for, example with a more precisedescription of the type of error. 4 refers to a notification of apremature or unforeseen termination of the execution of an application.

The values of the ServiceProcessingLogItemSeverityCode follow theUN/EDIFACT code list 0331 “Report function,” with regard to naming andadditional values. This code list also focuses on the dialog with asystem.

The following linear order applies for the severity: 1<2<3<4. During theexecution of an application, log messages may be created that areclassified by the severity of the GDT LogItemSeverityCode 15300 (e.g.,as an error message).

The ServiceProcessingLogItemSeverityCode may be a proprietary code listwith fixed predefined values. Changes to the permitted values involvechanges to the interface.

(ooooo) Measure

A GDT Measure 15400 is a physical measurement with the correspondingunit of measurement. An example of GDT Measure 15400 is:<NetWeightMeasure unitCode=“KGM”>420.5</NetWeightMeasure>, where KGMmeans kilogram.

The structure of GDT Measure 15400 is depicted in FIG. 154. The GDTMeasure 15400 includes attribute unitCode 15410. For the GDT Measure15400, the Representation/Association is Measure 15402, the Type is xsd15404, the Type Name is decimal 15406, and the Length is maximumthirteen predecimal units and six decimal units 15408.

For the unitCode 15410, the Category is Attribute 15412, the ObjectClass is Measure 15414, the Property is Unit 15416, theRepresentation/Association is Code 15418, the Type is xsd 15420, theType Name is token 15422, and the Length is from one to three 15424. TheCardinality is one 15426.

GDT Measure 15400 is the result of the measurement of a physical size inrelation to a standard size, which may be the standard against whicheverything else is measured. Positive and negative entries are possibleby using the built-in data type “xsd: decimal.” Negative entries may beprefixed with a negative sign (“−”). Positive entries do not have to beprefixed with a positive sign (“+”).

GDT Measure 15400 can be used to specify physical business sizes.Examples of such measurements are the height, width, length, weight, andvolume of a handling unit, or the latitude or longitude of a geographiclocation.

(ppppp) MeasureUnitCode

The GDT MeasureUnitCode 15500 is the coded representation of anon-monetary unit of measurement. A unit of measurement is, for example,a quantity that is either defined by a standard or established byconventions as a particular type of unit. This unit quantity may be thestandard of comparison for determining and specifying other quantitiesof the same type. An example of GDT MeasureUnitCode 15500 is:

<MeasureUnitCode>BX</MeasureUnitCode>, where BX stands for box.

The structure of GDT MeasureUnitCode 15500 is depicted in FIG. 155. TheGDT Measure Unit Code 15500, the Object Class is Measure Unit 15502, theRepresentation/Association is Code 15504, the Type is xsd 15506, theType Name is token 15508, and the Length is from one to three 15510.

The permitted values for GDT MeasureUnitCode 15500 are the “CommonCodes” specified in UN/CEFACT Recommendation #20. The Common Code is asequence of a maximum of three alphanumerical characters. Therecommendation is divided into three levels. Each unit belongs to alevel. Levels 1 and 2 contain physical units: level 1 contains SI unitsand level 2 contains SI-equivalent units. Level 3 contains other“informative” units of measurement that are not assigned to level 1 or2.

In particular, UN/CEFACT Recommendation #20 contains codes for physicalunits (Physical Measure Units) such as meters, kilograms, or seconds andunits that derive from them such as cubic meters, hours, and Newtons, aswell as country-specific and industry-specific physical units.

A distinction may be made between Common Code and the representationsymbol of a unit. A standardized representation symbol may be available.

(qqqqq) MeasureUnitMeaningCode

The GDT MeasureUnitMeaningCode 15600 is a coded representation of themeaning of a physical unit of measurement. An example of GDTMeasureUnitMeaningCode 15600 is:

<MeasureUnitMeaningCode>E17</MeasureUnitMeaningCode>.

The structure of GDT MeasureUnitMeaningCode 15600 is depicted in FIG.156. The GDT Measure Unit Meaning Code 15600, the Object Class isMeasure Unit 15602, the Property is Meaning 15604, theRepresentation/Association is Code 15606, the Type is CCT 15608, theType Name is Code 15610, and the Length is three 15612. The GDTMeasureUnitMeaningCode 15600 may be restricted.

The possible values may be taken from the IEC61360 standard. Forexample, the unit kA/m can be derived in different ways and describesdifferent properties, such as longitudinal currents, magnetic fieldstrength, or magnetization.

(rrrrr) MessageTypeCode

The GDT MessageTypeCode 15700 is a coded representation of the(business) type of a message. A message type describes the nature of(business) messages of the same kind. An example of GDT MessageTypeCode15700 is:

<MessageTypeCode>0101</MessageTypeCode>.

The structure of GDT MessageTypeCode 15700 is depicted in FIG. 157. Forthe GDT Message Type Code 15700, the Object Class is Message 15702, theProperty is Type Code 15704, the Representation/Association is Code15706, the Type is CCT 15708, the Type Name is Code 15710, and theLength is four 15712. The GDT MessageTypeCode 15700 may be a restrictedGDT.

The permitted values for the GDT MessageTypeCode 15700 are described inthe table below. Code Name Description 0060 PurchaseContractLegal- ADocumentRequest PurchaseContractLegalDocumentRequest is a request fromPurchase Contract Management to Document Builder to create from purchasecontract data a contract text conforming to legal standards. 0061PurchaseContractLegal- A DocumentNotificationPurchaseContractLegalDocumentNotification is a notification fromDocument Builder to Purchase Contract Management about a legal contract.0062 PurchaseContractUse- A PurchaseContractUseRequest is a Requestrequest from Purchase Contract Management to Purchasing to use thetransmitted purchase contract or to take into account transmittedchanges of the purchase contract. 0063 PurchaseContractUse- APurchaseContractUseConfirmation Confirmation is a confirmation fromPurchasing to Purchase Contract Management about the use or change,respectively, of a transmitted purchase contract. 0064PurchaseContractRelease- A NotificationPurchaseContractReleaseNotification is a notification from Purchasing toPurchase Contract Management about a purchase contract release. 0077SourceOfSupplyNotification A SourceOfSupplyNotification is a notice toSupply Chain Planning about available sources of supply. 0080CatalogueUpdateNotification A CatalogueUpdateNotification is a noticefrom a catalogue provider to an interested party about a new cataloguetransmitted in the message or about changes to an existing cataloguetransmitted in the message. 0081 CataloguePublication ACataloguePublicationRequest is a Request request from catalogueauthoring to the Catalogue Search Engine (the publishing system) topublish a new or changed catalogue or to delete an already publishedcatalogue (the catalogue is possibly split into several transmissionpackages) 0082 CataloguePublication A TransmissionCataloguePublicationTransmissionPackage PackageNotification otificationis the notification of the Catalogue Search Engine (the publishingsystem) to Catalogue Authoring about a package of a cataloguepublication transmission and information about the reception of thispackage and the validity of its content. 0083 CataloguePublication- ACataloguePublicationConfirmation Confirmation is the confirmation of theCatalogue Search Engine (the publishing system) to the CatalogueAuthoring whether the publication or deletion of a Catalogue requestedby a CataloguePublicationRequest was successful or not. 0084CataloguePublication- A TransmissionCancelation-CataloguePublicationTransmissionCancellation Request equest is therequest of Catalogue Authoring to Catalogue Search Engine (thepublishing system) to cancel the transmission of a Catalogue and torestore an earlier published state (if such exists) of the Catalogue.Moreover, no more packages are sent for this transmission. 0085CataloguePublication- A TransmissionCancelation-CataloguePublicationTransmissionCancellation Confirmation onfirmation isthe confirmation of Catalogue Search Engine (the publishing system)whether the transmission of a Catalogue has been cancelled successfullyand an earlier published state of this catalogue (if such exists) hasbeen restored or not. 0086 CataloguePublication- A TransmissionItemLock-CataloguePublicationTransmissionItem Request Lock equest is the requestof Catalogue Authoring to lock single items of the catalogue containedin the catalogue publication transmission. 0087 CataloguePublication- ATransmissionItemLock- CataloguePublicationTransmissionItem ConfirmationLock onfirmation is the confirmation of Catalogue Search Engine (thepublishing system) to Catalogue Authoring whether single items of thecatalogue contained in the catalogue publication transmission could belocked or not. To lock means: If the catalogue is not yet published theitems must not be published. If the catalogue is already published, thepublication of these items must be revoked. 0101 PurchaseOrderRequest APurchaseOrderRequest is a request from a purchaser to a seller todeliver goods or provide services. 0102 PurchaseOrderChange- APurchaseOrderChangeRequest is a Request change to a purchaser's requestto the seller to deliver goods or provide services. 0103PurchaseOrderCancellation- A PurchaseOrderCancellationRequest Request isthe cancellation of a purchaser's request to the seller to deliver goodsor provide services. 0104 PurchaseOrderConfirmation APurchaseOrderConfirmation is a confirmation, partial confirmation, orchange from a seller to the purchaser, regarding the requested deliveryof goods or provision of services. 0120 PurchaseOrderInformation APurchaseOrderInformation is information from a purchasing system forinterested recipients about the current state of a purchase order whenmaking, changing, confirming, or cancelling a purchase order. 0121PurchaseOrderPlanning- A Notification PurchaseOrderPlanningNotificationis a message by means of which planning applications are notified aboutthose aspects of a purchase order that are relevant for planning. 0130PurchaseRequirement A PurchaseRequirementRequest is a Request requestfrom a requestor to a purchaser to (externally) procure products(materials, services) (external procurement). 0131 PurchaseRequirement-A PurchaseRequirementConfirmation Confirmation is a notice from thepurchaser to the requestor about the degree of fulfillment of arequirement. 0140 ProductDemandInfluencing- A EventNotificationProductDemandInfluencingEventNotification is a notification about anevent that influences the supply or demand of products. 0141ProductForecastNotification A ProductForecastNotification is anotification about future product supply or demand (forecasts). 0142ProductForecastRevision- A NotificationProductForecastRevisionNotification is a notification about the revisionof future product supply or demand (forecasts). 0145ProductActivityNotification A ProductActivityNotification is a noticefrom a buyer to a vendor about product-related activities. Based onthis, the vendor can perform supply planning for the buyer. 0151RFQRequest An RFQRequest is the request from a purchaser to a bidder toparticipate in a request for quotation for a product. 0152RFQChangeRequest An RFQChangeRequest is a change to the purchaser'srequest to a bidder to participate in the request for quotation for aproduct. 0153 RFQCancellationRequest An RFQCancellationRequest is acancellation by the purchaser of a request for quotation for a product.0154 RFQResultNotification An RFQResultNotification is a notification bya purchaser to a bidder about the type and extent of the acceptance of aquote or about the rejection of the quote. 0155 Quote Notification AQuoteNotification is the quote of a bidder communicated to a purchaserconcerning the request for quotation for a product by the purchaser.0160 SalesOrderFulfillment- A SalesOrderFulfillmentRequest is Request arequest (or change and cancellation of such a request) from a sellingcomponent to a procuring component, to fulfill the logisticalrequirements (available-to-promise check, scheduling, requirementsplanning, procurement, delivery, . . . ) of a sales order. 0161SalesOrderFulfillment- A Confirmation SalesOrderFulfillmentConfirmationis a confirmation, partial confirmation, or change from the procuringcomponent to the selling component, regarding a sales order with respectto which procurement has been requested. 0185 OrderIDAssignment- AnOrderIDAssignmentNotification Notification is a notice from a buyer to avendor that contains order IDs to be used by the latter for identifying“purchase orders generated by the vendor”. 0200 DeliveryExecutionRequestA DeliveryExecutionRequest is a request to a warehouse or supply chainexecution to prepare and execute the outbound delivery of goods or theacceptance of an expected or announced inbound delivery. 0201DeliveryInformation A DeliveryInformation is a notice about thecreation, change, and execution status of a delivery. 0202DespatchedDelivery- A DespatchedDeliveryNotification Notification is anotification communicated to a product recipient about the plannedarrival, pickup, or issue date of a ready-to-send delivery, includingdetails about the content of the delivery. 0203ReceivedDeliveryNotification A ReceivedDeliveryNotification is anotification communicated to a vendor about the arrival of the deliverysent by him to the product recipient, including details about thecontent of the delivery. 0206 ReturnDeliveryInstruction- A NotificationReturnDeliveryInstructionNotification is a notice to a vendor whichcontains instructions for the return delivery to be executed by him.0210 DeliveryScheduleNotification A DeliveryScheduleNotification is thenotification to a vendor about the quantity of a product to be deliveredwith a certain liability at a certain date in accordance with a givenscheduling aggreement between buyer and vendor. 0213VendorGeneratedOrder- A VendorGeneratedOrderNotification Notification isa notification to a customer/buyer about a replenishment order initiatedand planned by a vendor/seller so that the former can create acorresponding purchase order. 0214 VendorGeneratedOrder-VendorGeneratedOrderConfirmation Confirmation is the confirmation from acustomer/buyer that a purchase order has been created for thereplenishment order initiated and planned by his vendor/seller. 0216Replenishment A ReplenishmentOrderNotification Order Notification is anotification from Logistics Planning (SCP, vendor) to LogisticsExecution (SCE, vendor) about a replenishment order planned for acustomer/buyer in order to trigger further processing for the order andprepare the outbound delivery. 0217 ReplenishmentOrder AReplenishmentOrderConfirmation Confirmation is a confirmation fromLogistics Execution (SCE, vendor) to Logistics Planning (SCP, vendor)that a replenishment order that is planned for a customer/buyer can befulfilled. 0235 CustomsVendorDeclaration- A CompleteRequestCustomsVendorDeclarationCompleteRequest is the request a buyer makes toa vendor to complete a long- term vendor declaration for customspurposes. 0236 CustomsVendorDeclaration- A NotificationCustomsVendorDeclarationNotification is a notification from a vendor toinform a buyer of a long-term vendor declaration for customs purposes. Avendor declaration refers to goods that are delivered from the vendor tothe buyer. 0240 ServiceAcknowledgement- A ServiceAcknawledgementRequestis Request a request by a seller to a purchaser to confirm the servicesrecorded. 0241 ServiceAcknowledgement- A ConfirmationServiceAcknowledgementConfirmation is a confirmation (or rejection) ofthe services recorded. 0250 InventoryChangeNotification AnInventoryChangeNotification is a notice with detailed information aboutinventory changes in inventory management, which is used, e.g., bylogistics planning. 0251 InventoryChangeAccounting An NotificationInventoryChangeAccountingNotification is a notice with aggregatedinformation about inventory changes in inventory management, which istailored to financials. 0252 InventoryChangeAccounting An CancellationInventoryChangeAccountingCancellation Request Request is a request forthe full cancellation of posting information previously sent tofinancials with respect to a goods movement. 0290 BillingDueNotificationA BillingDueNotification is a notification about billing- relevant datacommunicated to an application in which the subsequent operativeprocessing of billing takes place. 0291 InvoicingDueNotification AnInvoicingDueNotification is a notification about invoicing- relevantdata communicated to an application in which the operative verificationand creation of invoices takes place, and/or in which “self billing”invoices (evaluated receipt settlement) are created. 0401 InvoiceRequestAn InvoiceRequest is a legally binding notice about accounts receivableor accounts payable for delivered goods or provided services - typicallya request that payment be made for these goods or services. 0402InvoiceConfirmation An InvoiceConfirmation is the respose of a recipientof an invoice to the bill-from-party by which the invoice as a whole isconfirmed, rejected, or classified as ‘not yet decided’. 0409SupplierInvoiceInformation A SupplierInvoiceInformation is aninformation from Invoicing about an accepted supplier invoice or itscancelation. 0410 InvoiceIssuedInformation An InvoiceIssuedInformationcontains information on the following: Which items of an invoice havebeen billed Which rendered services, delivered products, or credit ordebit memo request items have been billed The extent to which the aboveitems have been billed. 0411 InvoiceAccounting- AnInvoiceAccountingNotification Notification is a notification tailored tofinancials about incoming or outgoing invoices. 0412 InvoiceAccounting-An CancellationRequest InvoiceAccountingCancellationRequest is a requestfor the full cancellation of posting information previously sent tofinancials, regarding an incoming or outgoing invoice or credit memo.0420 TaxDueNotification A TaxDueNotification is a notice from taxdetermination and calculation to the tax register of a company aboutdata relevant for tax reports and tax payments. 0421VATDeclarationRequest A VATDeclarationRequest is a request to a taxauthority to handle a tax return for tax on sales/purchases. 0422VATDeclarationConfirmation A VATDeclarationConfirmation is aconfirmation about the receipt, completeness, formal correctness and, ifnecessary, consistency of a tax return for tax on sales/purchases. 0426SupplierInvoiceCancellation- A ExecutionRequestSupplierInvoiceCancellationExecution Request is request to execute thecancellation of a supplier invoice. 0427 SupplierInvoiceSettlement- AReleaseRequest SupplierInvoiceSettlementReleaseRequest is the request torelease an accepted supplier invoice for settlement. 0430PaymentDueNotification A PaymentDueNotification is a notification aboutdue payments (accounts receivable and accounts payable). 0450CreditAgencyReport A CreditAgencyReportQuery is an Query inquiry to acredit agency concerning the credit report for a business partner. 0451CreditAgencyReport- A CreditAgencyReportResponse is a Response responsefrom a credit agency concerning the inquiry about the credit report fora business partner. 0452 CreditWorthinessQuery A CreditWorthinessQueryis an inquiry to credit management concerning the credit worthiness of abusiness partner. 0453 CreditWorthinessResponse ACreditWorthinessResponse is a response from credit management concerningthe inquiry about the credit worthiness of a business partner. 0454CreditWorthinessChange- A Information CreditWorthinessChangeInformationis information about changes of the credit worthiness of a businesspartner. 0455 CreditCommitmentQuery A CreditCommitmentQuery is aninquiry from credit management concerning existing payment obligationsof a business partner. 0456 CreditCommitmentResponse ACreditCommitmentResponse is a response concerning an inquiry from creditmanagement about existing payment obligations of a business partner.0457 CreditCommitmentRecord- A NotificationCreditCommitmentRecordNotification is a notice to credit managementabout existing payment obligations of business partners. 0458CreditWorthinessCritical- A PartiesQueryCreditWorthinessCriticalPartiesQuery is an inquiry to credit managementabout business partners, for which the credit worthiness has been ratedas critical. 0459 CreditWorthinessCritical- A PartiesResponseCreditWorthinessCriticalpartiesResponse is a response from creditmanagement concerning an inquiry about business partners, for which thecredit worthiness has been rated as critical. 0460CreditPaymentBehaviour- A CreditPaymentRecordNotificationSummaryNotification is a notification to credit management about thepayment behavior (payments made, open items, dunning notices) of abusiness partner. 0601 PersonnelTimeSheet- APersonnelTimeSheetInformation is Information a notice to personnel timemanagement.about personnel times and personnel time events recorded byan upstream personnel time recording system.

Message types may be collected in this code list.

(sssss) Name

A GDT Name 15800 is a word or word combination used to name or identifyan object. An example of GDT Name 15800 is: <ProductName>NW FeezerSJ-450</ProductName>.

The structure of GDT Name 15800 is depicted in FIG. 158. For the GDTName 15800, the Object Class is 15802, the Representation/Association isText 15804, the Type is CCT 15806, and the Type Name is Text 15808.

For the Language Code 15810, the Category is Attribute 15812, the ObjectClass is Name 15814, the Property is Language Code 15816, theRepresentation/Association Code 15818, the Type is xsd 15820, the TypeName is Language 15822, the Length is from two to five 15824, and theCardinality is zero or one 15826. GDT Name 15800 is from the CoreComponent Type “Text.”

The GDT Name 15800 can be language-specific. If the name islanguage-specific, the attribute “languageCode” can be used to determinethe relevant language of the name according to RFC 3066.

GDT Name 15800 may be used for the object label that is typically usedin a natural language context. This may be the name of a person,location, service or product, for example.

The GDT Name 15800 can be language-specific. For example, an object canhave a different name in different languages. In this case, the languagemay be specified using the “languageCode” attribute.

(ttttt) Note

A GDT Note 15900 is a brief communication, the language of which is notexplicitly specified. An example of GDT Note 15900 is:<DocumentNote>Order 04.04.2002</DocumentNote>.

The structure of GDT Note 15900 is depicted in FIG. 159. For the GDTNote 15900, the Property is Note 15902, the Representation/Associationis Text 15904, the Type is CCT 15906, and the Type Name is Text 15908.The GDT Note 15900 may be a restricted GDT. GDT Note 15900 is from theCore Component Type “Text”:

GDT Note 15900 may be used to title or briefly describe a complexobject. In a variation, GDT Note 15900 may not be used as a placeholderwhen there is no other appropriate global type for an individualelement. GDT Note 15900 may not have its own language. Either thelanguage is known from the context or GDT Note 15900 islanguage-independent.

(uuuuu) ObjectStructureRelationshipTypeCode

The GDT ObjectStructureRelationshipTypeCode 16000 is a codedrepresentation of the type of a business relationship between objects ofthe same object type, and is used to create structures (hierarchies ornetworks) on these objects. An example of GDTObjectStructureRelationshipTypeCode 16000 is:

<ObjectStructureRelationshipTypeCode>001</ObjectStructureRelationshipTypeCode>.

The structure of GDT ObjectStructureRelationshipTypeCode 16000 isdepicted in FIG. 160. The GDT Object Structure Relationship Type Code16000, the Object Class is Object Structure Relationship 16002, theProperty is Type Code 16004, the Representation/Association is Code16006, the Type is CCT 16008, the Type Name is Code 16010, and theLength is three 16012. The GDT ObjectStructureRelationshipTypeCode 16000may be a restricted GDT.

ObjectStructureHierarchyRelationshipTypeCode can have the values 001through 006. 001 means the relationship is a bill of materialsrelationship. 002 means the relationship is a grouping relationship. Theobject involved in this relationship is part of a logical grouping tothe other object. 003 means the relationship is a discount-in-kindrelationship. 004 means the relationship is a spare-part relationship.005 means the relationship is an accessories relationship. 006 means therelationship is a substitute-product relationship.

GDT ObjectStructureRelationshipTypeCode 16000 is used for typingrelationships between objects of a single object type, for example,relationships between products (e.g., a spare-part relationship),relationships between (document) items (e.g., a discount-in-kindrelationship), or relationships between project plans.

The typing of relationships between objects of different object typesmay not be covered by this GDT. This includes relationships between aproduct and a business document, between a marketing plan and amarketing campaign, between a business document and an item of adocument, or between a project plan and a project plan element.

Furthermore, the GDT ObjectStructureRelationshipTypeCode 16000 may berestricted to the typing of relationships from a purely businessperspective. In a variation, technical typings (e.g., “implemented by”or “generated from”) may not be covered.

(vvvvv) OrdinalNumberValue

A GDT OrdinalNumberValue 16100 is a number that indicates the positionof an element in a linearly ordered set that is ordered according toparticular factors. An example of GDT OrdinalNumberValue 16100 is:

<OrdinalNumberValue>4</OrdinalNumberValue>.

The structure of GDT OrdinalNumberValue 16100 is depicted in FIG. 161.The GDT Ordinal Number Value 16100, the Representation/AssociationQuality is Ordinal Number 16102, the Representation/Association is Value16104, the Type is xsd 16106, the Type Name is Positive Integer 16108,an the Length is from one to nine 16110.

Positive, whole numbers smaller than one billion are permitted. GDTOrdinalNumberValue 16100 may be used in a catalog to specify the orderof characteristics in a list of characteristics.

(wwwww) PartialDelivery

A GDT PartialDelivery 16200 is the maximum number of partial deliveriesthat may/can be carried out to deliver the ordered quantity of an item.An example of GDT PartialDelivery 16200 is: <PartialDelivery>  <MaximalNumber>    9   <\MaximalNumber> <\ PartialDelivery >.

The structure of GDT PartialDelivery 16200 is depicted in FIG. 162. Forthe GDT Partial Delivery 16200, the Object Class is Partial Delivery16202 and the Representation/Association is Details 16204.

For Category Element 16206, the Object Class is Partial Delivery 16208,the Property is Maximal Number 16210, the Representation/Association isInteger 16212, the Type is GDT 16214, the Type Name is Integer Value16216, the Length is one 16218. The Cardinality is zero or one 16220.For Category Element 16206, zero not allowed 16222. A length of 1 in theMaximalNumber field means that a maximum of up to 9 partial deliverieswill be accepted to fulfill the ordered quantity. The specification ismade as a whole number without any plus/minus sign (e.g., 9). No entryin this field means that complete delivery is wanted and no partialdelivery is allowed even if the UnlimitedIndicator is not set.

For Category Element 16224, the Object Class is Partial Delivery 16226,the Property is Unlimited Indicator 16228, theRepresentation/Association is Indicator 16230, the Type is GDT 16232,the Type Name is Value Unlimited Indicator 16234, and the Length is one16236. The Cardinality is zero or one 16238. The UnlimitedIndicator canhave the values 1 (true) or 0 (false). True means that a number ofpartial deliveries will be accepted. False means that a number ofpartial deliveries will not be accepted. The fields MaximalNumber andUnlimitedIndicator are mutually exclusive, i.e., entering “true” or “1”in the UnlimitedIndicator and simultaneously making an entry in Numberis not logical.

PartialDelivery comprises two child elements, Number from the CCT:Numeric and UnlimitedIndicator from the CCT: Indicator.

GDT PartialDelivery 16200 indicates the maximum number of partialdeliveries (including the first delivery) that may be performed todeliver the ordered quantity of an item.

(xxxxx) PartyID

A GDT PartyID 16300 is a unique identifier for a party. A party is anatural person, organization, or group in which a company has a businessor intra-enterprise interest. This could be a person, organization, orgroup within or outside of the company. An example of GDT PartyID 16300is:

Example 1: Standard ID, Standard Agency <PartyID schemeID=“DUNS”schemeAgencyID=“016”> 065055766 </PartyID> 065055766 = Bosch at DUNS 016= DUNS from Code List DE 3055

<PartyID schemeID=“PartyID” schemeAgencyID=“BPL_300”>schemeAgencySchemeAgencyID=“ZZZ”> 4711 </PartyID>.

In the above examples, 4711 refers to the business partner in systemBPL_(—)300 with SAP CMDMm and ZZZ refers to a proprietary agency fromCode List DE 3055.

The structure of GDT PartyID 16300 is depicted in FIG. 163. The GDTPartyID 16300 includes attributes schemeID 16316, schemeAgencyID 16334,schemeAgencySchemeID 16352, and schemeAgencySchemeAgencyID 16370. Forthe GDT PartyID 16300, the Object Class is Party 16302, the Property isIdentification 16304, the Representation/Association term is Identifier16306, the Type term is CCT 16308, the Type Name term is Identifier16310, and the Length is from one to sixty 16312. The GDT PartyID 16300may be a restricted GDT.

For the schemeID 16316, the Category is Attribute 16318, the ObjectClass is IdentificationScheme 16320, the Property tem is Identification16322, the Representation/Association term is Identifier, the Type termis xsd 16326, the Type Name term is Token 16328, and the Length is fromone to sixty 16330. The Cardinality between the GDT PartyID 16300 andthe schemeID 16316 is zero or one 16332.

For the schemeAgencyID 16334, the Category is Attribute 16336, theObject Class is IdentificationSchemeAgency 16338, the Property isIdentification 16340, the Representation/Association term is Identifier16342, the Type term is xsd 16344, the Type Name term is Token 16346,and the Length is from one to sixty 16348. The Cardinality between theGDT PartyID 16300 and the schemeAgencyID 16334 is zero or one 16350.

For the schemeAgencySchemeID 16352, the Category is Attribute 16354, theObject Class is IdentificationSchemeAgency 16356, the Property is Scheme16358, the Representation/Association term is Identifier 16360, the Typeterm is xsd 16362, the Type Name term is Token 16364, and the Length isfrom one to sixty 16366. The Cardinality between the GDT PartyID 16300and the schemeAgencySchemeID 16352 is zero or one 16368.

For the schemeAgencySchemeAgencyID 16370, the Category is Attribute16372, the Object Class is IdentificationSchemeAgency 16374, theProperty is SchemeAgency 16376, the Representation/Association term isIdentifier 16378, the Type term is xsd 16380, the Type Name term isToken 16382, and the Length is three 16384. The Cardinality between theGDT PartyID 16300 and the schemeAgencySchemeAgencyID 16370 is zero orone 16386.

The definition of the GDT PartyID 16300 includes persons, organizations,and party groups. The name GDT PartyID 16300 was intentionally choseninstead of BusinessPartnerID in order to be able to use the GDT forparties in which there is no direct business interest (e.g., employees'partners or children). The GDT is intended to cover roles which a partymight assume. IDs that identify a party are permitted. IDs that identifya location may not be permitted.

GDT PartyID 16300 is used for software representation of a naturalperson, a legal person (organization), or a grouping of natural persons,legal persons, and their groupings (business partner group). Thedifferent roles of a party (e.g., Buyer, Vendor, Supplier) can be usedin accordance with the UBL standard to enhance element names (e.g.,BuyerPartyID).

(yyyyy) PartyInternalID

A CDT PartyInternalID 16400 is a proprietary identifier for a party. Aparty is a natural person, organization, or group in which a company hasa business or intra-enterprise interest. This could be a person,organization, or group within or outside of the company. An example of aGUID of a party is:   <PartyInternalID schemeID=“PartyGUID”schemeAgencyID= “MPL_002”>1C743CEC501F6A4D8826C7EC5A8554B9</PartyInternal ID>

In the example, schemeID=“PartyGUID” indicates that the scheme“PartyGUID” was used to identify the party, andschemeAgencyID=“MPL_(—)002” indicates that the scheme was assigned bythe business system “MPL_(—)002.”

The following is an example of a party ID of a party:   <PartyInternalIDschemeID=“PartyID” schemeAgencyID=“MPL_002”>4711</PartyInternalID>.

The structure of CDT PartyInternalID 16400 is depicted in FIG. 164. TheCDT PartyInternalID 16400 includes attributes schemeID 16418 andschemeAgencyID 16436. For the CDT PartyInternalID 16400, the ObjectClass is Party 16402, the Property Qualifier term is Internal 16404, theProperty is Identification 16406, the Representation/Association term isIdentifier 16408, the Type term is GDT 16410, the Type Name term isPartyID 16412, and the Length is from one to thirty-two 16414. The CDTPartyInternalID 16400 may be a restricted CDT.

For the schemeID 16418, the Category is Attribute 16420, the ObjectClass is IdentificationScheme 16422, the Property is Identification16424, the Representation/Association term is Identifier 16426, the Typeterm is xsd 16428, the Type Name term is Token 16430, and the Length isfrom one to sixty 16432. The Cardinality between the CDT PartyInternalID16400 and the schemeID 16418 is zero or one 16434.

For the schemeAgencyID 16436, the Category is Attribute 16438, theObject Class is IdentificationSchemeAgencyID 16440, the Property isIdentification 16442, the Representation/Association term is Identifier16444, the Type term is xsd 16446, the Type Name term is Token 16448,and the Length is from one to sixty 16450. The Cardinality between theCDT PartyInternalID 16400 and the schemeAgencyID 16436 is zero or one16452.

PartyGUID and PartyID are schemes provided for scheme ID. PartyGUIDidentifies a party via a Global Unique Identifier, and PartyIDidentifies a party via an identification number. ShemeAgencyIDidentifies a business system in which the identifier was assigned.

The CDT PartyInternalID 16400 represents a projection of the GDT“PartyID,” in which the attributes “schemeID” and “schemeAgencyID” arecontained for describing an internally assigned ID. If an attribute isnot explicitly assigned in the use of the CDT, it may be determinedthrough the context.

The CDT PartyInternalID 16400 is used when both sender and recipient canaccess shared master data, e.g., during internal communication.

(zzzzz) PartyPartyID

A CDT PartyPartyID 16500 is an identifier for a party assigned by aparty. A party is a natural person, organization, or group in which acompany has a business or intra-enterprise interest. This could be aperson, organization, or group within or outside of the company. Anexample is:

<BuyerPartySellerID>ABC</BuyerPartySellerID>

(the ID assigned by the seller for the Buyer).

The structure of CDT PartyPartyID 16500 is depicted in FIG. 165. For theCDT PartyPartyID 16500, the Object Class is Party 16502, the PropertyQualifier term is Party 16504, the Property is Identification 16506, theRepresentation/Association term is Identifier 16508, the Type term isGDT 16510, the Type Name term is PartyID 16512, and the Length is fromone to sixty 16514. The CDT PartyPartyID 16500 may be a restricted CDT.

The CDT PartyPartyID 16500 is the proprietary identifier assigned by aparty. The party (in its role) that assigned this identifier may derivefrom the context of the message that the CDT PartyPartyID 16500 uses.The CDT PartyPartyID 16500 limits the general identifier PartyID. Incontrast to “PartyStandardID,” the use of the “PartyPartyID” isrole-dependent (e.g., as an ID assigned by the Buyer). The party thatassigns the ID is indicated by its role. The “Party” is replaced withthe “partner role type” (e.g., PartySellerID). The SchemeID andschemeVersionID may be included as attributes to differentiate betweenseveral schemes. (See also PartyID and PartyStandardID).

(aaaaaa) PartyStandardID

A CDT PartyStandardID 16600 is a standardized identifier for a party,and the identification scheme used is controlled by an agency from thecode list DE 3055. A party is a natural person, organization, orbusiness partner group in which a company has a business orintra-enterprise interest. This could be a person, organization, orgroup within or outside of the company. An example is: <BuyerParty>  ...   <StandardID schemeAgencyID=“016”>123456789   </PartyStandardID>  ... </BuyerParty>

(the standardID assigned for the buyer).

The structure of PartyStandardID is depicted in FIG. 166. The CDTPartyStandardID 16600 includes attribute schemeAgencyID 16618. For theCDT PartyStandardID 16600, the Object Class is Party 16602, the PropertyQualifier term is Standard 16604, the Property is Identification 16606,the Representation/Association term is Identifier 16608, the Type termis GDT 16610, the Type Name term is PartyID 16612, and the Length isfrom one to thirteen. The CDT PartyStandardID 16600 may be a restrictedCDT.

For the schemeAgencyID 16618, the Category is Attribute 16620, theObject Class is IdentificationSchemeAgency 16622, the Property isIdentification 16624, the Representation/Association term is Identifier16626, the Type term is xsd 16628, the Type Name term is Token 16630,and the Length is three 16632. The Cardinality between the CDTPartyStandardID 16600 and the schemeAgencyID 16618 is one 16634.

The attribute ‘schemeAgencyID’ can contain values from the code list DE3055. The codes which are supported for schemeAgencyID are: 1) 009(EAN.UCC) for the 13-character Global Location Number (GLN); 2) 016(Dun&Bradstreet Corporation) for the 9-character DUNS (Data UniversalNumbering System); and 3) 182 (US, Standard Carrier Alpha Code (Motor)Organization) for the 2-to-4-character SCAC (Standard Carrier AlphaCode).

CDT PartyStandardID 16600 limits the general identifier PartyID tostandard identifiers, whose scheme was assigned by a standardizationorganization from code list DE 3055. IDs that identify a party arepermitted. IDs that identify a location may not be permitted. Incontrast to PartyPartyID, use of CDT PartyStandardID 16600 is not roledependent. See also PartyID and PartyPartyID.

(bbbbbb) PaymentCard

A GDT PaymentCard 16700 is an identification card that authorizes theholder to settle invoices without cash with contract companies connectedto the payment system. An example is:   CreditCard VISA:   <PaymentCard>   <ID schemeAgencyID=“XYZ” schemeAgencySchemeID=“9362”schemeAgencySchemeAgencyID=“5”>5555222200008888</ID>   <ReferenceID>8765432</ReferenceID>    <SequenceID>01</SequenceID>   <HolderName>Mayermann</HolderName>   <ExpiryDate>2005-05-31</ExpiryDate>   </PaymentCard>   CustomerCardIKEAGold:   <PaymentCard>    <ID schemeID=“IKEAGold”schemeAgencyID=“124224” schemeAgencySchemeID=“DUNS”schemeAgencySchemeAgencyID=“16”>     AEIBDEFXXXX    </ID>   <ReferenceID>8765432</ReferenceID>   <HolderName>Mayermann</HolderName>   <ExpiryDate>2005-05-31</ExpiryDate>   </PaymentCard>.

The structure of GDT PaymentCard 16700 is depicted in FIG. 167. The GDTPaymentCard 16700 includes elements ID 16706, ReferenceID 16722,SequenceID 16740, Holder 16760, and ExpirationDate 16778. For the GDTPayment Card 16700, the Object Class is Payment Card 16702, and theRepresentation/Association term is Details 16704.

-   -   The ID is an unique identifier for a payment card. For the ID        16706, the Category is Element 16708, the Object Class is        Payment Card 16710, the Property is Identification 16712, the        Representation/Association term is Identifier 16714, the Type        term is GDT 16716, and the Type Name term is PaymentCardID        16718. The Cardinality between the GDT PaymentCard 16700 and the        ID 16706 is one 16720.    -   The ReferenceID is an additional reference number that is        required for certain credit cards or customer cards for security        purposes to guarantee error-free processing. For the ReferenceID        16722, the Category is Element 16724, the Object Class is        PaymentCard 16726, the Property is Reference Identification        16728, the Representation/Association term is Identifier 16730,        the Type term is CCT 16732, the Type Name term is Identifier        16734, and the Length is from one to twenty-five 16736. The        Cardinality between the GDT PaymentCard 16700 and the        ReferenceID 16722 is zero or one 16738. The ReferenceID 16722        may be restricted 16740.    -   The SequenceID is a sequence number of the payment card that        indicates that the bank has issued more than one card for an        account, and identifies which card is being used in this case.    -   For the SequenceID 16740, the Category is Element 16742, the        Object Class is PaymentCard 16744, the Property is Sequence        Identification 16746, the Representation/Association term is        Identifier 16748, the Type term is CCT 16750, the Type Name term        is Identifier 16752, and the Length is from one to ten 16754.        The Cardinality between the GDT PaymentCard 16700 and the        SequenceID 16740 is zero or one 16756. The SequenceID 16740 may        be restricted 16758.    -   The Holder is the name of the cardholder (name of a person or        company; for a person's name, both first and last names are        usually included). For the Holder 16760, the Category is Element        16762, the Object Class is Payment Card 16764, the Property is        Holder 16766, the Representation/Association term is Text 16768,        the Type term is CCT 16770, the Type Name term is text 16772,        and the Length is from one to forty 16774. The Cardinality        between the GDT PaymentCard 16700 and the Holder 16760 is zero        or one 16776.    -   The ExpirationDate is an expiration date of the payment card.        For the ExpirationDate 16778, the Category is Element 16780, the        Object Class is Payment Card 16782, the Property is Expiration        Date 16784, the Representation/Association term is Date 16786,        the Type term is GDT 16788, and the Type Name term is Date        16790. The Cardinality between the GDT PaymentCard 16700 and the        ExpirationDate 16778 is one 16792.

No restriction is placed on company-specific customer cards in terms ofthe possible identifications based on UN/CEFACT code list DE 3055. TheGDT PaymentCard 16700 is used when the payment card is a credit cardthat belongs to one of the listed standard types, or a company-specificcustomer card.

(cccccc) PaymentCardID

A GDT PaymentCardID 16800 is a unique identifier for a payment card. Anexample is:   CreditCard VISA:   <PaymentCardID     schemeAgencyID=“XYZ”schemeAgencySchemeID=“9362”schemeAgencySchemeAgencyID=“5”>5555222200008888   </IPaymentCardID>  CustomerCard IKEAGold:   <PaymentCardID>     schemeID=“IKEAGold”schemeAgencyID=“124224” schemeAgencySchemeID=“DUNS”schemeAgencySchemeAgencyID=“16”> AEIBDEFXXXX   </PaymentCardID>

The structure of GDT PaymentCardID 16800 is depicted in FIG. 168. TheGDT PaymentCardID 16800 includes attributes schemeID 16820,schemeAgencyID 16838, schemeAgencySchemeID 16856, andschemeAgencySchemeAgencyID 16874. For the GDT PaymentCardID 16800, theCategory is Element 16802, the Object Class is Payment Card 16804, theProperty is Identification 16806, the Representation/Association term isIdentifier 16808, the Type term is CCT 16810, the Type Name term isIdentifier 16812, and the Length is from one to twenty-five 16814. TheCardinality of the GDT PaymentCardID 16800 is one 16816. The GDTPaymentCardID 16800 may be a restricted GDT.

For the schemeID 16820, the Category is Attribute 16822, the ObjectClass is Identification Scheme 16824, the Property is Identification16826, the Representation/Association term is Identifier 16828, the Typeterm is xsd 16830, the Type Name term is token 16832, and the Length isfrom one to sixty 16834. The Cardinality between the GDT PaymentCardID16800 and the schemeID 16820 is one 16836.

For the schemeAgencyID 16838, the Category is Attribute 16840, theObject Class is Identification Scheme Agency 16842, the Property isIdentification 16844, the Representation/Association term is Identifier16846, the Type term is xsd 16848, the Type Name term is token 16850,and the Length is from one to sixty 16852. The Cardinality between theGDT PaymentCardID 16800 and the schemeAgencyID 16838 is one 16854.

For the schemeAgencySchemeID 16856, the Category is Attribute 16858, theObject Class is Identification Scheme Agency 16860, the Property isScheme 16862, the Representation/Association term is Identifier 16864,the Type term is xsd 16866, the Type Name term is token 16868, and theLength is from one to sixty 16870. The Cardinality between the GDTPaymentCardID 16800 and the schemeAgencySchemeID 16856 is zero or one16872.

For the schemeAgencySchemeAgencyID 16874, the Category is Attribute16876, the Object Class is Identification Scheme Agency 16878, theProperty is Scheme Agency 16880, the Representation/Association term isIdentifier 16882, the Type term is xsd 16886, the Type Name term istoken 16886, and the Length is three 16888. The Cardinality between theGDT PaymentCardID 16800 and the schemeAgencySchemeAgencyID 16874 is zeroor one 16890.

No restriction is placed on company-specific customer cards in terms ofthe possible identifications based on UN/CEFACT code list DE 3055. In avariation, the identifier for the standard types is based on the BIC(Bank Identification Code), whose scheme is standardized according toISO 9362: 1994. Therefore, the attribute “schemeAgencySchemeID” is setto 9362 for standard types, and the attribute“schemeAgencySchemeAgencyID” is set to ‘5’ for ISO. Standard types areregistered using SWIFT. These standard types can be queried at thefollowing link: www.swift.com/biconline/index.cfm Then, e.g., “XYZ” isthe result for attribute “schemeAgencyID.”

The responsible organizations for the company-specific customer cardsare identified via a generally valid and standardized identification,like that of Dun & Bradstreet. For this, the attribute “schemeID” maycontain the identifier of the corresponding identification list (e.g.,IKEAGold). In the attribute “schemeAgencyID,” the particular uniqueidentification may correspond to the responsible organization accordingto the international standardized identifier list (for example, DUNS).The attribute “schemeAgencySchemeID” contains the identification of thescheme on which the organization identifier is based, and the attribute“schemeAgencySchemeAgencyID” contains the particular identificationaccording to the DE 3055 code list, which is responsible for theinternational and standardized identification scheme for the responsibleorganization of the company-specific customer card.

(dddddd) PaymentFormCode

The CDT PaymentFormCode 16900 is a coded representation of the paymentform. The payment form is the way in which, e.g., goods or services arepaid for. An example is:

<PaymentFormCode>01</PaymentFormCode>.

The structure of CDT PaymentFormCode 16900 is depicted in FIG. 169. Forthe CDT PaymentFormCode 16900, the Object Class is Payment 16902, theProperty is Form Code 16904, the Representation/Association term is Code16906, the Type term is CCT 16908, the Type Name term is Code 16910, andthe Length is two 16912. The CDT PaymentFormCode 16900 may be arestricted CDT.

CDT PaymentFormCode 16900 can have the following values: 01) Invoice,which means that the selling company issues an invoice to the buyer; 02)PaymentCard, which means that the buyer pays with credit card, customercard, or generally a payment card; 03) CashOnDelivery, which means thatthe payment is made on delivery; and 04) BankCollection, which meansthat the payment is carried out using automatic debit.

Existing standardized code lists (e.g., UN/EDIFACT code list ‘4461’,Payment Means Code) may not cover these values. Consequently, the abovecode list may be used for this GDT, and this code list is submitted tothe responsible standardization body. The CDT PaymentFormCode 16900 isused to determine the payment form when goods or services are ordered.The code “Invoice” is the default value.

The CDT PaymentFormCode 16900 does not contain additional informationneeded for payment processing, e.g., the type and number of the creditcard or the number of the bank account from which the payment should bedebited. Some of this information is transmitted in other parts of themessage, and some is transmitted in separate messages. The CDTPaymentFormCode 16900 should not be confused with the PaymentMethod,which describes in detail how a payment is carried from FI, HR, or theTreasury.

Some parts of the UN/EDIFACT code list 4461 (Payment Means Code) (or ASCX12 107) can also be used for the PaymentMethodCode, including 1)Domestic bank transfer; 2) Foreign bank transfer; 3) Postal transfer; 4)Bank direct debit; 5) Check; 6) Order check; 7) Bank check; and 8) Billof exchange.

A suitable payment method is determined based on the payment form. Thesetwo terms cannot be placed together in one list, as shown below.PaymentFormCode >>> PaymentMethodCode Invoice BankTransfer, CheckPaymentCard PaymentCard CashOnDelivery Check, Cash BankCollectionDirectDebit

Up until CRM 4.0, three values (PaymentCard, CashOnDelivery, PerInvoice) are used. If a payment is to be made per invoice, it is notnecessary to specify a payment form. To use a new value, animplementation for the new code may be made; therefore, CRM may notaccept other values.

(eeeeee) Percent

A GDT Percent 17000 is a number that relates to the comparison FIG. 100.An example is: <ProductTaxPercent>16</ProductTaxPercent>.

The structure of GDT Percent 17000 is depicted in FIG. 170. GDT Percent17000 is given as a percent value. For the GDT Percent 17000, theCategory is Element 17002, the Representation/Association term isPercent 17004, the Type term is xsd 17006, the Type Name term is decimal17008, and the Length is maximum ten predecimal values and 6 decimalvalues 17010.

Positive and negative values can be used by using the built-in data type“xsd: decimal.” Negative values may be prefixed with a negative sign(“−”). However, positive values do not require a positive sign “+”prefix.

No measurements or currencies are specified in GDT Percent 17000.

GDT Percent 17000 can be used to represent a percentage that indicateshow many hundredths of a basic value are to be calculated. The result ofthe calculation is the proportion in percent of, e.g., amounts, values,rates, discounts, and taxes. Further examples for the application ofPercent are proportion and comparison information, such as dividends andearnings, or a percentage comparison of target and actual businessresults, or trade or amount margins.

Information on measurements or currencies may be expressed in the basicvalue, for example: <Total> <Amount currencyCode=“EUR”>777.95</Amount><ProductTaxPercent>16</ProductTaxPercent> </Total>

Here the value added tax rate of 16 percent is specified for the basicvalue of 777.95 EUR.

(ffffff) PersonName

A GDT PersonName 17100 contains the parts of a natural person's name. Anexample is: <PersonName> <FormattedName>Mr. Paul JohnTester</FormattedName> <LegalName>Paul John Tester</LegalName><GivenName></GivenName> <PreferredGivenName>Paul</PreferredGivenName><MiddleName>John</MiddleName> <Family>   <FamilyName>Tester</FamilyName>  <PrimaryIndicator>true</PrimaryIndicator>  <FamilyNamePrefix></FamilyNamePrefix> </Family> <Affix>  <AffixName>Mr.</AffixName>   <AffixCode>FormOfAddress</AffixCode></Affix> </PersonName>

The structure of GDT PersonName 17100 is depicted in FIG. 171. The GDTPersonName 17100 includes elements FormattedName 17108, LegalName 17126,GivenName 17144, PreferredGivenName 17162, MiddleName 17180, Family17198, FamilyName 17111, PrimaryIndicator 17127, FamilyNamePrefix 17147,Affix 17167, AffixName 17179, and AffixCode 17197. For the GDTPersonName 17100, the Category is Element 17102, the Object Class isPersonName 17104, and the Representation/Association term is Details17106.

The attribute FormattedName 17108 contains, in one string, a formattedname with its pieces in their places. This includes the necessarypunctuation. For the FormattedName 17108, the Category is Element 17110,the Object Class is PersonName 17112, the Property is FormattedName17114, the Representation/Association term is Name 17116, the Type termis xsd 17118, the Type Name term is string 17120, and the Length iseighty 17122. The Cardinality between the GDT PersonName 17100 and theFormattedName 17108 is zero or one 17124.

The attribute LegalName 17126 is the legal name used for legaldocumentation or other legal purposes. LegalName 17126 contains, in onestring, a formatted name with its pieces in their places. This includesthe necessary punctuation. For the LegalName 17126, the Category isElement 17128, the Object Class is PersonName 17130, the Property isLegalName 17132, the Representation/Association term is Name 17134, theType term is xsd 17136, the Type Name term is string 17138, and theLength is eighty 17140. The Cardinality between the GDT PersonName 17100and the LegalName 17126 is zero or one 17142.

The attribute GivenName 17144 contains the given or chosen name. Alsoknown as a person's first name. If multiple givenNames are used, theorder is implied. For the GivenName 17144, the Category is Element17146, the Object Class is PersonName 17148, the Property is GivenName17150, the Representation/Association term is Name 17152, the Type termis xsd 17154, the Type Name term is string 17156, and the Length isforty 17158. The Cardinality between the GDT PersonName 17100 and theGivenName 17144 is zero or unbounded 17160.

The attribute PreferredGivenName 17162 contains the chosen name by whichthe person prefers to be addressed. Note: This name may be a name otherthan a given name, such as a nickname. For the PreferredGivenName 17162,the Category is Element 17164, the Object Class is PersonName 17166, theProperty is PreferredGivenName 17168, the Representation/Associationterm is Name 17170, the Type term is xsd 17172, the Type Name term isstring 17174, and the Length is from one to forty 17176. The Cardinalitybetween the GDT PersonName 17100 and the PreferredGivenName 17162 iszero or one 17178.

The attribute MiddleName 17180 contains a person's middle name orinitial. For the MiddleName 17180, the Category is Element 17182, theObject Class is PersonName 17184, the Property is MiddleName 17186, theRepresentation/Association term is Name 17188, the Type term is xsd17190, the Type Name term is string 17192, and the Length is from one toforty 17194. The Cardinality between the GDT PersonName 17100 and theMiddleName 17180 is zero or unbounded 17196.

The attribute Family 17198 contains the non-chosen or inherited name.Also known as a person's last name in the Western context. For theFamily 17198, the Category is Element 17101, the Object Class isPersonName 17103, the Property is Family 17105, and theRepresentation/Association term is Detail 17107. The Cardinality betweenthe GDT PersonName 17100 and the Family 17198 is zero or unbounded17109.

The element FamilyName 17111 describes the non-chosen or inherited name.For the FamilyName 17111, the Category is Element, the Object Class isFamily 17113, the Property is FamilyName 17115, theRepresentation/Association term is Name 17117, the Type term is xsd17119, the Type Name term is string 17121, and the Length is from one toforty 17123. The Cardinality between the GDT PersonName 17100 and theFamilyName 17111 is one 17125.

The element PrimaryIndicator 17127 allows you to mark one family name tobe printed or shown first. For the PrimaryIndicator 17127, the Categoryis Element 17129, the Object Class is Family 17131, the Property isFamilyNamePrimaryCode 17133, the Representation/Association term is Code17135, the Type is CCT 17137, the Type Name term is Indicator 17139, andthe Length is one 17141. The Cardinality between the GDT PersonName17100 and the PrimaryIndicator 17127 is zero or one 17143. ThePrimaryIndicator 17127 is a no default value 17145.

The element FamilyNamePrefix 17147 contains the PersonName prefix, suchas an aristocratic prefix. For the FamilyNamePrefix 17147, the Categoryis Element 17149, the Object Class is Family 17151, the Property isFamilyNamePrefix 17153, the Representation/Association term is Text17155, the Type term is xsd 17157, the Type Name term is string 17159,and the Length is from one to twenty 17161. The Cardinality between theGDT PersonName 17100 and the FamilyNamePrefix 17147 is zero or one17163. The FamilyNamePrefix 17147 may be different from the HR-XMLProposal 17165.

The attribute Affix 17167 contains the remaining parts of the PersonNameas defined by the elements AffixName and AffixCode. For the Affix 17167,the Category is Element 17169, the Object Class is PersonName 17171, theProperty is Affix 17173, and the Representation/Association term isDetail 17175. The Cardinality between the GDT PersonName 17100 and theAffix 17167 is zero or unbounded 17177.

The element AffixName 17179 contains the affix. For the AffixName 17179,the Category is Element 17181, the Object Class is Affix 17183, theProperty is Affix 17185, the Representation/Association term is Name17187, the Type term is xsd 17189, the Type Name term is string 17191,and the Length is from one to twenty 17193. The Cardinality between theGDT PersonName 17100 and the AffixName 17179 is one 17195.

The element AffixCode 17197 defines the context for the affix. For theAffixCode 17197, the Category is Element 17199, the Object Class isAffix 17102 a, the Property is AffixCode 17104 a, theRepresentation/Association term is Code 17106 a, the Type is CCT 17108a, the Type Name term is Code 17110 a, and the Length is from one totwenty 17112 a. The Cardinality between the GDT PersonName 17100 and theAffixCode 17197 is one 17114 a.

The code=aristocraticTitle, contains titles, such as, Baron, Earl, andso on. The code=formOfAddress, contains the form of address, for exampleMr., Mrs., Hon., Dr., or Major. The code=generation, contains terms suchas, Sr., Jr., III (the third). The code=qualification, contains theletters used to describe academic or other type qualifications held by aperson and/or the distinctions conferred upon them, for example PhD, MD,CPA, or MCSD.

GDT PersonName 17100 is used to identify actual people.

(gggggg) PersonnelTimeEventID

A GDT PersonnelTimeEventID 17200 is a unique ID for a personnel timeevent. A personnel time event is a change in the execution of servicesof a personnel resource with which one personnel time ends and anotherpersonnel time begins. Such changes can include, e.g., the start ofwork, interruption of work or end of work. A personnel time event ischaracterized by a type such as, e.g., “clock-in entry,” “clock-outentry,” or “start of break.” A personnel time event can includeadditional information (e.g., reference to project, order, cost center)for different target applications (e.g., project system or Controlling).An example is:

<PersonnelTimeEventID>1234567890123456</PersonnelTimeEventID>.

The structure of GDT PersonnelTimeEventID 17200 is depicted in FIG. 172.The GDT PersonnelTimeEventID 17200 includes attributes schemeID 17216and schemeAgencyID 17234. For the GDT PersonnelTimeEventID 17200, theObject Class is Personnel Time Event 17202, the Property isIdentification 17204, the Representation/Association term is Identifier17206, the Type term is GDT 17208, the Type Name term is Identifier17210, and the Length is from one to forty 17212. The GDTPersonnelTimeEventID 17200 may be a restricted GDT.

The schemeID specifies the scheme according to which the ID wasassigned. Currently, the following schemes are provided: 1)PersonnelTimeEventGUID, which identifies the personnel time event via aGlobal Unique Identifier; and 2) PersonnelTimeTypeID: Identifies thepersonnel time event via an internal identifier of the scheme agency.For the schemeID 17216, the Category is Attribute 17218, the ObjectClass is IdentificationScheme 17220, the Property is Identification17222, the Representation/Association term is Identifier 17224, the Typeterm is xsd 17226, the Type Name term is Token 17227, and the Length isfrom one to sixty 17230. The Cardinality between the GDTPersonnelTimeEventID 17200 and the schemeID 17216 is zero or one 17232.

The schemeAgencyID 17234 identifies the business system in which the IDwas assigned. For the schemeAgencyID 17234, the Category is Attribute17236, the Object Class is IdentificationSchemeAgency 17238, theProperty is Identification 17240, the Representation/Association term isIdentifier 17242, the Type term is xsd 17244, the Type Name term isToken 17246, and the Length is from one to sixty 17248. The Cardinalitybetween the GDT PersonnelTimeEventID 17200 and the schemeAgencyID 17234is zero or one 17250.

If PersonnelTimeEventGUID is used for schemeID, PersonnelTimeEventID maycomprise 1-40 characters. If “PersonnelTimeEventID” is used,PersonnelTimeEventID may comprise 1-16 characters and may bealphanumeric. If schemeID and schemeAgencyID have not been specified,they may be determined from the context.

(hhhhhh) PersonnelTimeEventTypeID

A GDT PersonnelTimeEventTypeID 17300 is a unique ID for a personnel timeevent type. A personnel time event type is a classification of personneltime events according to personnel time management criteria. A typicalcriterion is whether the employee is at work or not. Examples are“clock-in entry,” “clock-out entry,” or “start of break.” An example is:

<PersonnelTimeEventTypeID>1234567890123456</PersonnelTimeEventTypeID>

The structure of GDT PersonnelTimeEventTypeID 17300 is depicted in FIG.173. The GDT PersonnelTimeEventTypeID 17300 includes attributes schemeID17316 and schemeAgencyID 17334. For the GDT PersonnelTimeEventTypeID17300, the Object Class is Personnel Time Event Type 17302, the Propertyis Identification 17304, the Representation/Association term isIdentifier 17306, the Type term is GDT 17308, the Type Name term isIdentifier 17310, and the Length is from one to forty 17312. The GDTPersonnelTimeEventTypeID 17300 may be a restricted GDT.

SchemeID 17316 identifies the scheme according to which the ID wasassigned. For example, the following schemes may be supported: 1)PersonnelTimeEventTypeGUID, which identifies the personnel time eventtype using a Global Unique Identifier; and 2) PersonnelTimeEventTypeID:Identifies the personnel time event type using an internal identifierfor the scheme agency. For the schemeID 17316, the Category is Attribute17318, the Object Class is IdentificationScheme 17320, the Property isIdentification 17322, the Representation/Association term is Identifier17324, the Type term is xsd 17326, the Type Name term is Token 17328,and the Length is from one to sixty 17330. The Cardinality between theGDT PersonnelTimeEventTypeID 17300 and the schemeID 17316 is zero or one17332.

The schemeAgencyID 17334 specifies the business system in which the IDwas assigned. For the schemeAgencyID 17334, the Category is Attribute17336, the Object Class is IdentificationSchemeAgency 17338, theProperty is Identification 17340, the Representation/Association term isIdentifier 17342, the Type term is xsd 17344, the Type Name term isToken 17346, and the Length is from one to sixty 17348. The Cardinalitybetween the GDT PersonnelTimeEventTypeID 17300 and the schemeAgencyID17334 is zero or one 17350.

If the PersonnelTimeEventTypeGUID is used for schemeID, thePersonnelTimeEventTypeID may comprise 1-40 characters. If thePersonnelTimeEventTypeID is used, the GDT PersonnelTimeEventTypeID 17300may comprise 1-16 characters and may be alphanumeric. If the schemeID17316 or the schemeAgencyID 17334 have not been specified, they may bedetermined from the context.

(iiiiii) PersonnelTimeID

A GDT PersonnelTimeID 17400 is a unique ID for a personnel time. Apersonnel time is a period of a personnel resource that is characterizedby business, pay scale, or legal criteria. The period can be entered asa duration (e.g., 8 hours on Nov. 10, 2003) or as clock times (e.g.,from 8:10 to 17:30 on Nov. 10, 2003). A personnel time is characterizedby a personnel time type (e.g., “working time,” “leave,” “overtime,”“availability for work,” “illness,” or “work break”). A personnel timecan include additional information (e.g., reference to project, order,cost center) for different target applications (e.g., project system orControlling). An example is:<PersonnelTimeID>1234567890123456</PersonnelTimeID>.

The structure of GDT PersonnelTimeID 17400 is depicted in FIG. 174. TheGDT PersonnelTimeID 17400 includes attributes schemeID 17416 andschemeAgencyID 17434. For the GDT PersonnelTimeID 17400, the ObjectClass is Personnel Time 17402, the Property is Identification 17404, theRepresentation/Association term is Identifier 17406, the Type term isGDT 17408, the Type Name term is Identifier 17410, and the Length isfrom one and forty 17412. The GDT PersonnelTimeID 17400 may be arestricted GDT.

The schemeID 17416 specifies the scheme according to which theidentifier was assigned. For example, the following schemes may beprovided: 1) PersonnelTimeGUID, which identifies the personnel timeusing a Global Unique Identifier; and 2) PersonnelTimeID: Identifies thepersonnel time using an internal identifier for the scheme agency. Forthe schemeID 17416, the Category is Attribute 17418, the Object Class isIdentificationScheme 17420, the Property is Identification 17422, theRepresentation/Association term is Identifier 17424, the Type term isxsd 17426, the Type Name term is Token 17428, and the Length is from oneto sixty 17430. The Cardinality between the GDT PersonnelTimeID 17400and the schemeID 17416.

The SchemeAgencyID 17434 indicates the business system in which theidentifier was assigned. For the schemeAgencyID 17434, the Category isAttribute 17436, the Object Class is IdentificationSchemeAgency 17438,the Property is Identification 17440, the Representation/Associationterm is Identifier 17442, the Type term is xsd 17444, the Type Name termis Token 17446, and the Length is from one to sixty 17448. TheCardinality between the GDT PersonnelTimeID 17400 and the schemeAgencyID17434 is zero or one 17450.

If the PersonnelTimeGUID is used for the schemeID, the PersonnelTimeIDmay comprise 1-40 characters. If the PersonnelTimeID” is used, thePersonnelTimeID may comprise 1-16 characters and may be alphanumeric. Ifthe schemeID or the schemeAgencyID have not been specified, they may bedetermined from the context.

(jjjjjj) PersonnelTimeTypeID

A GDT PersonnelTimeType ID 17500 is a unique identifier for a personneltime type. The PersonnelTimeType is a classification of personnel timesaccording to business, pay scale, or legal criteria. Depending onwhether the employee is at work or absent, the classification can bemade according to payment-relevant or further personnel time managementcriteria. Examples include “working time,” “leave,” “overtime,”“availability for work,” “illness” or “work break.” An example is:<PersonnelTimeTypeID>1234567890123456</PersonnelTimeTypeID>.

The structure of GDT PersonnelTimeTypeID 17500 is depicted in FIG. 175.The GDT PersonnelTimeTypeID 17500 includes attributes schemeID 17516 andschemeAgencyID 17534. For the GDT PersonnelTimeTypeID 17500, the ObjectClass is Personnel Time Type 17502, the Property is Identification17504, the Representation/Association term is Identifier 17506, the Typeterm is GDT 17508, the Type Name term is Identifier, and the Length isfrom one to forty 17512. The GDT PersonnelTimeTypeID 17500 may be arestricted GDT.

The schemeID 17516 indicates the scheme according to which theidentifier was assigned. For example, the following schemes may beprovided: 1) PersonnelTimeTypeGUID, which identifies the personnel timetype using a Global Unique Identifier; and 2) PersonnelTimeTypeID, whichidentifies the personnel time type using an internal identifier for thescheme agency. For the schemeID 17516, the Category is Attribute 17518,the Object Class is IdentificationScheme 17520, the Property isIdentification 17522, the Representation/Association term is Identifier17524, the Type term is xsd 17526, the Type Name term is Token 17528,and the Length is from one to sixty 17530. The Cardinality between theGDT PersonnelTimeTypeID 17500 and the schemeID 17516 is zero or one17532.

The SchemeAgencyID 17534 specifies the business system in which the IDwas assigned. For the schemeAgencyID 17534, the Category is Attribute17536, the Object Class is IdentificationSchemeAgency 17538, theProperty is Identification 17540, the Representation/Association term isIdentifier 17542, the Type term is xsd 17544, the Type Name term isToken 17546, and the Length is from one to sixty 17548. The Cardinalitybetween the GDT PersonnelTimeTypeID 17500 and the schemeAgencyID is zeroor one 17550.

If the PersonnelTimeTypeGUID is used for the schemeID, thePersonnelTimeTypeID may comprise 1-40 characters. If thePersonnelTimeTypeID is used, the PersonnelTimeTypeID may comprise 1-16characters and may be alphanumeric. If the schemeID or theschemeAgencyID have not been specified, it may be possible to determinethem from the context.

(kkkkkk) PhoneNumber

A GDT PhoneNumber 17600 is a telephone number that comprises theinternational dialing code, regional area code, number, and extension.An example is: <PhoneNumber> <AreaID>6227</AreaID><SubscriberID>7</SubscriberID> <ExtensionID>47474</ExtensionID><CountryCode>DE</ CountryCode> </PhoneNumber>

The structure of GDT PhoneNumber 17600 is depicted in FIG. 176. The GDTPhoneNumber 17600 contains one telephone number. The GDT PhoneNumber17600 includes elements AreaID 17606, SubscriberID 17626, ExtensionID17646, and CountryCode 17666. For the GDT PhoneNumber 17600, the ObjectClass is PhoneNumber 17602 and the Representation/Association term isDetails 17604.

The AreaID 17606 indicates the area code if known separately. It may bedisplayed in standardized format, i.e., without a leading zero or thelike. Alternatively, the area code can be displayed together with thetelephone number in SubscriberID 17626. When using a mobile phonenumber, the AreaID 17606 contains the prefix for the mobile phonenetwork (also without a leading zero or the like). The synonym forAreaID 17606 is AreaCodeNumber. For the AreaID 17606, the Category isElement 17608, the Object Class is PhoneNumber 17610, the Property isPhoneNumberArea 17612, the Representation/Association term is Identifier17614, the Type term is CCT 17616, the Type Name term is Identifier17618, and the Length is from one to ten 17620. The Cardinality betweenthe GDT PhoneNumber 17600 and the AreaID 17606 is zero or one 17622. TheAreaID 17606 may be restricted 17624.

The SubscriberID 17626 may indicate the telephone number without theregional area code and without the international dialing code.Alternatively, SubscriberID 17626 can also contain the telephone numbertogether with the regional area code, extension, or both. SubscriberID17626 is displayed in a standardized format that can contain numbers orletters and cannot contain blanks or special characters. A synonym forSubscriberID 17626 is SubscriberNumber. For the SubscriberID 17626, theCategory is Element 17628, the Object Class is PhoneNumber 17630, theProperty is PhoneNumberSubscriber 17632, the Representation/Associationterm is Identifier 17634, the Type term is CCT 17636, the Type Name termis Identifier 17638, and the Length is from one to thirty 17640. TheCardinality between the GDT PhoneNumber 17600 and the SubscriberID 17626is zero or one 17642. The SubscriberID 17626 may be restricted 17644.

The ExtensionID 17646 indicates the extension if the telephone numbercomprises a telephone number and an extension. Alternatively, theextension can be included in SubscriberID 17626 together with thetelephone number. ExtensionID 17646 may be empty if the telephone numberis a cell phone number. A synonym for ExtensionID 17646 isExtensionTelephoneNumber. For the ExtensionID 17646, the Category isElement 17648, the Object Class is PhoneNumber 17650, the Property isPhoneNumberExtension 17652, the Representation/Association term isIdentifier 17654, the Type term is CCT 17656, the Type Name term isIdentifier 17658, and the Length is from one to ten 17660. TheCardinality between the GDT PhoneNumber 17600 and the ExtensionID 17646is zero or one 17662. The ExtensionID 17646 may be restricted 17664.

The CountryCode 17666 identifies the country code in accordance with ISO3166-1. It is used to determine the international dialing code. If it isempty, the country can be derived from the address instead. The countryentered in the address and the country for the telephone number can alsobe different if the telephone number is provided in the context of anaddress. The country code is more appropriate for determining theinternational dialing code than the standardized format (e.g., +49). Forthe CountryCode 17666, the Category is Element 17668, the Object Classis PhoneNumber 17670, the Property is PhoneNumberCountry 17672, theRepresentation/Association term is Code 17674, the Type term is GDT17676, and the Type Name is CountryCode 17678. The Cardinality betweenthe GDT PhoneNumber 17600 and the CountryCode 17666 is zero or one17680.

The telephone number is divided into components based on the MicrosoftTAPI specification and ITU guidelines (International TelecommunicationUnion). The GDT PhoneNumber 17600 is used to describe the sequence ofnumbers that may be dialed to establish a connection. The GDTPhoneNumber 17600 is used for Telephone, MobilePhone, and Facsimile(fax), all of which have a similar structure.

(llllll) Price

A GDT Price 17700 is the exchange value, expressed in a monetary unit,of a product or a service in relation to a basic amount. An example is:  <NetPrice>     <Amount currencyCode=“EUR”>32.14</Amount>    <BaseQuantity unitCode=“C62”>1</BaseQuantity>   </NetPrice> (Note:According to UN/ECE Recommendation 20, C62 is a piece)

The structure of GDT Price 17700 is depicted in FIG. 177. The GDT Price17700 includes elements Amount 17706 and BaseQuantity 17720. For the GDTPrice 17700, the Object Class is Price 17702 and theRepresentation/Association term is Details 17704.

-   -   For the Amount 17706, the Category is Element 17708, the Object        Class is Price 17710, the Property is Amount 17712, the        Representation/Association term is Amount 17714, the Type term        is GDT 17716, and the Type Name term is Amount 17718. The        Cardinality between the GDT Price 17700 and the Amount 17706 is        one. For more on the Amount 17706, see GDT Amount.    -   For the BaseQuantity 17720, the Category is Element 17722, the        Object Class is Price 17724, the Property is Base 17726, the        Representation/Association term is Quantity 17728, the Type term        is GDT 17730, and the Type Name term is Quantity 17732. The        Cardinality between the GDT Price 17700 and the BaseQuantity        17720 is one. For more on the BaseQuantity 17720, see GDT        Quantity.

GDT Price 17700 is used for the price of goods, products, and services.See the following examples: 1) Natural price; 2) Market price; 3) Unitprice; 4) Total price; and 5) Recommended price.

(mmmmmm) PriceComponent

A GDT PriceComponent 17800 is a non-fiscal part of a price that wascalculated for the quantity of a product. An example is:<PriceComponent >  <TypeCode>0001</TypeCode >  <DescriptionlanguageCode=“EN”>Product Base Price</Description >  <AmountcurrencyCode=“EUR”>250</Amount> </PriceComponent > <PriceComponent > <TypeCode>0004</TypeCode >  <Description languageCode=“EN”>CustomerDiscount</Description >  <BaseAmount currencyCode=“EUR”>250</BaseAmount> <Percent>5</Percent>  <Amount currencyCode=“EUR”>12.5</Amount></PriceComponent >

The structure of GDT PriceComponent 17800 is depicted in FIG. 178. TheGDT PriceComponent 17800 includes elements TypeCode 17808, Description17826, BaseAmount 17842, Percent 17858, and Amount 17874. For the GDTPriceComponent 17800, the Category is Complex 17802, the Object Class isPriceComponent 17804, and the Representation/Association term is Details17806.

The TypeCode 17808 is the coded representation of a type of pricecomponent according to GDT PriceComponentTypeCode. For the TypeCode17808, the Category is Element 17810, the Object Class is PriceComponent17812, the Property is Type Code 17814, the Representation/Associationterm is Code 17816, the Type term is GDT 17818, the Type Name term isPriceComponentTypeCode 17820, and the Length is four 17822. TheCardinality between the GDT PriceComponent 17800 and the TypeCode 17808is one 17824.

The Description 17826 is additional natural language information onprice component, which may be optional. For the Description 17826, theCategory is Element 17828, the Object Class is PriceComponent 17830, theProperty is Description 17832, the Representation/Association term isText 17834, the Type term is GDT 17836, and the Type Name term isDescription 17838. The Cardinality between the GDT PriceComponent 17800and the Description 17826 is zero or one 17840.

The BaseAmount 17842 is the base amount from which a price component iscalculated using a percentage, which may be optional. For the BaseAmount17842, the Category is Element 17844, the Object Class is PriceComponent17846, the Property is Base Amount 17848, the Representation/Associationterm is Amount 17850, the Type term is GDT 17852, and the Type Name termis Amount 17854. The Cardinality between the GDT PriceComponent 17800and the BaseAmount 17842 is zero or one 17856.

The Percent 17858 is the percentage which is used to calculate a pricecomponent from a base amount, which may be optional. For the Percent17858, the Category is Element 17860, the Object Class is PriceComponent17862, the Property is Percent 17864, the Representation/Associationterm is Percent 17866, the Type term is GDT 17868, and the Type Nameterm is Percent 17870. The Cardinality between the GDT PriceComponent17800 and the Percent 17858 is zero or one 17872.

The Amount 17874 is the amount of a price component. For the Amount17874, the Category is Element 17876, the Object Class is PriceComponent17878, the Property is Amount 17880, the Representation/Association termis Amount 17882, the Type term is GDT 17884, and the Type Name term isAmount 17886. The Cardinality between the GDT PriceComponent 17800 andthe Amount 17874 is one 17888.

If GDT PriceComponents 17800 are specified for a quantity of a product,the PriceComponentTypeCode for the base price may be used once here. Thetwo optional elements BaseAmount and Percent may either both bespecified or not specified in each instance of PriceComponent. Manualchanges to a percentage price component for the quantity of a product inthe original document lead to the value calculated from the elementsBaseAmount and Percent varying from the content of the element Amount.The element BaseAmount always has a non-negative value. The elementsPercent and Amount can both be either positive or negative at the sametime, e.g., to express a surcharge or discount.

The GDT PriceComponent 17800 is used to make the net price specified orto be specified in an invoice for an ordered or delivered quantity ofproducts comprehensible by specifying price components. Therefore, itmay be used in invoice items. Results of price calculations arepreferably transmitted, not the exact calculation method, which can becomplex due to, e.g., proprietary Customizings, user exits in the formof coding, scales, rounding difference clearing, price date or referencesteps. Therefore, the GDT can be used for automated control ofcalculation results using a recipient system in a limited way (e.g.,invoice verification). Different types of price components may berepresented by “condition types” which are defined in customer-specificCustomizing.

(nnnnnn) PriceComponentTypeCode

The GDT PriceComponentTypeCode 17900 is the coded representation of anon-fiscal price element type that was calculated for the quantity of aproduct. An example is:

<PriceComponentTypeCode>0001</PriceComponentTypeCode>.

The structure of GDT PriceComponentTypeCode 17900 is depicted in FIG.179.

The possible illustrative values of the PriceComponentTypeCode are:

1) Code 0001, which represents a Base Price, for example, for a pricefrom a price list calculated as (quantity * unit price) or (weight *price per kg);

2) Code 0002, which represents a surcharge or discount based on aspecial product configuration, for example, a surcharge for the color‘red’, surcharge for size “XL,” discount for smaller model;

3) Code 0003, which represents a surcharge or discount based on salespromotion over a limited period of time, for example, a Christmasdiscount, Easter sale, summer surcharge;

4) Code 0004, which represents a surcharge or discount based on specialgroup membership; typically a product belonging to a product group, thecustomer belonging to a customer group, or a combination of both, forexample, an OEM surcharge for a product, corporate customer discount;

5) Code 0005, which represents a surcharge or discount for a quantity ofthe product based on a special agreement made when the order was takenor at the acquisition of the sales contract (manual entries);

6) Code 0006, which represents a surcharge or discount for a total orderbased on a special agreement made when the order was taken or at theacquisition of the sales contract (manual entries);

7) Code 0007, which represents a surcharge or discount for a quantity ofthe product based on deviations from standard business processing, forexample, a minimum price, pallet discount, surcharge for incompletepallet, mixed pallet discount, surcharge for incomplete mixed pallet,free-goods discount;

8) Code 0008, which represents a surcharge or discount for a total orderbased on deviations from standard business processing, for example, aminimum sales order value, minimum value surcharge;

9) Code 0009, which represents a surcharge or discount for a quantity ofthe product based on special calculation processing, for example, a 100%discount, rounding difference;

10) Code 0010, which represents a shipment costs/packaging/customs for aquantity of the product;

11) Code 0011, which represents a shipment costs/packaging/customs for atotal order;

12) code 0012, which represents a cash discount.

The GDT PriceComponentTypeCode 17900 may be a proprietary code list withfixed predefined values. Changes to the permitted values involve changesto the interface. In a variation, related standardized code lists suchas Price.Type.Code (UN/CEFACT 5375) or Price.Specification.Code(UN/CEFACT 5387) may not be used, since they contain a differentsemantic that is also worked out at a much greater level of detail. Inthe first case, e.g., the classifying of prices into different typesaccording to special information for the quantity of products takes up alarge amount of space. In the second case, however, the businesscircumstances determining the prices take up more space. For the GDTPrice Component Type Code 17900, the Object Class is Price Component17902, the Property is Type Code 17904, the Representation/Associationterm is Code 17906, the Type term is CCT 17908, the Type Name term isCode 17910, and the Length is four 17912.

(oooooo) PriceTimeSeries

A CDT PriceTimeSeries 18000 is time series information that consists ofitems that each contain a period with a start time and end time and aperiod-based price. An example is: <PriceTimeSeries>  <Item>  <ValidityPeriod>   <StartDateTime>2002-04-19T15:00:00Z</StartDateTime>  <EndDateTime>2002-04-19T17:00:00Z</EndDateTime>   </ValidityPeriod>  <Price>    <Amount currencyCode=“EUR”>32.14</Amount>    <BaseQuantityunitCode=“C62”>1</BaseQuantity>   </Price>  </Item> </PriceTimeSeries>.

The structure of CDT PriceTimeSeries 18000 is depicted in FIG. 180. TheCDT PriceTimeSeries 18000 includes elements Item 18014, Validity-Period18026, Price 18040, and Fixed-Indicator 18054. For the CDTPriceTimeSeries 18000, the Object Class Qual. term is Price 18002, theObject Class is TimeSeries 18004, the Representation/Association term isDetails 18006, the Type term is GDT 18008, the Type Name term isTimeSeries 18010. The CDT PriceTimeSeries 18000 may be a restricted CDT18012.

The PriceTimeSeriesItem 18014 is an item in a time series and can berepeated as often as required. For the Item 18014, the Category isElement 18016, the Object Class is TimeSeries 18018, the Property isItem 18020, and the Representation/Association term is Details 18022.The Cardinality between the CDT PriceTimeSeries 18000 and the Item 18014is from one to n 18024. The ValidityPeriod 18026 describes the validityperiod of the time series item with a start time stamp and an end timestamp. For the Validity-Period 18026, the Category is Element 18028, theObject Class is TimeSeries 18030, the Property is ValidityPeriod 18032,the Representation/Association term is Details 18034, the Type term is18036, and the Type Name term is DateTimePeriod 18038. The Cardinalitybetween the CDT PriceTimeSeries 18000 and the Validity-Period 18026 isone 18040.

The Price 18040 describes the price connected to the time series item.For the Price 18040, the Category is Element 18042, the Object Class isTimeSeries 18042, the Property is Price 18044, theRepresentation/Association term is Price 18046, the Type term is GDT18048, and the Type Name term is Price 18050. The Cardinality betweenthe CDT PriceTimeSeries 18000 and the Price 18040 is one 18052. TheFixedIndicator 18054 describes whether the corresponding item forchanges is blocked or not. For the Fixed-Indicator 18054, the Categoryis Element 18056, the Object Class is TimeSeries 18058, the Property isFixedIndicator 18060, the Representation/Association term is Indicator18062, the Type term is GDT 18064, and the Type Name term is FixedIndicator 18066. The Cardinality between the CDT PriceTimeSeries 18000and the Fixed-Indicator 18054 is zero or one 18068.

The CDT PriceTimeSeries 18000 is used as a generic data type that canhave various specifications in one interface, depending on the contextcategory being used.

(pppppp) ProcurementCostUpperLimit

A GDT ProcurementCostUpperLimit 18100 is the cost upper limit fordifferent types of procurement costs. An example is:<ProcurementCostUpperLimit>  <OverallLimit>   <AmountcurrencyCode=“EUR”>10000.00</Amount>  <AmountUnlimitedIndicator>false</AmountUnlimitedIndicator>  <ExpectedAmount currencyCode=“EUR”>7500.00</   ExpectedAmount> <OverallLimit>  <ContractPartialLimit>   <AmountcurrencyCode=“EUR”>0.00</Amount>  <AmountUnlimitedIndicator>true</AmountUnlimitedIndicator>  <ContractReference>    <ID>4000008599</ID>    <ItemID>148</ItemID>  </ContractReference>  </ContractPartialLimit> <MiscellaneousPartialLimit>   <AmountcurrencyCode=“EUR”>500.00</Amount>  <AmountUnlimitedIndicator>false</AmountUnlimitedIndicator> </MiscellaneousPartialLimit> </ProcurementCostUpperLimit>.

The structure of GDT ProcurementCostUpperLimit 18100 is depicted in FIG.181. The GDT Procurement Cost Upper Limit 18100 includes elementsOverallLimit 18108, Amount 18120, Amount Unlimited Indicator 18134,Expected Amount 18150, Contract Partial Limit 18166, Amount 18178,Amount Unlimited Indicator 18194, ContractReference 181110,Miscellaneous Partial Limit 181126, Amount 181138, and Amount UnlimitedIndicator 181154. For the GDT Procurement Cost Upper Limit 18100, theObject Class is Procurement Cost 18102, the Property is Upper Limit18104, and the Representation/Association term is Details 18106.

The OverallLimit 18108 is the limit for the total costs in a procurementprocess. For the OverallLimit 18108, the Category is Element 18110, theObject Class is Procurement Cost Upper Limit 18112, the Property isOverall Limit 18114, and the Representation/Association term is Details18116. The Cardinality between the GDT Procurement Cost Upper Limit18100 and the OverallLimit 18108 is one 18118.

The OverallLimit/Amount 18120 is the cost upper limit that may not beexceeded in a procurement process. For the Amount 18120, the Category isElement 18122, the Object Class is Overall Limit 18124, the Property isAmount 18124, the Representation/Association term is Amount 18126, theType term is GDT 18128, and the Type Name term is Amount 18130. TheCardinality between the GDT Procurement Cost Upper Limit 18100 and theAmount 18120 is zero or one 18132.

The OverallLimit/AmountUnlimitedIndicator 18134 indicates whether theamount in OverallLimit/Amount is unlimited. For the Amount UnlimitedIndicator 18134, the Category is Element 18136, the Object Class isOverall Limit 18138, the Property is Amount Unlimited Indicator 18140,the Representation/Association term is Indicator 18142, the Type term isGDT 18144, and the Type Name term is ValueUnlimitedIndicator 18146. TheCardinality between the GDT Procurement Cost Upper Limit 18100 and theAmount Unlimited Indicator 18134 is zero or one 18148.

The OverallLimit/ExpectedAmount 18150 is the costs that are expected.The expected costs may be less than the maximum permitted costs. For theExpected Amount 18150, the Category is Element 18152, the Object Classis 18154, the Property is Expected Amount 18156, theRepresentation/Association term is Amount 18158, the Type term is GDT18160, and the Type Name term is Amount 18162. The Cardinality betweenthe GDT Procurement Cost Upper Limit 18100 and the Expected Amount 18150is zero or one 18164.

The ContractPartialLimit 18166 is the partial limit for costs relatingto a contract. For the Contract Partial Limit 18166, the Category isElement 18168, the Object Class is Procurement Cost Upper Limit 18170,the Property is Contract Partial Limit 18172, and theRepresentation/Association term is Details 18174. The Cardinalitybetween the GDT Procurement Cost Upper Limit 18100 and the ContractPartial Limit 18166 is from zero to n 18176.

The ContractPartialLimit/Amount 18178 is the cost upper limit for aparticular contract that may not be exceeded in a procurement process.For the Amount 18178, the Category is Element 18180, the Object Class isContract PartialLimit 18182, the Property is Amount 18184, theRepresentation/Association term is Amount 18186, the Type term is GDT18188, and the Type Name term is Amount 18190. The Cardinality betweenthe GDT Procurement Cost Upper Limit 18100 and the Amount 18178 is zeroor one 18192.

The ContractPartialLimit/AmountUnlimitedIndicator 18194 indicateswhether the amount in ContractLimit/Amount is unlimited. For the AmountUnlimited Indicator 18194, the Category is Element 18196, the ObjectClass is Contract PartialLimit 18198, the Property is Amount UnlimitedIndicator 181100, the Representation/Association term is Indicator181102, the Type term is GDT 181104, and the Type Name term isValueUnlimitedIndicator 181106. The Cardinality between the GDTProcurement Cost Upper Limit 18100, and the Amount Unlimited Indicator18194 is zero or one 181108.

The ContractPartialLimit/ContractReference 181110 is the reference to acontract. For the ContractReference 181110, the Category is Element181112, the Object Class is Contract PartialLimit 181114, the Propertyis Contract Reference 181116, the Representation/Association term isBusiness Transaction Document Reference 181118, the Type term is GDT181120, and the Type Name is Business Transaction Document Reference181122. The Cardinality between the GDT Procurement Cost Upper Limit18100 and the ContractReference 181110 is one 181124. TheContractPartialLimit/ContractReference/ID 181126 is the contract number.The ContractPartialLimit/ContractReference/ItemID an item within thecontract. If no item number is specified, the partial limit applies forall the items in the contract.

The MiscellaneousPartialLimit 181126 is the partial limit for theoverall limit for miscellaneous costs. For the Miscellaneous PartialLimit 181126, the Category is Element 181128, the Object Class isProcurement Cost Upper Limit 181130, the Property is MiscellaneousPartialLimit 181132, and the Representation/Association term is Details181134. The Cardinality between the GDT Procurement Cost Upper Limit18100 and the Miscellaneous Partial Limit 181126 is zero or one 181136.

The MiscellaneousPartialLimit/Amount 181138 is the cost upper limit formiscellaneous costs. For the Amount 181138, the Category is Element181140, the Object Class is Miscellaneous PartialLimit 181142, theProperty is Amount 181144, the Representation/Association term is181146, the Type term is GDT 181148, and the Type Name is Amount 181150.The Cardinality between the GDT Procurement Cost Upper Limit 18100 andthe Amount 181138 is zero or one 181152.

The MiscellaneousPartialLimit/AmountUnlimitedIndicator 181154 indicateswhether the amount in MiscellaneousLimit/Amount is unlimited. For theAmount Unlimited Indicator 181154, the Category is Element 181156, theObject Class is Miscellaneous PartialLimit 181158, the Property isAmount Unlimited Indicator 181160, the Representation/Association termis Indicator 181162, the Type term is GDT 181164, and the Type Name termis ValueUnlimitedIndicator 181181. The Cardinality between the GDTProcurement Cost Upper Limit 18100 and the Amount Unlimited Indicator181154 is zero or one 181168.

The rules for the GDT AmountUnlimitedIndicator apply for Amount andAmountUnlimitedIndicator. Currencies within a ProcurementCostUpperLimitmay be identical. The OverallLimit/Amount may be greater than or equalto the OverallLimit/ExpectedAmount. If no ExpectedAmount is specified,the Amount is used as the ExpectedAmount. If no ExpectedAmount isspecified and the Amount is unlimited, an ExpectedAmount of 0.00 isassumed. In a variation, the same contract/same contract item may not bereferenced in different limits which refer to contracts.

A ProcurementCostUpperLimit is used to define the type and amount ofcosts that are permitted for limit items within an ordering process.Limit items are used as placeholders in purchase orders if therequirements are unknown at the time of ordering. This can be the case,e.g., for repairs, where the time and spare parts required are not knownuntil the repair has been made.

Regarding the costs in a procurement process and the limits, the totalof all the costs may not exceed the overall limit, though the total ofall the partial limits may well exceed the overall limit. This can leadto mistakes, for example: 1) Overall limit of EUR 10,000; 2) Partiallimit of EUR 8,000 for contract 4711; and 3) Miscellaneous partial limitof EUR 4,000. The total of the partial limits is EUR 12,000, which isgreater than the overall limit of EUR 10,000. This makes sense whencosts of EUR 8,000 and miscellaneous costs of EUR 3,000 (=total costs ofEUR 11,000) are to be identified as too high for contract 4711.

(qqqqqq) ProductCategoryID

A GDT ProductCategoryID 18200 is a unique identifier for a productcategory. A product category is a division of products according toobjective business-specific criteria. An example or instance is:

1. Reference to a category using a standard ID: <ProductCategoryIDschemeID=“eClass” schemeAgencyID=“ZZZ”>AAA650001</ProductCategoryID>

2. Reference to a category using a version-dependent, hierarchicalstandard ID: <ProductCategoryID schemeID=“UNSPSC” schemeVersionID=“11.0” schemeAgencyID=“257”>10.10.15.17.00</ProductCategoryID>

3. Reference to a category using a proprietary ID: <ProductCategoryIDschemeID=‘ProductCategories’ schemeAgencyID=‘123456789’schemeAgencySchemeAgencyID=‘16’>0006</ ProductCategoryID >

The structure of GDT ProductCategoryID 18200 is depicted in FIG. 182.The GDT ProductCategoryID 18200 is from the Core Component TypeIdentifier. The GDT ProductCategoryID 18200 includes attributes schemeID18216, SchemeVersionID 18238, schemeAgencyID 18256, schemeAgencySchemeID18274, and schemeAgencySchemeAgencyID 18292. For the GDTProductCategoryID 18200, the Object Class is ProductCategory 18202, theProperty is Identification 18204, the Representation/Association term isIdentifier 18206, the Type term is CCT 18208, the Type Name term isIdentifier 18210, and the Length is from one to forty 18212. The GDTProductCategoryID 18200 may be a restricted GDT.

The following classifications are supported for standard IDs: 1)schemeID 18216 of ‘UNSPSC’; 2) schemeAgencyID 18256 of ‘257’; 3)schemeID of ‘eClass’; and 4) schemeAgencyID of ‘ZZZ’. The followingclassifications are supported for version-dependent, hierarchicalstandard IDs: 1) schemeID of ‘UNSPSC’; 2) schemeVersionID of nn.m; 3)schemeAgencyID of ‘257’; 4) schemeID of ‘eClass’; 5) schemeVersionID:nn.m; and 6) schemeAgencyID: ‘ZZZ’. For the schemeID 18216, the Categoryis Attribute 18218, the Object Class is IdentificationScheme 18220, theProperty is Identification 18222, the Representation/Association term isIdentifier 18228, the Type term is xsd 18230, the Type Name term isToken 18232, and the Length is from one to sixty 18234. The Cardinalitybetween the GDT ProductCategoryID 18200 and the schemeID 18216 is zeroor one 18236.

For the SchemeVersionID 18238, the Category is Attribute 18240, theObject Class is IdentificationScheme 18242, the Property is Version18244, the Representation/Association term is Identifier 18246, the Typeterm is xsd 18248, the Type Name term is Token 18250, and the Length isfrom one to fifteen 18252. The Cardinality between the GDTProductCategoryID 18200 and the SchemeVersionID 18238 is zero or one18254.

For the schemeAgencyID 18256, the Category is Attribute 18258, theObject Class is IdentificationSchemeAgency 18260, the Property isIdentification 18262, the Representation/Association term is Identifier18264, the Type term is xsd 18266, the Type Name term is Token 18268,and the Length is from one to sixty 18270. The Cardinality between theGDT ProductCategoryID 18200 and the schemeAgencyID 18256 is zero or one18272.

For the schemeAgencySchemeID 18274, the Category is Attribute 18276, theObject Class is IdentificationSchemeAgency 18278, the Property is Scheme18280, the Representation/Association term is Identifier 18282, the Typeterm is xsd 18284, the Type Name term is Token 18286, and the Length isfrom one to sixty 18288. The Cardinality between the GDTProductCategoryID 18200 and the schemeAgencySchemeID 18274 is zero orone 18290.

For the schemeAgencySchemeAgencyID 18292, the Category is Attribute18294, the Object Class is IdentificationSchemeAgency 18296, theProperty is SchemeAgency 18298, the Representation/Association term isIdentifier 18201, the Type term is xsd 18203, the Type Name term isToken 18205, and the Length is three 18207. The Cardinality between theGDT ProductCategoryID 18200 and the schemeAgencySchemeAgencyID 18292 iszero or one 18209.

Product CategoryID can be used, for example, in three ways:

1) For identifying a product category using a globally-unique,non-versioned, standardized ID. The ID is generally not structuredhierarchically, i.e., it references one product category and does notcontain information about how this category is based on several othergeneral categories. The attribute schemeID and schemeAgencyID are usedin the same way as planned in the CCT identifier for standard IDs. Otherattributes are not specified.

2) For identifying a product category within a tree of productcategories that build on one another and using a globally unique,standardized ID that contains information on the location of thecategory within the tree structure. The ID is generallyversion-dependent. The attribute schemeID and schemeVersionID andschemeAgencyID are used in the same way as planned in the CCT identifierfor standard IDs. Other attributes are not specified.

3) For identifying a product category using a proprietary ID. Theattributes schemeID, schemeAgencyID, schemeAgencySchemeID andschemeAgencySchemeAgencyID are used as planned for the CCT identifier inorder to define the context for which a CategoryPartyID is guaranteed tobe unique. Other attributes are not specified.

(rrrrrr) ProductCategoryInternalID

A CDT ProductCategoryInternalID 18300 is a proprietary identifier for aproduct category. A product category is a division of products accordingto objective criteria. Illustrative examples ofProductCategoryInternalID (SAP MDM) are:

The GUID of a product category:  <ProductCategoryInternalIDschemeID=“ProductCategoryGUID” schemeAgencyID=“MPL_002”> 1C743CEC501F6A4D8826C7EC5A8554B9</  ProductCategoryInternalID> schemeID=“ProductCategoryGUID” indicates that the scheme“ProductCategoryGUID” was used to identify the product category. schemeAgencyID=“MPL_002” indicates that the scheme was assigned by thebusiness system “MPL_002.”

ProductCategoryID of a product category:   <ProductCategoryInternalIDschemeID=“ProductCategoryID” schemeAgencyID=“MPL_002”>Private CarVehicles MPLCNT002</ProductCategoryInternalID>

The structure of CDT ProductCategoryInternalID 18300 is depicted in FIG.183. The CDT ProductCategoryInternalID 18300 includes attributesschemeID 18316 and schemeAgencyID 18334. For the CDTProductCategoryInternalID 18300, the Object Class is ProductCategory18302, the Property is Internal Identification 18304, theRepresentation/Association term is Identifier 18306, the Type term isGDT 18308, the Type Name term is ProductCategoryID 18310, and the Lengthis from one to forty 18312. The CDT ProductCategoryInternalID 18300 maybe a restricted CDT.

The attributes of a CDT ProductCategoryInternalID 18300 are filled, forexample, as follows in SAP MDM:

1) The schemeID 18316, in which the following schemes are provided for:

1) The ProductCategoryGUID, which identifies a product category using aGlobal Unique Identifier, and

2) The ProductCategoryID, which identifies a product category using anidentifier.

For the schemeID 18316, the Category is Attribute 18318, the ObjectClass is IdentificationScheme 18320, the Property is Identification18322, the Representation/Association term is Identifier 18324, the Typeterm is xsd 18326, the Type Name term is Token 18328, and the Length isfrom one to sixty 18330. The Cardinality between the CDTProductCategoryInternalID 18300 and the schemeID 18316 is zero or one18332.

2) The schemeAgencyID 18334 for a Business system in which the numberwas assigned. For the schemeAgencyID 18334, the Category is Attribute18336, the Object Class is IdentificationSchemeAgency 18338, theProperty is Identification 18340, the Representation/Association term isIdentifier 18342, the Type term is xsd 18344, the Type Name term isToken 18346, and the Length is from one to sixty 18348. The Cardinalitybetween the CDT ProductCategoryInternalID 18300 and the schemeAgencyID18334 is zero or one 18350.

The GDT ProductCategoryInternalID 18300 represents a projection of theGDT ProductCategoryID, in which the attributes schemeID andschemeAgencyID are contained for describing an internally assigned ID.If an attribute is not explicitly assigned in the use of the GDT, it maybe determined through the context.

The ProductCategoryInternalID 18300 is used when both sender andrecipient can access shared master data, e.g., during internalcommunication.

If the product category is identified using the ProductCategoryID scheme(schemeID), the product category may be uniquely identified using acombined key (e.g., the product category at an entity level can beuniquely identified (semantically) using ProductCategoryID,ProductHierarchyID and the logical system).

(ssssss) ProductCategoryPartyID

A CDT ProductCategoryPartyID 18400 is an identifier for a productcategory assigned by a party. A product category is a division ofproducts according to objective criteria. An example is:<ProductCategorySellerID>0006</ProductCategorySellerID>.

The structure of CDT ProductCategoryPartyID 18400 is depicted in FIG.184.

The CDT ProductCategoryPartyID 18400 is the proprietary identifierassigned by a party. The party (in its role) that assigned thisidentifier may derive from the business context of the message that usesthe CDT ProductCategoryPartyID 18400. For the CDT Product Category PartyID 18400, the Object Class is Product Category 18402, the PropertyQuality term is Party 18404, the Property is Identification 18406, theRepresentation/Association term is Identifier 18408, the Type term isGDT 18410, the Type Name term is ProductCategoryID 18412, and the Lengthis from one to forty 18414. The CDT Product Category Party ID 18400 maybe a restricted CDT 18416.

In contrast to CDT ProductCategoryStandardID 18500, the use of the CDTProductCategoryPartyID 18400 is role-dependent (e.g., as an ID assignedby the Buyer).

The party is specified by its role. The Party is replaced with thepartner role type (e.g., ProductCategorySellerID). SchemeID andSchemeVersionID are to be included as attributes as soon as there is aneed to differentiate between several schemes. (See GDTProductCategoryID).

(tttttt) ProductCategoryStandardID

A CDT ProductCategoryStandardID 18500 is a standardized identifier for aproduct category, whereby the identification scheme used may be managedby an agency from the code list DE 3055. A product category is adivision of products according to objective criteria. An example is:

<ProductCategoryStandardID schemeID=“UNSPSC” schemeVersionID=“11.0”

schemeAgencyID=“113”>10.10.15.17</ProductCategoryStandardID>

The structure of CDT ProductCategoryStandardID 18500 is depicted in FIG.185. The CDT Product Category Standard ID 18500 includes attributesschemeID 18518, SchemeVersionID 18536, and schemeAgencyID 18554. For theCDT Product Category Standard ID 18500, the Object Class is ProductCategory 18502, the Property Qual. is Standard 18504, the Property isIdentification 18506, the Representation/Association term is Identifier18508, the Type term is GDT 18510, the Type Name is ProductCategoryID18512, and the Length is from one to forty 18514. The CDT ProductCategory Standard ID 18500 may be a restricted CDT 18516.

For the schemeID 18518, the Category is Attribute 18520, the ObjectClass is IdentificationScheme 18522, the Property is Identification18524, the Representation/Association term is Identifier 18526, the Typeterm is xsd 18528, the Type Name term is Token 18530, and the Length isfrom one to sixty 18532. The Cardinality between the CDT ProductCategory Standard ID 18500 and the scheme ID 18518 is zero or one 18534.

For the SchemeVersionID 18536, the Category is Attribute 18538, theObject Class is IdentificationScheme 18540, the Property is Version18542, the Representation/Association term is Identifier 18544, the Typeterm is xsd 18546, the Type Name term is Token 18548, and the Length isfrom one to fifteen 18550. The Cardinality between CDT Product CategoryStandard ID 18500 and the SchemeVersionID 18536 is zero or one 18552.

The schemeAgencyID 18554 identifies the agency that manages anidentification scheme. The agencies from DE 3055 are used as thedefault, but the roles defined in DE 3055 cannot be used. For theschemeAgencyID 18554, the Category is Attribute 18556, the Object Classis IdentificationSchemeAgency 18558, the Property is Identification18560, the Representation/Association term is Identifier 18562, the Typeterm is xsd 18564, the Type Name term is Token 18566, and the Length isthree 18568. The Cardinality between CDT Product Category Standard ID18500 and the schemeAgencyID 18554 is one 18570. The followingillustrative code is supported for a version-dependent hierarchicalstandard ID:

-   -   1) SchemeAgencyID=“113”—UCC (Uniform Code Council) with 1)        SchemeID=“UNSPSC” (United Nations Standard Product and Services        Classification Code); and 2) SchemeVersionID=nn.m (e.g. 11.0).

The GDT ProductCategoryStandardID 18500 represents a projection of theGDT ProductCategoryID, in which the attributes schemeID,schemeVersionID, and schemeAgencyID are contained for describing an IDassigned by a standardization organization (i.e., an organizationregistered in the DE 3055). The attribute schemeAgencyID may be amandatory attribute.

In contrast to ProductCategoryPartyID, the use ofProductCategoryStandardID may not be role-dependent.

The SchemeID is another standardized identification scheme (for materialclassification and material groups) is “eClass” (current release status5.0). The German Institute for Economics in Cologne provides theclassification as an independent platform and central point of contact,free of charge, in the Internet under www.eClass.de (For thespecification seewww.eclass.de/informationen/download/eclassMerkmalleisten5_(—)00.doc).

The version of eClass is a 2-digit number.

Illustrative usages of the SchemeID include: 1) SchemeAgencyID for theGerman Institute for Economics Cologne (not contained in DE 3055),wherein the SchemeID equals “eClass,” and the SchemeVersionID equals nn(e.g. 42). If necessary, the SchemeID ETIM (www.etim.de) can also beexamined for its applicability. (See also GDT ProductCategoryID).

(uuuuuu) ProductChangeID

A GDT ProductChangeID 18600 is a unique identifier for a change to aproduct which leaves the product unchanged in terms of its propertiesthat are relevant for the user. Changes in terms of this definition mayoccur, e.g., due to changed manufacturing processes or the use of othermodules/component batches. An example is:

<ProductChangeID>31337KSK/4711</ProductChangeID>.

The structure of GDT ProductChangeID 18600 is depicted in FIG. 186. Forthe GDT ProductChangeID 18600, the Category is Element 18602, the ObjectClass is Product Change 18604, the Property is Identification 18606, theRepresentation/Association term is Identifier 18608, the Type term isCCT 18610, the Type Name term is Identifier 18612, and the Length isfrom one to thirty-two 18614. The GDT ProductChangeID 18600 may be arestricted GDT.

ProductChangeIDs may be used, e.g., for a recall activity: Assuming thetransistors installed in a product are replaced with other similar ones,then the features of the product are not changed and it should stillhave the same ProductID. However, if the transistors turn out to befaulty, it may be ensured that the serial numbers of the productaffected are logged using ProductChangeIDs in case there is a resultingrecall activity. If a change is made using change management, theProductChangeID as a rule contains the ID of the relevant change order(ChangeOrderID).

In an example, in the R/3, GDT ProductChangeID 18600 is the changenumber that uniquely identifies a change master record for a product. Achange identified here is neither a version nor a variant. For example,A yellow VW Golf C with leather seats would be “yellow with leatherseats,” a variant of version “C” of product “VW Golf.”

(vvvvvv) ProductDemandInfluencingEventStatusCode

The GDT ProductDemandInfluencingEventStatusCode 18700 is a codedrepresentation for the status of an event that influences the demand forproducts. The event might be, e.g., a promotional event. An example is:

<ProductDemandInfluencingEventStatusCode>PLANNED</ProductDemandInfluencingEventStatusCode>.

The structure of GDT ProductDemandInfluencingEventStatusCode 18700 isdepicted in FIG. 187. For the GDT Product Demand Influencing EventStatus Code 18700, the Object Class is Product Demand Influencing Event18702, the Property is Status 18704, the Representation/Association termis Code 18706, the Type term is CCT 18708, the Type Name term is Code18710, and the Length is from one to thirty-five 18712. The GDT ProductDemand Influencing Event Status Code 18700 may be a restricted GDT.

The possible code values are a subset of the “Retail Event Status CodeList” of the “EAN.UCC XML Business Message Standards, Version 1.3 (July2003).” These are: 1) CANCELED; 2) COMPLETED; 3) PLANNED; 4) PROPOSED;and 5) TERMINATED.

(wwwwww) ProductDemandInfluencingEventTypeCode

The GDT ProductDemandInfluencingEventTypeCode 18800 is a codedrepresentation for the type of an event that influences the demand forproducts. An example is:

<ProductDemandInfluencingEventTypeCode>HOLIDAY</ProductDemandInfluencingEventTypeCode>.

The structure of GDT ProductDemandInfluencingEventTypeCode 18800 isdepicted in FIG. 188. For the GDT Product Demand Influencing Event TypeCode 18800, the Object Class is Product Demand Influencing Event 18802,the Property is Type 18804, the Representation/Association term is Code18806, the Type term is CCT 18808, the Type Name term is Code 18810, andthe Length is from one to thirty-five 18812. The GDT Product DemandInfluencing Event Type Code 18800 may be a restricted GDT.

The GDT groups several partial quantities of standard code lists,whereby the supported partial quantities are disjunctive. Therefore noattributes, or supplementary components, are needed to identify therelevant standard code list.

The illustrative code values may be subsets of the union of the“Miscellaneous Event Type Code List” and “Promotional Event Type CodeList” of the “EAN.UCC XML Business Message Standards, version 1.3 (July2003).” These are: (From the “Miscellaneous Event Type Code List”): 1)The code ASSORTMENT_CHANGE is used when the set of items that thelocation carries for this category is changing, affecting one or moreitems; 2) The code DISASTER is used when a hurricane, tornado, accident,attack, or some other catastrophic, unexpected event affecting supply ordemand; 3) The code FREIGHT_FLOW_ALLOCATION is used when an itemavailability may be restricted, due to unexpected demand, transportationissues, production problems, or some other reason; 4) The codeINVENTORY_POLICY_CHANGE is used when the inventory policy at the storeor retail distribution center is changing, resulting in changes to theestimated supply of the item; 5) The code LABOR is used when a strike orother labor issue affects supply; 6) The code LOCATION_CLOSING is usedwhen one or more locations that carry the item are closing. No promotionis associated with the item during the closing; 7) The codeLOCATION_OPENING is used when one or more new locations is opening thatwill carry the item. No promotion is associated with the item during theopening; 8) The code PACKAGING_LABELING_CHANGE is used when thepackaging or labeling of the item is changing, possibly affecting demandor distribution; 9) The code PRICE_DECREASE is used when the price isdecreasing for the item at the retail location(s); 10) The codePRICE_INCREASE is used when the price is increasing for the item at theretail location(s); 11) The code STORE_FORMAT_OR_PLANOGRAM_CHANGE isused when the store format or planogram is changing, affecting one ormore items; 12) The code TEST_MARKET is used when selling a new item ata limited set of locations to gauge consumer interest, or testing anexisting item in a new channel or location; and 13) The code WEATHER isused when a heat wave, cold front, snow storm, or other weatherphenomenon affecting supply or demand. (From the “Promotional Event TypeCode List”): 1) The code COMMUNITY EVENT is used when a promotionalactivity timed to coincide with a local, regional, or national event(charity drive, Indy 500, Grammy Awards); 2) The code HOLIDAY is usedwhen a promotional activity timed to coincide with a national, regional,or religious holiday; 3) The code SEASONAL_EVENT is used when apromotional activity timed to coincide with a change in the season, oran annual cultural phenomenon (such as “back to school”); 4) The codeSTORE_CLOSING is used when a promotional activity timed to coincide withthe elimination of one or more store locations (e.g.going-out-of-business sale); 5) The code STORE_OPENING is used when apromotional activity timed to coincide with the opening of one or morenew store locations (e.g. grand opening sale); 6) The codeTRADE_ITEM_DISCONTINUATION is used when a promotional activity timed tocoincide with the elimination of a product from a location or market(e.g. clearance sale); and 7) The code TRADE_ITEM_INTRODUCTION is usedwhen a promotional activity timed to coincide with the introduction of anew product to a location or market

(xxxxxx) ProductDiscontinuationIndicator

A GDT ProductDiscontinuationIndicator 18900 indicates whether a productis to be discontinued, i.e., removed from the product line, or not. Anexample,<ProductDiscontinuationIndicator>true</ProductDiscontinuationIndicator>.

The structure of GDT ProductDiscontinuationIndicator 18900 is depictedin FIG. 189. For the GDT ProductDiscontinuationIndicator 18900, theObject Class is Product 18902, the Property is Discontinuation 18904,the Representation/Association term is Indicator 18906, the Type term isCCT 18908, and the Type Name term is Indicator 18910. Valid values for18900 are: 1) true, meaning that the product is discontinued; or 2)false, meaning that the product is not discontinued. (See CCT: Indicatorfor the value range).

(yyyyyy) ProductID

A GDT ProductID 19000 is a unique identifier for a product. A product iseither a tangible or intangible good, and is a part of the businessactivities of a company. It can be traded and contributes directly orindirectly to value added. An example and instance is:

(a) Proprietary ID, Standard Agency   <ProductID schemeID=“DomesticAppliances”       schemeAgencyID=“065055766”        schemeAgencySchemeID=“DUNS”        schemeAgencySchemeAgencyID=“016”>     B 1165 HS   </ProductID>065055766 = Bosch at DUNS 016 = DUNS from Code List DE 3055

The structure of GDT ProductID 19000 is depicted in FIG. 190. ProductIDconnotes the type of product, instead of a concrete object. Thus, in theabove example: B1165HS means a type of appliance, not an actualappliance with the serial number XY. The GDT ProductID 19000 includesattributes schemeID 19016, the schemeAgencyID 19034,schemeAgencySchemeID 19052, and schemeAgencySchemeAgencyID 19070. Forthe GDT ProductID 19000, the Object Class is Product 19002, the Propertyis Identification 19004, the Representation/Association term isIdentifier 19006, the Type term is CCT 19008, the Type Name isIdentifier 19010, and the Length is from one to sixty 19012. The GDTProductID 19000 may be a restricted GDT.

A product contributes directly to the value creation if it is salable. Aproduct contributes indirectly to value creation if it is necessary forselling another product, it supports the salability of another product,or it occurs in the business activity of a company and it is in thecompany's interest that this product adds value.

For the schemeID 19016, the Category is Attribute 19018, the ObjectClass is IdentificationScheme 19020, the Property is Identification19022, the Representation/Association term is Identifier 19024, the Typeterm is xsd 19026, the Type Name term is Token 19028, and the Length isfrom one to sixty 19030. The Cardinality between the GDT ProductID 19000and the schemeID 19016 is zero or one 15732. For the schemeAgencyID19034, the Category is Attribute 19036, the Object Class isIdentificationSchemeAgency 19038, the Property is Identification 19040,the Representation/Association term is Identifier 19042, the Type termis xsd 19044, the Type Name term is Token 19046, and the Length is fromone to sixty 19048. The Cardinality between the GDT ProductID 19000 andthe schemeAgencyID 19034 is zero or one 19050. For theschemeAgencySchemeID 19052, the Category is Attribute 19054, the ObjectClass is IdentificationSchemeAgency 19056, the Property is Scheme 19058,the Representation/Association term is Identifier 19060, the Type termis xsd 19062, the Type Name term is Token 19064, and the Length is fromone to sixty 19066. The Cardinality between the GDT ProductID 19000 andthe schemeAgencySchemeID 19052 is zero or one 19068. For theschemeAgencySchemeAgencyID 19070, the Category is Attribute 19072, theObject Class is IdentificationSchemeAgency 19074, the Property isSchemeAgency 19076, the Representation/Association term is Identifier19078, the Type term is xsd 19080, the Type Name term is Token 19082,and the Length is three 19084. The Cardinality between the GDT ProductID19000 and the schemeAgencySchemeAgencyID 19070 is zero or one 19086.

(zzzzzz) ProductInternalID

A CDT ProductInternalID 19100 is a proprietary identifier for a product.A product is either a tangible or intangible good, and is a part of thebusiness activities of a company. It can be traded and contributesdirectly or indirectly to value added. Examples (in SAP MDM)

GUID of a product:   <ProductInternalID schemeID=“ProductGUID”schemeAgencyID= “MPL_002”>1C743CEC501F6A4D8826C7EC5A8554B9</ProductInternalID>   schemeID=“PartyGUID” indicates that the scheme“ProductGUID” was used to identify the product.  schemeAgencyID=“MPL_002” indicates that the scheme was assigned by thebusiness system “MPL_002.”

Product ID of a product:   <ProductInternalID schemeID=“ProductID”  schemeAgencyID=“MPL_002”> VWPassat 01 0601 MPLCNT002</ProductInternalID>

The structure of CDT ProductInternalID 19100 is depicted in FIG. 191.The CDT ProductInternalID 19100 includes attributes schemeID 19118 andschemeAgencyID 19136. For the CDT ProductInternalID 19100, the ObjectClass is Product 19102, the Property Qualifier term is Internal 19104,the Property is Identification 19106, the Representation/Associationterm is Identifier 19108, the Type term is GDT 19110, the Type Name termis ProductID 19112, and the Length is from one to sixty 19114. The CDTProductInternalID 19100 may be a restricted CDT.

The attributes of a CDT ProductInternalID 19100 may be filled as followsin an SAP MDM example.

For the schemeID 19118, the following schemes are provided: 1)ProductGUID, which identifies a product category via a Globally UniqueIdentifier; and 2) ProductID, which identifies a product category usingan identifier. For the schemeID 19118, the Category is Attribute 19120,the Object Class is IdentificationScheme 19122, the Property isIdentification 19124, the Representation/Association term is Identifier19126, the Type term is xsd 19128, the Type Name term is Token 19130,and the Length is from one to sixty 19132. The Cardinality between theCDT ProductInternalID 19100 and the schemeID 19118 is zero or one 19134.

The schemeAgencyID 19136 is the business system in which the identifierwas assigned. For the schemeAgencyID 19136, the Category is Attribute19138, the Object Class is IdentificationSchemeAgency 19140, theProperty is Identification 19140, the Representation/Association term isIdentifier 19142, the Type term is xsd 19144, the Type Name term isToken 19146, and the Length is from one to sixty 19148. The Cardinalitybetween the CDT ProductInternalID 19100 and the schemeAgencyID 19136 iszero or one 19150.

The CDT ProductInternalID 19100 represents a projection of the GDTProductID, in which the attributes schemeID and schemeAgencyID arecontained for describing an internally assigned ID. If an attribute isnot explicitly assigned in the use of the GDT, it may be determinedthrough the context.

The CDT ProductInternalID 19100 is used when both sender and recipientcan access shared master data, e.g., during internal communication.

-   -   A product contributes directly to the value creation if it is        salable. A product contributes indirectly to value creation if        -   it is necessary for selling another product,        -   it supports the salability of another product, or        -   it occurs in the business activity of a company and it is in            the company's interest that this product adds value.

In case the product is identified via the schema (schemeID), it shouldbe noted that the product category may first be capable of beinguniquely identified via a combined key (for example, the productcategory at an entity level can be uniquely identified (semantically) byusing the ProductID, the ProductTypeID, the ObjectFamily and the logicalsystem).

(aaaaaaa) CDT ProductPartyID

A CDT ProductPartyID 19200 is an identifier for a product assigned by aparty. A product is either a tangible or intangible good, and is a partof the business activities of a company. It can be traded andcontributes directly or indirectly to value added. An example of a CDTProductPartyID 19200 is: <ProductSellerID>B 1165 HS</ProductSellerID>

The structure of ProductPartyID is depicted in FIG. 192. The CDTProductPartyID 19200 is the proprietary identifier assigned by abusiness partner. The business partner, in its role, that assigned thisidentifier may derive from the business context of the message that theProductPartyID uses. For the CDT ProductPartyID 19200, the Object Classis Product 19202, the Property Quality term is Party 19204, the Propertyis Identification 19206, the Representation/Association term isIdentifier 19208, the Type term is GDT 19210, the Type Name term isProductID 19212, and the Length is from one to sixty 19214. The CDTProductPartyID 19200 may be a restricted CDT.

The use of the CDT ProductPartyID 19200, unlike the ProductStandardID,is role-dependent for example, as an ID assigned by the Buyer. The partyis specified by its role. The term “Party” is replaced with the term“partner role type” for example, ProductSellerID. SchemeID andschemeVersionID are to be included as attributes as soon as there is aneed to differentiate between several schemes. (See GDT ProductID17500).

(bbbbbbb) ProductStandardID

A CDT ProductStandardID 19300 is a standardized identifier for aproduct, and the identification scheme may be managed by an agency fromthe code list DE 3055. A product is either a tangible or intangiblegood, and is a part of the business activities of a company. The productcan be traded and contributes directly or indirectly to value added. Anexample of a CDT ProductStandardID 19300 is: <ProductStandardIDschemeAgencyID=“009”>B 1165 HS</ProductStandardID>, wherein 009 is theEAN (International Article Numbering association) code.

The structure of GDT ProductStandardID 19300 is depicted in FIG. 193.The structure of GDT ProductStandard ID 19300 is depicted in FIG. 193.The GDT ProductStandard ID 19300 includes attributes schemeID 19318 andschemeAgencyID 19336. For the GDT ProductStandard ID 19300, the ObjectClass is Product 19302, the Property Qualifier term is Standard 19304,the Property is Identification 19306, the Representation/Associationterm is Identifier 19308, the Type term is GDT 19310, the Type Name termis ProductID 19312, and the Length is from one to fourteen 19314. TheGDT ProductStandard ID 19300 may be a restricted GDT.

For the schemeID 19318, the Category is Attribute 19320, the ObjectClass is Identification Scheme 19322, the Property is Identification19324, the Representation/Association term is Identifier 19326, the Typeterm is xsd 19328, the Type Name term is Token 19330, and the Length isfrom one to sixty 19332. The Cardinality between the GDT ProductStandardID 19300 and the schemeID 19318 is zero or one 19334.

The “schemeAgencyID” 19336 identifies the agency that manages anidentification scheme. The agencies from DE 3055 may be used as thedefault, but in a variation the roles defined in DE 3055 may no be used.At least the following two codes may be supported: 1) 009, which is theEAN.UCC, International Numbering Association code for the GTIN (GlobalTrade Item Number), which can have up to 14 characters; and 2) 005,which is the ISO, International Organization for Standardization codefor the 13-character ISBN (International Standard Book Number). ForISBN, the code “005” (ISO) is entered for the schemeAgencyID 19336 alongwith the schemeID 19318 of “ISO 2108: 1992,” which indicates that it isan ISBN. The ISBN scheme is managed by isbn-international.org/.Specifying a schemeID 19318 is not necessary if a scheme exists for anagency.

For the schemeAgencyID 19336, the Category is Attribute 19338, theObject Class is Identification Scheme Agency 19340, the Property isIdentification 19342, the Representation/Association term is Identifier19344, the Type term is xsd 19346, the Type Name term is Token 19348,and the Length is three 19350. The Cardinality between the CDTProductStandard ID 19300 and the schemeAgencyID 19336 is one 19352.

Another standardized identification scheme is the pharmaceutical centralnumber. There is no SchemeAgencyID 19336 for this in the code list DE3055. How this will be represented may still be clarified. The structureof the GDTs HandlingUnit may be compatible with the “packaging” in theDELVRY03 IDoc.

The GDT ProductStandardID 19300 represents a projection of the GDTProductID 19000, in which the attributes schemeID 19318 andschemeAgencyID 19336 are contained for describing an ID assigned by astandardization organization (i.e., an organization registered in DE3055). The attribute schemeAgencyID 19336 may be a mandatory attribute.

Contrary to the ProductPartyID 19200, use of the ProductStandardID 19300is not role dependent. SchemeVersionID is to be included as an attributeas soon as there is a need to differentiate between several schemes.(See GDT ProductID 19000).

(ccccccc) GDT ProductTax

A GDT ProductTax 19400 is a tax that is incurred during the sale,purchase, and consumption of products and during other related businesstransactions. An example of a ProductTax GDT 19400 used inTaxDueNotification, is as follows: <ProductTax>  <CountryCode>DE</CountryCode>   <TypeCode>VAT</TypeCode>  <TypeDescription>Value added tax</TypeDescription>   <BaseAmountcurrencyCode=“EUR”>100</BaseAmount>   <Percent>16</Percent>   <AmountcurrencyCode=“EUR”>116</Amount>  <BusinessTransactionDocumentItemGroupID>1</BusinessTransactionDocumentItemGroupID> </ProductTax>.

The structure of the GDT ProductTax 19400 is depicted in FIG. 194. Thestructure of GDT ProductTax 19400 is depicted in FIG. 194. The GDTProductTax 19400 includes elements CountryCode 19403, JurisdictionCode19411, Type Code 19419, TypeDescription 19427, BaseAmount 19435, Percent19443, Amount 19452, NonDeductiblePercent 19460, NonDeductibleAmount19468, BusinessTransactionDocument ItemGroupID 19476,TriangulationIndicator 19484, and LegallyRequiredPhrase 19492. For theGDT ProductTax 19400, the Object Class is ProductTax 19401, and theRepresentation/Association term is Details 19402.

The CountryCode 19406 (ISO 3166-1) defines the country in which the taxis incurred. For the CountryCode 19403, the Category is Element 19404,the Object Class is ProductTax 19405, the Property is Country Code19406, the Representation/Association term is Cod 19407, the Type termis GDT 19408, and the Type Name term is CountryCode 19409. TheCardinality between the GDT ProductTax 19400 and the CountryCode 19403is zero or one 19410.

The JurisdictionCode 19422 is used for some countries (in particular theUS) to identify the responsible tax authorities. For theJurisdictionCode 19411, the Category is Element 19412, the Object Classis ProductTax 19413, the Property is Tax Jurisdiction Code 19414, theRepresentation/Association term is Code 19415, the Type term is GDT19416, and the Type Name term is TaxJurisdictionCode 19417. TheCardinality between the GDT ProductTax 19400 and the JurisdictionCode19411 is zero or one 19418.

The TypeCode 19438 is a tax code, see GDT ProductTaxTypeCode. For theTypeCode 19419, the Category is Element 19420, the Object Class isProductTax 19421, the Property is Type Code 19422, theRepresentation/Association term is Code 19423, the Type term is GDT19424, and the Type Name term is ProductTaxTypeCode 19425. TheCardinality between the GDT ProductTax 19400 and the TypeCode 19419 iszero or one 19426.

The TypeDescription 19454 is a short description of tax, such as for thetax code “OTH—Other taxes, unspecified, miscellaneous tax charges.” Forthe TypeDescription 19427, the Category is Element 19428, the Propertyis Type Description 19430, the Representation/Association term is Text19431, the Type term is GDT 19432, and the Type Name term is Description19433. The Cardinality between the GDT ProductTax 19400 and theTypeDescription 19427 is zero or one 19434.

The BaseAmount 19470 is a Base amount on which tax was calculated(assessment basis). For the BaseAmount 19435, the Category is Element19436, the Object Class is ProductTax 19437, the Property is Base Amount19438, the Representation/Association term is Amount 19439, the Typeterm is GDT 19440 m, and the Type Name term is Amount 19441. TheCardinality between the GDT ProductTax 19400 and the BaseAmount 19435 iszero or one 19442.

The Percent 19486 is a tax rate, or level of tax in percent. For thePercent 19443, the Category is Element 19444, the Object Class isProductTax 19445, the Property is Percent 19446, theRepresentation/Association term is Percent 19447, the Type term is GDT19448, and the Type Name term is Percent 19449. The Cardinality betweenthe GDT ProductTax 19400 and the Percent 19443 is either zero or one19450.

The Amount 19403 is a tax amount that is due for the underlying baseamount. For the Amount 19451, the Category is Element 19452, the ObjectClass is ProductTax 19453, the Property is Amount 19454, theRepresentation/Association term is Amount 19455, the Type term is GDT19456, and the Type Name term is Amount 19457. The Cardinality betweenthe GDT ProductTax 19400 and the Amount 19451 is either zero or one19458.

The NonDeductiblePercent 19419 is a percentage rate, portion, of taxthat is non-deductible. For the NonDeductiblePercent 19459, the Categoryis Element 19460, the Object Class is ProductTax 19461, the Property isNonDeductiblePercent 19462, the Representation/Association term isDecimal 19463, the Type term is GDT 19464, and the Type Name term isPercent 19465. The Cardinality between the GDT ProductTax 19400 and theNonDeductiblePercent 19459 is zero or one 19466.

The NonDeductibleAmount 19435 is an amount of tax that isnon-deductible. For the NonDeductibleAmount 19467, the Category isElement 19468, the Object Class is ProductTax 19469, the Property isNonDeductibleAmount 19470, the Representation/Association term is Amount19471, the Type term is GDT 19472, and the Type Name term is Amount19473. The Cardinality between the GDT ProductTax 19400 and theNonDeductibleAmount 19467 is zero or one 19474.

The BusinessTransactionDocumentItemGroupID 19451 groups items of aBusinessTransactionDocument that may be taxed in the same way. There isno global code list for the BusinessTransactionDocumentItemGroupID19451, the possible values are arbitrary and may be used consistentlywithin a document (e.g., an invoice). TheBusinessTransactionDocumentItemGroupID 19451 can optionally be used torelate the taxes at item level to the summary tax lines at documentlevel. The BusinessTransactionDocumentItemGroupID 19451 assists duringinvoice verification. For the BusinessTransactionDocument ItemGroupID19475, the Category is Element 19476, the Object Class is ProductTax19477, the Property is Business Transaction Document Item GroupIdentification 19478, the Representation/Association term is Identifier19479, the Type term is GDT 19480, and the Type Name term isBusinessTransactionDocumentItemGroupID 19481. The Cardinality betweenthe GDT ProductTax 19400 and the BusinessTransactionDocument ItemGroupID19475 is zero or one 19482.

The TriangulationIndicator 19467 is a yes or no indicator that specifieswhether the transaction is a triangular transaction. For theTriangulationIndicator 19483, the Category is Element 19484, the ObjectClass is ProductTax 19485, the Property is Triangulation 19486, theRepresentation/Association term is Indicator 19487, the Type term is CCT19488, and the Type Name term is Indicator 19489. The Cardinalitybetween the GDT ProductTax 19400 and the TriangulationIndicator 19483 iszero or one 19490.

The LegallyRequiredPhrase 19438 is a legally required phrase that may beprinted on the invoice. For the LegallyRequiredPhrase 19491, theCategory is Element 19492, the Object Class is ProductTax 19493, theProperty is Legally Required Phrase 19494, theRepresentation/Association term is Text 19495, the Type term is CCT19496, the Type Name term is Text 19497, and the Length is one to twohundred fifty-six 19498. The Cardinality between the GDT ProductTax19400 and the LegallyRequiredPhrase 19491 is zero or one 19499.

The segment GDT ProductTax 19400 is connected with an amount from whichthe base amount to be taxed is calculated. Rules on which taxes may bereported in summary form or at item level are country-dependent and arederived from the relevant legal requirements. For example, German salestax may be reported in an invoice in summarized form for each tax rate.Non-deductible taxes are relevant for incoming invoices and creditmemos. When a tax rate or tax amount is reported, the tax type theTypeCode 19438, may also be specified.

It is possible to tell from the BusinessTransactionDocumentItemGroupID19451 how the individual items are taxed. If the items also report taxrate and tax amount, then the BusinessTransactionDocumentItemGroupID19451 is superfluous. An example of an invoice with 3 items with Germansales tax is shown in the following table: Item Type Base Group CountryCode Description Amount Percent Amount ID Item 1 100.00 EUR A Item 2200.00 EUR B Item 3 300.00 EUR A Total A DE VAT Sales Tax 400.00 EUR 1664.00 EUR A Total B DE VAT Sales Tax 200.00 EUR 7 14.00 EUR BThe GDT ProductTax 19400 is used to report different tax portions ininvoice amounts or to initiate tax returns and payments of a company tothe responsible tax authorities. A tax is a mandatory public paymentthat a community levies on natural and legal persons in its territory ata unilaterally fixed level (unlike fees and contributions) withoutproviding a service in return. The tax jurisdiction code of a natural orlegal person is part of the address data. The tax calculation depends onthe tax jurisdiction code of the ship-from or ship-to party in certaincountries, e.g., the US and Brazil.

(ddddddd) ProductTaxEventTypeCode

The GDT ProductTaxEventTypeCode 19500 is a coded representation of thetax event type that is linked to the purchase, sale or consumption ofproducts. A tax event type refers to a combination of characteristicsthat are the basis for tax liability, tax relief measures, or taxexemptions of specific types and amounts, from the point of view ofcountry-specific tax laws. An example or Instance of GDTProductTaxEventTypeCode 19500 is: <ProductTaxEventTypeCode> DE101</ProductTaxEventTypeCode >.

The structure of GDT ProductTaxEventTypeCode 19500 is depicted in FIG.195.

Characteristics of the tax event types in terms of tax legislation arethe subject of taxation, the legal entity that may pay tax, and thetaxation object, the object, transaction or status of taxation. The typeand number of tax event types to be taken into account for product taxesderive from the tax laws of a country. These laws or their provisionsgenerally do not stipulate any specific codes, however. The codes maytherefore be individually defined by the respective softwaremanufacturers. The structure of GDT Product Tax Event Type Code 19500 isdepicted in FIG. 195. For the GDT Product Tax Event Type Code 19500, theObject Class is Product Tax Event 19502, the Property is Type Code19504, the Representation/Association term is Code 19506, the Type termis CCT 19508, the Type Name term is Code 19510, and the Length is fromthree to six 19512. The GDT Product Tax Event Type Code 19500 may be arestricted GDT.

In the GDT ProductTaxEventTypeCode 19500, the first two figures consistof the two-character ISO code 3166-1 for the country for which the taxmatter is relevant, and is generally followed by a three-digit numberfrom 100 to 999.

The GDT ProductTaxEventTypeCodes 19500 for Germany and the USA arelisted in the following table: ProductTaxEventTypeCode Description DE100Non-taxable delivery DE101 Domestic delivery DE102 Intra-communitydelivery to recipient with VAT reg. no. DE103 Intra-community deliveryof new vehicles to recipient without VAT reg. no. DE104 Intra-communitydelivery of new vehicles outside a company DE105 Tax-free deliveryaccording to § 4 nos. 2 to 7 UStG (German taxation law) DE106 Tax-freedelivery according to § 4 nos. 8 to 28 UStG (German taxation law) DE107Domestic delivery according to § 3c(3) UStG (German taxation law)(Distance selling) DE110 Export delivery (export to third country) DE151Delivery by an agricultural or forestry company to the remainingcommunity area to recipients with VAT reg. no. DE152 Domestic deliveryby an agricultural or forestry company according to § 24(1)2 UStG(German taxation law) DE200 Non-taxable acquisition DE201 Domesticacquisition DE202 Tax-free intra-community acquisition according to § 4bUStG (German taxation law) DE203 Taxable intra-community acquisition ofobjects DE204 Taxable intra-community acquisition of other servicesDE205 Taxable intra-community acquisition of new vehicles fromdeliverers without VAT reg. no. DE206 Taxable intra-communityacquisition according to delivery to first recipient in intra-communitytriangular transaction according to § 25b(2) UStG (German taxation law)DE207 Acquisition according to § 13b(2) UStG (German taxation law)(beneficiary owes tax) DE210 Import (import from third country) DE301Posttax for taxed payments due to increased tax rate DE302 Authorizationfor input tax deduction according to § 15a UStG (German taxation law)US100 Non-taxable domestic sale US101 Taxable domestic sale US110 Export(not taxable) US200 Non-taxable domestic acquisition US201 Domesticacquisition use tax US202 Domestic acquisition sales tax US210 Import(taxable)

The GDT ProductTaxEventTypeCode 19500 is used in tax calculation todetermine the type and percentage rate of tax to be taken into account.Furthermore, based on the GDT ProductTaxEventTypeCode 19500, the taxregister decides how and when the reported tax may be declared and paidto the tax authorities.

The GDT ProductTaxEventTypeCode 19500 may be a proprietary code listwith fixed predefined values. Changes to the permitted values involvechanges to the interface. In a variation, the GDTProductTaxEventTypeCode 19500 is similar to the tax code in R/3 from asemantic point of view. In contrast to the tax code, however, the GDTProductTaxEventTypeCode 19500 is independent of tax rates.

(eeeeeee) ProductTaxTypeCode

The GDT ProductTaxTypeCode 19600 is a coded representation of the typeof a tax that is incurred during the sale, purchase, and consumption ofproducts and during other related business transactions. An example of19600 is:

<ProductTaxTypeCode>VAT</ProductTaxTypeCode>

The structure of 19600 is depicted in FIG. 196. The structure of GDTProduct Tax Type Code 19600 is depicted in FIG. 196. For the GDT ProductTax Type Code 19600, the Object Class is ProductTaxType 19602, theProperty is Code 19604, the Representation/Association term is Code19606, the Type term is CCT 19608, the Type Name term is Code 19610, andthe Length is three 19612. The GDT Product Tax Type Code 19600 may be arestricted GDT.

The complete UN/EDIFACT code list “Duty or tax or fee Type code” is usedfor the values of the GDT ProductTaxTypeCode 19600. The GDTProductTaxTypeCode 19600 is used for entering taxes, e.g., in invoices.The relevant types of product taxes for Germany and the US are, forexample:

1) A Value added tax (VAT), which is a sales tax levied in Germany. TheVAT also applies to all other EU countries and countries with comparablesales tax.

2) A State/provincial sales tax (STT), which is a sales tax levied byfederal states in the USA; also applies to other federal countries withcomparable tax.

3) Local sales tax (LOC), which is a sales tax levied by tax authoritiesin a state in the US, e.g., county sales tax, city sales tax. The LOCalso applies to other federal countries with comparable tax.

(fffffff) ProductTypeCode

The GDT ProductTypeCode 19700 is a coded representation of the producttype. A product type describes the nature of products and establishesthe basic properties for products of this type. An example of 19700 is:<ProductTypeCode>1</ProductTypeCode>. The structure of GDTProductTypeCode 19700 is depicted in FIG. 197. The structure of GDTProductTypeCode 19700 is depicted in FIG. 197. For the GDTProductTypeCode 19700, the Category is Element 19702, the Object Classis Product 19704, the Property is Type 19706, theRepresentation/Association term is Code 19708, the Type term is CCT19710, the Type Name term is Code 19712, and the Length is from one totwo 19714. The GDT ProductTypeCode 19700 may be a restricted GDT.

Some illustrative examples of the GDT ProductTypeCode 19700 are:

1) The number 1, which represents a Material. A material is a tangibleproduct that can be created and thus represents a commercial value. Amaterial's manufacture/production is time-independent from itsconsumption/use. A material can be traded; used in manufacture,consumed, or produced.

2) The number 2, which represents a Service product. A service productis an intangible product that describes the rendering of service. Therendering of a service coincides in time with its use.

The GDT ProductTypeCode 19700 determines the type of a product in moredetail. It can be used in the context of a product instance or of areference to a product instance in order to qualify this productinstance, and can also be used in its own right. The GDT ProductTypeCode19700 may be a proprietary code list with fixed predefined values.Changes to the permitted values involve changes to the interface.

The ProductTypeCode can be expanded with other product types ifnecessary, including for example:

3) The number 3, which represents a Financial Product. A financialproduct may be a series of incoming and outgoing payments based on acontract and for the purposes of investment or financing. Examples of afinancial product are: Shares, bonds, loans, foreign exchangetransactions or financial derivatives.

4) The number 4, which represents an Intellectual Property. IntellectualProperty may be an intangible product of creative work. IntellectualProperty includes, for example, a media title, if it is (art)work thatis to be conveyed to a wide audience through the media.

5) The number 5, which represents a Warranty. A warranty may be aguarantee within a specified time period to be responsible for flaws ordefects in a product sold. The type and scope of this service arespecified in the warranty.

(ggggggg) PromotionID

A GDT PromotionID 19800 is a unique identifier for a promotion. Apromotion is a marketing activity between the consumer goods industryand retail over a limited timeframe to increase brand capital, namerecognition, and market share, to boost sales volumes, or to positionnew products or product groups. An example of 19800 is:

<PromotionID>72318</PromotionID>.

The structure of GDT PromotionID 19800 is depicted in FIG. 198. For theGDT PromotionID 19800, the Object Class is Promotion 19802, the Propertyis Identification 19804, the Representation/Association term isIdentifier 19806, the Type term is CCT 19808, the Type Name term isIdentifier 19810, and the Length is from one to thirty-five 19812. TheGDT PromotionID 19800 may be a restricted GDT.

Role-based IDs (e.g., BuyerPromotionID, SellerPromotionID) based on theCCT identifier are used without additional attributes; they may beunique in connection with the identification of the business partnerdescribed by the role (e.g., BuyerID, SellerID). A promotion can havedifferent objectives, e.g., to generate awareness of a new product,selectively increase demand for a certain brand, retain loyal customers,or fight competition, with various characteristics, e.g., pricereductions, retail promotion, and promotional rebates.

GDT PromotionID 19800 is used in connection with cooperative businessprocesses, in particular Vendor Managed Inventory (VMI) andCollaborative Planning, Forecasting and Replenishment (CPFR) to clearlyidentify a promotion between the business partners involved. Initially,one business partner, such as a retail company or a consumer goodsmanufacturer, informs the other partner of his identification of thepromotion with a PromotionID. This identification can then be used as areference in the downstream message exchange between the businesspartners.

(hhhhhhh) Property

A GDT Property 19900 is an object attribute. An example of 19900 is: <Property>   <ID schemeAgencyID=“005”>PROPERTY_1</ID>  <DefinitionClassReference>     <IDschemeAgencyID=“005”>DEFCLASS_01</ID>    <VersionID>DEFCLASS_01</VersionID>   </DefinitionClassReference>  <PreferredName languageCode=“EN”>My first property</   PreferredName>  <PreferredName languageCode=“DE”>Mein erstes Merkmal</PreferredName> <PropertyDataTypeReference>DATATYPE_5</  PropertyDataTypeReference> </Property>.

The structure of GDT Property 19900 is depicted in FIG. 199. The GDTProperty 19900 includes attribute ActionCode 19902, elements ID 19910,VersionID 19918, DefinitionClassReference 19926, RevisionID 19934,CreationDateTime 19944, VersionDateTime 19952, RevisionDateTime 19960,SubjectAreaCode 19968, PreferredName 19976, SynonymousName 19985,AbbreviationName 19994, DefiningDescription 19904 a,AdditionalDescription 19913 a, UsageDescription 19922 a,PreferredSymbolNote 19931 a, SynonymousSymbolNote 19940 a,DefinitionSourceDocument WebAddress 19949 a, IconAttachment 19958 a,FigureAttachment 19966 a, PropertyDataType 19974 a,PropertyDataTypeReference 19982 a, MeasureUnitMeaningCode 19990 a,DependingPropertyReference 19998 a, ConstrainingPropertyReference 19908b, AspectID 19917 b, TargetInterfaceElementID 19926 b,MultipleValueIndicator 19935 b, TextSearchableIndicator 19944 b,ParametricSearchableIndicator 19954 b, and ValuationRequiredIndicator19963 b. For the GDT Property 19900, the Representation/Association termis Details 19901.

The ActionCode 19902 is an instruction to the recipient of a messagetelling it how to process a transmitted property. For the ActionCode19902, the Category is Attribute 19903, the Object Class is Property19904, the Property is Action 19905, the Representation/Association termis Code 19906, the Type term is GDT 19907, the Type Name term isActionCode 19908. The Cardinality between the GDT Property 19900 and theActionCode 19902 is zero or one 19909.

The ID 19910 is an unique identifier of the property. For the ID 19910,the Category is Element 19911, the Object Class is Property 19912, theProperty is Identification 19913, the Representation/Association term isPropertyID 19914, the Type term is GDT 19915, the Type Name term isPropertyID 19916. The Cardinality between the GDT Property 19900 and theID 19910 is one 19917.

The VersionID 19918 is an unique identifier for a version of theproperty. For the VersionID 19918, the Category is Element 19919, theObject Class is Property 19920, the Property is Version Identification19921, the Representation/Association term is VersionID 19922, the Typeterm is GDT 19923, and the Type Name term is VersionID 19924. TheCardinality between the GDT Property 19900 and the VersionID 19918 iszero or one 19925.

The DefinitionClassReference 19926 is a reference to the definitionclass (or to a version of the definition class) of the property; if thisreference exists, the property is unique within the specified definitionclass. For the DefinitionClassReference 19926, the Category is Element19927, the Object Class is Property 19928, the Property is DefinitionClass Reference 19929, the Representation/Association term isPropertyDefinitionClassReference 19930, the Type term is GDT 19931, andthe Type Name term is PropertyDefinitionClassReference 19932. TheCardinality between the GDT Property 19900 and theDefinitionClassReference 19926 is zero or one 19933.

The RevisionID 19934 is a revision number, that is, a sequential numberthat is assigned when changes are made. For the RevisionID 19934, theCategory is Element 19935, the Object Class is Property 19936, theProperty is Revision identification 19937, theRepresentation/Association term is Identifier 19938, the Type term isCCT 19939, the Type Name term is Identifier 19940, and the Length isfrom one to ten 19941. The Cardinality between the GDT Property 19900and the RevisionID 19934 is zero or one 19942. The RevisionID may be arestricted CCT.

The CreationDateTime 19944 is a creation date/time stamp. For theCreationDateTime 19944, the Category is Element 19945, the Object Classis Property 19946, the Property is Creation 19947, theRepresentation/Association term is Date Time 19948, the Type term is GDT19949, and the Type Name term is Date Time 19950. The Cardinalitybetween the GDT Property 19900 and the CreationDateTime 19944 is zero orone 19951.

The VersionDateTime 19952 is a creation date/time stamp of this propertyversion. For the VersionDateTime 19952, the Category is Element 19945,the Object Class is Property 19954, the Property is Version 19955, theRepresentation/Association term is Date Time 19956, the Type term is GDT19957, and the Type Name term is Date Time 19958. The Cardinalitybetween the GDT Property 19900 and the VersionDateTime 19952 is zero orone 19959.

The RevisionDateTime 19960 is a date/time stamp of the last change. Forthe RevisionDateTime 19960, the Category is Element 19961, the ObjectClass is Property 19962, the Property is Revision 19968, theRepresentation/Association term is Date Time 19964, the Type term is GDT19965, and the Type Name term is Date Time 19966. The Cardinalitybetween the GDT Property 19900 and the RevisionDateTime 19960 is zero orone 19967.

The SubjectAreaCode 19968 is a subject area in which the property can beused. (See GDT SubjectAreaCode). For the SubjectAreaCode 19968, theCategory is Element 19969, the Object Class is Property 19970, theProperty is Subject Area 19971, the Representation/Association term isCode 19972, the Type term is GDT 19973, and the Type Name term isSubjectAreaCode 19974. The Cardinality between the GDT Property 19900and the SubjectAreaCode 19968 is zero or n 19975.

The PreferredName 19976 is a name of the property. There may be amaximum of one entry per language for the PreferredName 19976. For thePreferredName 19976, the Category is Element 19977, the Object Class isProperty 19978, the Property Quality term is Preferred 19979, theProperty is Name 19980, the Representation/Association term is Name19981, the Type term is GDT 19982, and the Type Name term is Name 19983.The Cardinality between the GDT Property 19900 and the PreferredName19976 is from one to n 19984.

The SynonymousName 19985 is a synonym name for the property. For theSynonymousName 19985, the Category is Element 19986, the Object Class isProperty 19987, the Property Quality term is Synonymous 19988, theProperty is Name 19989, the Representation/Association term is Name19990, the Type term is GDT 19991, and the Type Name term is Name 19992.The Cardinality between the GDT Property 19900 and the SynonymousName19985 is from zero to n 19993.

The AbbreviationName 19994 is an abbreviated property name. There may bea maximum of one entry per language for the AbbreviationName 19994. Forthe AbbreviationName 19994, the Category is Element 19995, the ObjectClass is Property 19996, the Property Quality term is Abbreviation19997, the Property is Name 19998, the Representation/Association termis Name 19999, the Type term is GDT 19901 a, and the Type Name term isName 19902 a. The Cardinality between the GDT Property 19900 and theAbbreviationName 19994 is from zero to n 19903 a.

The DefiningDescription 19904 a is an unique definition of theproperty's meaning that makes it possible to uniquely distinguish theproperty from the other properties. A definition may be entered for eachlanguage. For the Defining/Description 19904 a, the Category is Element19905 a, the Object Class is Property 19906 a, the Property Quality termis Defining 19907 a, the Property is Description 19908 a, theRepresentation/Association term is Description 19909 a, the Type term isGDT 19910 a, and the Type Name term is Description 19911 a. TheCardinality between the GDT Property 19900 and the Defining/Description19904 a is from zero to n 19912 a.

The AdditionalDescription 19913 a is an additional information aboutparts of the property which aids in the understanding of the property.For the AdditionalDescription 19913 a, the Category is Element 19914 a,the Object Class is Property 19915 a, the Property Quality term isAdditional 19916, the Property is Description 19917 a, theRepresentation/Association term is Description 19918 a, the Type term isGDT 19919 a, and the Type Name term Description 19920 a. The Cardinalitybetween the GDT Property 19900 and the AdditionalDescription 19913 a isfrom zero to n 19921 a.

The UsageDescription 19922 a is a free-text comment. The 19922 a can beused to add explanatory text or general/individual notes. The commentmay not supplement the definition; the description is used for this. Thecomment clarifies particular aspects concerning the use of a property.For the UsageDescription 19922 a, the Category is Element 19923 a, theObject Class is Property 19924 a, the Property Quality term is Usage19925 a, the Representation/Association term is Description, the Typeterm is GDT 19928 a, and the Type Name term is Description 19929 a. TheCardinality between the GDT Property 19900 and the UsageDescription19922 a is from zero to n 19930 a.

The PreferredSymbol 19931 a is a symbol for the property, such as “d”for diameter. For the PreferredSymbolNote 19931 a, the Category isElement 19932 a, the Object Class is Property 19933 a, the PropertyQuality term is Preferred 19934 a, the Property is Symbol 19935 a, theRepresentation/Association term is Note 19936 a, the Type term is GDT19937 a, and the Type Name term is Note 19938 a. The Cardinality betweenthe GDT Property 19900 and the PreferredSymbolNote 19931 a is zero orone 19939 a.

The SynonymousSymbolNote 19940 a is a synonymous symbol for theproperty. For the SynonymousSymbolNote 19940 a, the Category is Element19941 a, the Object Class is Property 19942 a, the Property Quality termis Synonymal 19943 a, the Property is Symbol 19944 a, theRepresentation/Association term is Note 19945 a, the Type term is GDT19946 a, and the Type Name term is Note 19947 a. The Cardinality betweenthe GDT Property 19900 and the SynonymousSymbolNote 19940 a is zero or n19948 a.

The DefinitionSourceDocumentWebAddress 19949 a is a reference to theoriginal document from which the complete property definition or itsmeaning was taken. For the DefinitionSourceDocument WebAddress 19949 a,the Category is Element 19950 a, the Object Class is Property 19951 a,the Property Quality term is DefinitionSource 19952 a, the Property isDocument 19953 a, the Representation/Association term is WebAddress19954 a, the Type term is GDT 19955 a, and the Type Name term isWebAddress 19956 a. The Cardinality between the GDT Property 19900 andthe DefinitionSourceDocument WebAddress 19949 a is zero or one 19957 a.

The IconAttachment 19958 a is a preferred icon, that is, a character(alphanumeric character, symbol, or combination thereof) that conformsto international standards and that, particularly in formulas,represents the property in place of the property name. For theIconAttachement 19958 a, the Category is Element 19959 a, the ObjectClass is Property 19960 a, the Property is Icon 19961 a, theRepresentation/Association term is Attachment 19962 a, the Type term isGDT 19963 a, and the Type Name term is Attachment 19964 a. TheCardinality between the GDT Property 19900 and the IconAttachment 19958a is zero or one 19965 a.

The FigureAttachment 19966 a is a link to a figure. For theFigureAttachment 19966 a, the Category is Element 19967 a, the ObjectClass is Property 19968 a, the Property is FIG. 19969 a, theRepresentation/Association term is Attachment 19970 a, the Type term isGDT 19971 a, and the Type Name term is Attachment 19972 a. TheCardinality between the GDT Property 19900 and the FigureAttachment19966 a is zero or one 19973 a.

The PropertyDataType 19974 a is used if the data type of the property isdefined for this property (local), then the GDT is embedded here. Inthis case, GlobalPropertyDataType is not used. For the PropertyDataType19974 a, the Category is Element 19975 a, the Object Class is Property19976 a, the Property is Property Data Type 19977 a, theRepresentation/Association term is PropertyDataType 19978 a, the Type isGDT 19979 a, and the Type Name term is PropertyDataType 19980 a. TheCardinality between the GDT Property 19900 and the PropertyDataType19974 a is zero or one 19981 a.

The PropertyDataTypeReference 19982 a is used if an independent datatype (global) is to be used for this property, then its identifier isspecified here. In this case, LocalPropertyDataType is not used. For thePropertyDataTypeReference 19982 a, the Category is Element 19983 a, theObject Class is Property 19984 a, the Property is Property Data TypeReference 19985 a, the Representation/Association term isPropertyDataTypeReference 19986 a, the Type term is GDT 19987 a, and theType Name term is PropertyDataTypeReference 19988 a. The Cardinalitybetween the GDT Property 19900 and the PropertyDataTypeReference 19982 ais zero or one 19989 a.

The MeasureUnitMeaningCode 199909 a indicates the meaning of a physicalunit. (See GDT MeasureUnitMeaningCode). For the MeasureUnitMeaningCode19990 a, the Category is Element 19991 a, the Object Class is Property19992 a, the Property is Measure Unit Meaning 19993 a, theRepresentation/Association term is Code 19994 a, the Type term is GDT19995 a, and the Type Name term is MeasureUnitMeaningCode 19996 a. TheCardinality between the GDT Property 19900 and theMeasureUnitMeaningCode 19990 a is zero or one 19997 a.

The DependingPropertyReference 19998 a is, for a constraining property,the reference to the depending properties. For examples, the“temperature” property, which affects the measurement of a length,contains the key for the “length” property here, in the evaluation, the“temperature” property contains the temperature at which the length isto be measured. For the DependingPropertyReference 19998 a, the Categoryis Element 19999 a, the Object Class is Property 19901 b, the PropertyQuality term is Depending 19902 b, the Property is PropertyIdentification 19903 b, the Representation/Association term isPropertyIdentifcation 19904 b, the Type term is GDT 19905 b, and theType Name term is PropertyReference 19906 b. The Cardinality between theGDT Property 19900 and the DependingPropertyReference 19998 a is fromzero to n 19907 b.

The ConstrainingPropertyReference 19908 b is, for a depending property,the reference to the constraining properties. For example, the “length”property, which is dependent on the temperature, contains the key forthe “temperature” property here; in the evaluation, the “temperature”property contains the temperature at which the length is to be measured.For the ConstrainingPropertyReference 19908 b, the Category is Element19909 b, the Object Class is Property 19910 b, the Property Quality termis Constraining 19911 b, the Property is Property Identification 19912b, the Representation/Association term is PropertyIdentification 19913b, the Type term is GDT 19914 b, and the Type Name term isPropertyReference 19915 b. The Cardinality between the GDT Property19900 and the ConstrainingPropertyReference 19908 b is from zero to n19916 b.

The following elements may be used in the context of a catalogue:

The AspectID 19917 b identifies an aspect for which the property isrelevant. For the AspectID 19917 b, the Category is Element 19918 b, theObject Class is Property 19919 b, the Property is Aspect Identification19920 b, the Representation/Association term is Identifier 19921 b, theType term is GDT 19922 b, and the Type Name term is AspectID 19923 b.The Cardinality between the GDT Property 19900 and the AspectID 19917 bis form zero to n 19924 b. The AspectID 19917 may be for the catalogue19925 b.

The TargetInterfaceElementID 48426 b is the unique identifier of anelement in an interface to which element the property can be assigned.For the TargetInterfaceElementID 19926 b, the Category is Element 19927b, the Object Class is Property 19928 b, the Property is TargetInterface Element Identification 19929 b, the Representation/Associationterm is Identifier 19930 b, the Type term is GDT 19931 b, and the TypeName term is InterfaceElementID 19932 b. The Cardinality between the GDTProperty 19900 and the TargetInterfaceElementID 19926 b is from zero ton 19933 b. The TargetInterface ElementID 19926 b may be for thecatalogue 19934 b.

The MultipleValueIndicator 19935 b indicates whether a property cancontain a list of values or not. For the MultipleValueIndicator 19935 b,the Category is Element 19936 b, the Object Class is Property 19937 b,the Property is Multiple Value Indication 19938 b, theRepresentation/Association term is Indicator 19939 b, the Type term isGDT 19940 b, and the Type Name term is PropertyMultipleValueIndicator19941 b. The Cardinality between the GDT Property 19900 and theMultipleValueIndictor 19935 b is zero or one 19942 b. TheMultipleValueIndictor 19935 b may be for the catalogue 19943 b.

The TextSearchableIndicatorm 19944 indicates whether a property issuitable for a text search or not. For the TextSearachableIndicator19944 b, the Category is Element 19946 b, the Object Class is Property19947 b, the Property is TextSearchableIndication 19948 b, theRepresentation/Association term is Indicator 19949 b, the Type term isGDT 19950 b, the Type Name term is TextSearchableIndicator 19951 b. TheCardinality between the GDT Property 19900 and theTextSearchableIndicator 19944 b is zero or one 19952 b. TheTextSearchableIndicator 19944 b may be for the catalogue 19953 b.

The ParametricSearchableIndicator 19954 b indicates, whether a propertyis suitable for a parametric search or not. For theParametricSearchableIndicator 19954 b, the Category is Element 19955 b,the Object Class is Property 19956 b, the Property is ParametricSearchable Indication 19957 b, the Representation/Association term isIndicator 19958 b, the Type term is GDT 19959 b, and the Type Name termis PropertyParametric SearchableIndicator 19960 b. The Cardinalitybetween the GDT Property 19900 and the ParametricSearchableIndicator19954 b is zero or one 19961 b. The ParametricSearchableIndicator 19954b may be for the catalogue 19962 b.

The ValuationRequiredIndicator 19963 b indicates whether a value may beassigned for the property or not. For the ValuationRequiredIndicator19963 b, the Category is Element 19964 b, the Object Class is Property19965 b, the Property is Valuation Required Indication 19966 b, theRepresentation/Association term is Indicator 19967 b, the Type term isGDT 19968 b, and the Type Name term isPropertyValuationReequiredIndicator 19969 b. The Cardinality between theGDT Property 19900 and the ValuationRequiredIndicator 19963 b is zero orone 19970 b. The ValuationRequiredIndicator 19963 b may be for thecatalogue 19971 b.

See, for example, ISO13584/42 (Definition of data model for properties)available from the GDT owner, for illustrative Integrity Conditions forthe PropertyDataType 19900.

The property may have a data type. The data type can either be embeddedunder PropertyDataType 19900 or specified as a reference underPropertyDataType 19900.

The ISO13584/42 specifies that a property cannot be depending andconstraining at the same time. This means that, in a variation,DependingPropertyReference 19998 a and ConstrainingPropertyReference19908 b are not both be filled out.

Properties can be used for classification, for example.

Some elements that are mandatory in ISO13584/42 are optional in thisscheme. This is intended to enable wider use of the scheme.

The attribute AdditionalDescription 19913 a corresponds to the attributeNote in ISO; the attribute UsageDescription 19922 a corresponds to theattribute Remark in ISO. ISO also contains an attribute that contains aformula describing the property. The GDT may not contain this attribute.

(iiiiiii) PropertyDataType

A CDT PropertyDataType 20000 is the data type of a property. Itdescribes the syntax of the values and can contain a list of permittedvalues. An example or instance of 20000 is as follows and describes atypical data type in character format and with a fixed length.  <PropertyDataType>     <ID schemeAgencyID=“005”>MY_DATATYPE_01</ID>    <VersionID>5</VersionID>     <PreferredName languageCode=‘EN’>Myfirst data type</PreferredName>     <Format>02</Format>    <MaximumTotalDigits>13</MaximumTotalDigits>    <LowerCaseAllowedIndicator>true</     LowerCaseAllowedIndicator>  </PropertyDataType>

The following example of 20000 describes a data type in numeric formatand with decimal places. Negative numbers are permitted, as areintervals. The following format is used: ______,   <PropertyDataType>    <ID schemeAgencyID=“005”>MY_DATATYPE_01</ID>    <VersionID>5</VersionID>     <PreferredName languageCode=‘EN’>Myfirst data type</PreferredName>     <FormatCode>06</FormatCode>    <MaximumTotalDigitsNumeric>13</     MaximumTotalDigitsNumeric>    <FractionalDigitsNumeric>5</FractionalDigitsNunmeric> <NegativeValuesAllowedIndicator>true</  NegativeValuesAllowedIndicator> <IntervalValuesAllowedIndicator>true</  IntervalValuesAllowedIndicator>  </PropertyDataType>.

The structure of CDT PropertyDataType 20000 is depicted in FIG. 200. TheCDT PropertyDataType 20000 includes attribute ActionCode 20002 andelements ID 20010, VersionID 20018, PreferredName 20026, SynonymousName20035, ShortName 20044, IconAttachment 20053, Description 20061,UsageDescription 20069, FormatCode 20078, LanguageDependencyIndicator20086, MaximumTotalDigitNumberValue 20094, FractionalDigitNumberValue20005 a, LowerCaseAllowedIndicator 20015 a,NegativeValueAllowedIndicator 20023 a, MeasureUnitCode, CurrencyCode,ExponentialRepresentationTypeCode 20047 a, ExponentIntegerValue 20055 a,IntervalValueIndicator 20064 a,FractionalDigitPresentationAccuracyIndicator 20073 a, RegularExpression20082 a, SeparatorUsageIndicator 20090 a, TupelLengthValue 20098 a,ComponentPropertyDefinition Class Reference 20008 b, ComponentProperty20017 b, AllowedPropertyValueElement 20042 b, andAllowedPropertyValuation 20084 b. For the PropertyDataType 20000, theRepresentation/Association term is Details 20001.

The ActionCode 20002 is an instruction to the recipient of a messagetelling it how to process a transmitted property data type. For theActionCode 20002, the Category is Attribute 20003, the Object Class isPropertyDataType 20004, the Property is Action 20005, theRepresentation/Association term is Code 20006, the Type term is GDT20007, and the Type Name term is ActionCode 20008. The Cardinalitybetween the PropertyDataType 20000 and the ActionCode 20002 is zero orone 20009.

The ID 20010 is an unique identifier of the data type. A data type caneither be embedded in a property or defined as a dependent object, inwhich case, no identifier or names are specified. If a data type is tobe used for several properties, it may have its own key and can have aname. For the ID 20010, the Category is Element 20011, the Object Classis PropertyDataType 20012, the Property is Identification 20013, theRepresentation/Association term is Identifier 20014, the Type term isGDT 20015, and the Type Name term is PropertyDataTypeID 20016. TheCardinality between the PropertyDataType 20000 and the ID 20010 is zeroor one 20017.

The VersionID 20018 is an unique identifier for a version of the datatype. For the VersionID 20018, the Category is Element 20019, the ObjectClass is PropertyDataType 20020, the Property is Version Identification20021, the Representation/Association term is VersionID 20022, the Typeterm is GDT 20023, and the Type Name term is VersionID 20024. TheCardinality between the PropertyDataType 20000 and the VersionID is zeroor one 20025.

The PreferredName 20026 is a name with, for example, one entry perlanguage. For the Preferred Name 20026, the Category is Element 20027,the Object Class is PropertyDataType 20028, the Property Quality term isPreferred 20029, the Property is Name 20030, theRepresentation/Association term is Name 20031, the Type term is GDT20032, and the Type Name term is Name 20033. The Cardinality between thePropertyDataType 20000 and the Preferred Name 20026.

The SynonymousName 20035 is a synonym for the data type. Severalsynonyms can be specified for each language. For the SynonymousName20035, the Category is Element 20036, the Object Class isPropertyDataType 20037, the Property Quality term is Synonymous 20038,the Property is Name 20039, the Representation/Association term is Name20040, the Type term is GDT 20041, and the Type Name term is Name 20042.The Cardinality between the PropertyDataType 20000 and the PreferredName 20026 is from zero to n 20043.

The ShortName 20044 is a short name of the data type. One short name canbe entered for each language. For the ShortName 20044, the Category isElement 20045, the Object Class is PropertyDataType 20047, the PropertyQuality term is Short 20047, the Property is Name 20048, theRepresentation/Association term is Name 20049, the Type term is GDT20050, and the Type Name term is Name 20051. The Cardinality between thePropertyDataType 20000 and the ShortName 20044 is from zero to n 20052.

The IconAttachment 20053 is a preferred icon. A character (alphanumericcharacter, symbol, or combination thereof) that conforms tointernational standards and that, particularly in formulas, representsthe data type in place of the data Type. For the IconAttachment 20053,the Category is Element 20054, the Object Class is PropertyDataType20055, the Property is Icon 20056, the Representation/Association termis Attachment 20057, the Type term is GDT 20058, and the Type Name termis Attachment 20059. The Cardinality between the PropertyDataType 20000and the IconAttachment is zero or one 20060.

The Description 20061 is an additional description for any parts of thedefinition class and that aids the understanding of the definitionclass. The description can supplement the definition. For theDescription 20061, the Category is Element 20062, the Object Class isPropertyDataType 20063, the Property is Description 20064, theRepresentation/Association term is Description 20065, the Type term isGDT 20066, and the Type Name term is Description 20067. The Cardinalitybetween the PropertyDataType 20000 and the Description 20061 is fromzero to n 20068.

The UsageDescription 20069 is a description of aspects concerning theusage of the property. This can be an explanatory text orgeneral/individual notes. For the Usage Description 20069, the Categoryis Element 20070, the Object Class is PropertyDataType 20071, theProperty Quality term is Usage 20072, the Property is Description 20073,the Representation/Association term is Description 20074, the Type termis GDT 20075, and the Type Name term is Description 20076. TheCardinality between the PropertyDataType 20000 and the Usage Description20069 is from zero to n 20077.

The FormatCode 20078 is a format of the data type; see GDTPropertyDataTypeFormatCode. For the FormatCode 20078, the Category isElement 20079, the Object Class is PropertyDataType 20080, the Propertyis Format 20081, the Representation/Association term is Code 20082, theType term is GDT 20083, and the Type Name term isPropertyDataTypeFormatCode 20084. The Cardinality between thePropertyDataType 20000 and the FormatCode 20078 is zero or one 20085.

The LanguageDependencyIndicator 20086 values may not be languageneutral. The default value is “false,” i.e., values are languageneutral. For the LanguageDependencyIndicator 20086, the Category isElement 20087, the Object Class is PropertyDataType 20088, the Propertyis Language Dependency 20089, the Representation/Association term isIndicator 20090, the Type term is GDT 20091, and the Type Name term isLanguageDependencyIndicator 20092. The Cardinality between thePropertyDataType 20000 and the LanguageDependencyIndicator 20086 is zeroor one 20093.

The MaximumTotalDigitNumber 20094 is a total length, including decimalplaces. For the MaximumTotalDigitNumberValue 20094, the Category isElement 20095, the Object Class is PropertyDataType 20096, the PropertyQuality term is Maximum Total 20097, the Property is Digit Number 20098,the Representation/Association Quality term is Digit Number 20099, theRepresentation/Association term is Value 20001 a, the Type term is GDT20002 a, and the Type Name term is DigitNumberValue 20003 a. TheCardinality between the PropertyDataType 20000 and theMaximumTotalDigitNumberValue 20094 is zero or one 20004 a.

The FractionalDigitNumber 20005 a is a number of decimal places. For theFractionalDigitNumberValue 20005 a, the Category is Element 20006, theObject Class is PropertyDataType 20007 a, the Property Quality term isFractional 20008 a, the Property is Digit Number 20009 a, theRepresentation/Association Quality term is Digit Number 20010 a, theRepresentation/Association term is Value 20011 a, the Type term is GDT20012 a, and the Type Name term is DigitNumberValue 20013 a. TheCardinality between the PropertyDataType 20000 and theFractionalDigitNumberValue 20005 a is zero or one 20014 a.

The LowerCaseAllowedIndicator 20015 a indicates whether or not lowercaseentries are allowed. The default value is “false,” i.e., lowercasevalues are not allowed. For the LowerCaseAllowedIndicator 20015 a, theCategory is Element 20016 a, the Object Class is PropertyDataType 20017a, the Property is Lower Case Allowed 20018 a, theRepresentation/Association term is Indicator 20019 a, the Type term isGDT 20020 a, and the Type Name term is Indicator 20021 a. TheCardinality between the PropertyDataType 20000 and theLowerCaseAllowedIndicator 20015 a is zero or one 20022 a.

The NegativeValueAllowedIndicator 20023 a indicates whether or notnegative values are allowed. The default value is “false,” i.e.,negative values are not allowed. For the NegativeValueAllowedIndicator20023 a, the Category is Element 20024 a, the ObjectClass term isPropertyDataType 20025 a, the Property is Negative Value Allowed 20026a, the Representation/Association term is Indicator 20027 a, the Typeterm is GDT 20028 a, and the Type Name term is Indicator 20029 a. TheCardinality between the PropertyDataType 20000 and theNegativeValueAllowedIndicator 20015 a is zero or one 20030 a.

The MeasureUnitCode 20031 a is a coded representation of a non-monetaryunit of measurement; see GDT MeasureUnitCode. For the MeasureUnitCode20031 a, the Category is Element 20032 a, the Object Class isPropertyDataType 20033 a, the Property is Measure Unit 20034 a, theRepresentation/Association term is Code 20035 a, the Type term is GDT20036 a, and the Type Name term is MeasureUnitCode 20037 a. TheCardinality between the PropertyDataType 20000 and the MeasureUnitCode20031 a is zero or one 20038 a.

The CurrencyCode 20039 a is a currency of the data type; see GDTCurrencyCode. For the CurrencyCode 20039 a, the Category is Element20040 a, the Object Class is PropertyDataType 20041 a, the Property isCurrency 20042 a, the Representation/Association term is Code 20043 a,the Type term is GDT 20044 a, and the Type Name term is CurrencyCode20045 a. The Cardinality between the PropertyDataType 20000 and theCurrencyCode 20039 a is zero or one 20046 a.

The ExponentialRepresentationTypeCode 20047 a is a type of exponentialrepresentation; see GDT ExponentialRepresentationTypeCode. For theExponentialRepresentationTypeCode 20047 a, the Category is Element 20048a, the Object Class is PropertyDataType 20049 a, the Property isExponentialRepresentationType 20049 a, the Representation/Associationterm is Code 20051 a, the Type term is GDT 20052 a, and the Type Nameterm is ExponentialRepresentationTypeCode 20053 a. The Cardinalitybetween the PropertyDataType 20000 and theExponentialRepresentationTypeCode 20047 a is zero or one 20054 a.

The ExponentIntegerValue 20055 a is an exponent value for exponentialrepresentation with predefined exponents. For the ExponentIntegerValue20055 a, the Category is Element 20056 a, the Object Class isPropertyDataType 20057 a, the Property is Exponent 20058 a, theRepresentation/Association Quality term is Integer 20059 a, theRepresentation/Association term is Value 20060 a, the Type term is GDT20061 a, and the Type Name term is IntegerValue 20062 a. The Cardinalitybetween the PropertyDataType 20000 and the ExponentIntegerValue 20055 ais zero or one 20063 a.

The IntervalValueAllowedIndicator 20064 a indicates whether or notinterval values are allowed (the interval is classed as one value in thevalue list.) The default value may be “false,” i.e., interval values arenot allowed. For the IntervalValueAllowedIndicator 20064 a, the Categoryis Element 20065 a, the Object Class PropertyDataType 20066 a, theProperty Quality term is Interval 20067 a, the Property is Value Allowed20068 a, the Representation/Association term is Indicator 20069 a, theType term is GDT 20070 a, and the Type Name term is Indicator 20071 a.The Cardinality between the PropertyDataType 20000 and theIntervalValueAllowedIndicator 20064 a is zero or one 20072 a.

The FractionalDigitPresentationAccuracyIndicator 20073 a indicateswhether or not the number of decimal places of numeric values followsthe entry under FractionalDigitsNumeric or the actual user entry.Example: three decimal places, entry 2.40; if this switch is not set,the entry is formatted as 2.400, if the switch is set, the formatremains as 2.40. The default value may be “false,” i.e.FractionalDigitsNumeric is deciding. For theFractionalDigitPresentationAccuracyIndicator 20073 a, the Category isElement 20074 a, the Object Class is PropertyDataType 20075 a, theProperty Quality term is Fractional Digit 20076 a, the Property isPresentation Accuracy 20077 a, the Representation/Association term isIndicator 20078 a, the Type term is GDT 20079 a, and the Type Name termis Indicator 20080 a. The Cardinality between the PropertyDataType 20000and the FractionalDigitPresentationAccuracyIndicator 20073 a is zero orone 20081 a.

The RegularExpression 20082 a is a formula that describes the data type,e.g., for a data type for density, this could indicate that the densityis the quotient of mass and volume. For the RegularExpression 20082 a,the Category is Element 20083 a, the Object Class is PropertyDataType20084 a, the Property is Regular Expression 20085 a, theRepresentation/Association term is Text 20086 a, the Type term is GDT20087 a, and the Type Name term is Note 20088 a. The Cardinality betweenthe PropertyDataType 20000 and the RegularExpression 20082 a is zero orone 20089 a.

The SeparatorUsageIndicator 20090 a indicates whether or not thousandseparators are to be used in numeric formats. The default value is“true”-thousand separators are used. For the SeparatorUsageIndicator20090 a, the Category is Element 20091 a, the Object Class isPropertyDataType 20092 a, the Property is Separator Usage 20093 a, theRepresentation/Association term is Indicator 20094 a, the Type term isGDT 20095 a, and the Type Name term is Indicator 20096 a. TheCardinality between the PropertyDataType 20000 and theSeparatorUsageIndicator 20090 a is zero or one 20097 a.

The TupelLengthValue 20098 a if the data type is used to record measuredvalues, minimum, maximum, and average values, e.g., need to be recorded,since a single value is generally not sufficient; these values have thesame format. In this case, the TupelLengthValue can be used to specifythat a value data set is required. In the example, a 3-tupel is requiredfor specifying values. If this attribute is not specified, the valuesare single values. For the TupelLengthValue 20098 a, the Category isElement 20099 a, the Object Class is PropertyDataType 20001 b, theProperty is Tupel Length 20002 b, the Representation/Association Qualityterm is Tupel Length 20003 b, the Representation/Association term isValue 20004 b, the Type term is GDT 20005 b, and the Type Name isTupelLengthValue 20006 b. The Cardinality between the PropertyDataType20000 and the TupelLengthValue 20098 a is zero or one 20007 b.

The ComponentPropertyDefinitionClassReference 20008 b is used in thecase of complex data types. This is the reference to the definitionclass (or to a version of the definition class) that contains the subproperties of the complex data type. If a definition class is not used,the properties contained are specified under ComponentPropertyReferenceinstead. For the ComponentPropertyDefinition ClassReference 20008 b, theCategory is Element 20009 b, the Object Class is PropertyDataType 20010b, the Property Quality term is Component 20011 b, the Property isProperty Definition Class Reference 20012 b, theRepresentation/Association term is PropertyDefinition ClassReference20013 b, the Type term is GDT 20014 b, and the Type Name term isPropertyDefinition ClassReference 20015 b. The Cardinality between thePropertyDataType 20000 and the ComponentPropertyDefinitionClassReference 20008 b is zero or one 20016 b.

The ComponentProperty 20017 b is in the case of complex data types,these are the properties that form the components of the complex datatype and the attributes related to this assignment. For theComponentProperty 20017 b, the Category is Element, the Object Class isPropertyDataType 20019 b, the Property Quality term is Component 20020b, the Property is Property Reference 20021 b, theRepresentation/Association term is PropertyReference 20022 b, the Typeterm is GDT 20023 b, and the Type Name is PropertyReference 20024 b. TheCardinality between the PropertyDataType 20000 and the ComponentProperty20017 b is zero or n 20025 b.

The ComponentPropertyReference 20026 b is if a complex data type ismodeled, but no definition class is used, these are the identifiers ofthe properties that form the complex data type. A complex data type maycontain at least two properties. For the ComponentProperty 20017 bReference 20026 b, the Category is Element 20027 b, the Object Class isComponentProperty 20028 b, the Property is Property Reference 20029 b,the Representation/Association term is PropertyReference 20030 b, theType term is GDT 20031 b, and the Type Name term is PropertyReference20032 b. The Cardinality between the PropertyDataType 20000 and theComponentProperty 20017 b Reference 20026 b is one 20033 b.

The PropertyOrdinalNumberValue 20034 b is a position of a given propertyin the list of component properties. The sequence of this property listis specified by the required display sequence of the properties. For theComponentProperty 20017 b OrdinalNumberValue 20034 b, the Category isElement 20035 b, the Object Class is ComponentProperty 20036, theProperty is Ordinal Number 20037 b, the Representation/Association termis Value 20038 b, the Type term is GDT 20039 b, and the Type Name termis OrdinalNumberValue 20040 b. The Cardinality between thePropertyDataType 20000 and the ComponentProperty 20017 bOrdinalNumberValue 20034 b is zero or one 20041 b.

The AllowedPropertyValueElement 20042 b is a data type value that isallowed in an evaluation of the associated property. If no value isspecified, there are no restrictions in terms of the values allowed inan evaluation (with the exception of the format specifications for thedata type). For the AllowedPropertyValueElement 20042 b, the Category isElement 20043 b, the Object Class is PropertyDataType 20044 b, theProperty Quality term is Allowed 20045 b, the Property isPropertyValueStructure 20046 b, and the Representation/Association termis Details 20047 b. The Cardinality between the PropertyDataType 20000and the AllowedPropertyValueElement 20042 b is from zero to n 20048 b.

The AllowedPropertyValue 20049 b is the value allowed. For theAllowedPropertyValueElement 20042 b PropertyValue 20049 b, the Categoryis Element 20050 b, the Object Class is PropertyValueStructure 20051 b,the Property is PropertyValue 20052 b, the Representation/Associationterm is PropertyValue 20053 b, the Type term is GDT 20054 b, and theType Name term is PropertyValue 20055 b. The Cardinality between thePropertyDataType 20000 and the AllowedPropertyValueElement 20042 bPropertyValue 20049 b is one 20056 b.

The DefaultValueIndicator 20057 b indicates whether or not the value orvalue interval is a standard value or standard value interval. Theformat and value range are defined by the GDT Indicator. The defaultvalue may be “false,” i.e., the value is not a standard value. For theAllowedPropertyValueElement 20042 b DefaultValueIndicator 20057 b, theCategory is Element 20058 b, the Object Class is PropertyValueStructure20059 b, the Property is DefaultValue 20060 b, theRepresentation/Association term is Indicator 20061 b, the Type term isGDT 20062 b, and the Type Name term is Indicator 20063 b. TheCardinality between the PropertyDataType 20000 and theAllowedPropertyValueElement 20042 b DefaultValueIndicator 20057 b iszero or one 20064 b.

The NetElementID 20065 b identifies the current value or value intervalin a value hierarchy. The ID is allocated sequentially in whole numbersin the value list. NetElementID is type CCT: Identifier. For theAllowedPropertyValueElement 20042 b NetElementID 20065 b, the Categoryis Element 20066 b, the Object Class is PropertyValueStructure 20067 b,the Property is NetElementIndentification 20068 b, theRepresentation/Association term is Identifier 20069 b, the Type term isCCT 20070 b, and the Type Name term is Identifier 20071 b. The Length isfive 20072. The Cardinality between the PropertyDataType 20000 and theAllowedPropertyValueElement 20042 b NetElementID 20065 b is zero or one20073 b.

The PreceedingNetElementID 20074 b identifies a preceding value orpreceding value interval in the value hierarchy. There can be severalpreceding values or value intervals. PreceedingNetElementID is type CCT:Identifier. For the PreceedingNetElementID 20074 b, the Category isElement, the Object Class is PropertyValueStructure 20076 b, theProperty Quality term is Preceding 20077 b, the Property isNetelmentIdentification 20078 b, the Representation/Association term isIdentifier 20079 b, the Type term is CCT 20080 b, and the Type Name termis Identifier 20081 b. The Length is five 20082 b. The Cardinalitybetween the PropertyDataType 20000 and the AllowedPropertyValueElement20042 b PreceedingNetElementID 20074 b is from zero to n 20083 b.

The AllowedPropertyValuation 20084 b is used if the data type is acomplex data type. It may not have a direct value list. The valuesallowed result from the valuation of the components of the complex datatype. This valuation is specified in AllowedPropertyValuation. For theAllowedPropertyValuation 20084 b, the Category is Element 20085 b, theObject Class is PropertyDataType 20086 b, the Property Quality term isAllowed 20087 b, the Property is Property Valuation 20088 b, theRepresentation/Association term is PropertyValuation 20089 b, the Typeterm is GDT 20090 b, and the Type Name is PropertyValuation 20091 b. TheCardinality between the PropertyDataType 20000 and theAllowedPropertyValuation 20084 b is from zero to n 20092 b.

See ISO13584/42 (Definition of data model for properties), availablefrom the GDT owner, for illustrative Integrity Conditions for 20000.

There are a number of consistency conditions for the individual fields;illustrative consistency conditions are: 1) aLanguageDependencyIndicator, which is for character format; 2) aMaximumTotalDigitNumber, which is exactly 1 for Boolean values and notset for character strings of unlimited length and complex data types; 3)a FractionalDigitsNumber for decimal numbers and exponential numbers.The FractionalDigitsNumber is shorter than the total length; 4) aLowerCaseAllowedIndicator for character format; 5) aNegativeValueAllowedIndicator for whole numbers, decimal numbers,exponential numbers, and currency format; 6)aExponentialRepresentationTypeCode for exponential format; 7) aExponentInteger for ExponentialRepresentationTypeCode equal to 02; 8) aIntervalValueAllowedIndicator for whole numbers, decimal numbers,exponential numbers, and currency format; 9) aFractionalDigitsPresentationAccuracyIndicator for decimal numbers andexponential numbers; 10) a SeparatorUsageIndicator for whole numbers,decimal numbers, exponential numbers, and currency format; 11) aTupelLengthNumber for integers, decimal numbers, and exponentialnumbers; 12) an AllowedPropertyValue which can be filled for simple datatypes; and 13) an AllowedPropertyValuation can be filled for complexdata types. If the data type contains a value list, the values containedin the list may satisfy the value syntax defined in the data type. Inthe case of complex data types, either the identifier for the area ofapplication (ComponentPropertyDefinitionClassReference) or the list ofthe components contained (ComponentPropertyReference) is used.

The data type is specified for a property in order to define its formatand allowed values. If the data type does not contain a value list, anyvalue that satisfies the format described in the data type is allowedfor the assigned property. A data type can be created explicitly with anexternal key. Such data types can be assigned to several properties.Alternatively, a data type can be created implicitly when a property iscreated; in this case, the data type can be used for this particularproperty and that it can be changed on the basis of this particularproperty.

The data type defined here is not to be confused with a DDIC data type.In a variation, it contains particular properties, does not cover all ofthe attributes of a DDIC data type, and is linked to ISO13584/42. Someelements that are mandatory in ISO13584/42 are optional in this scheme(such as, the optional use of the definition class in the case ofcomplex data types). This is provides wider use of the scheme. Theattribute Description corresponds to the attribute Note in ISO and theattribute UsageDescription 20069 corresponds to the attribute Remark inISO.

For the NetElementID 20065 b and the PreceedingNetElementID 20074 b,when the values allowed for the property are defined, they can bearranged in hierarchies in order to simplify navigation and valueselection. A value can have several predecessors. For example, thevalues of the property ‘country’ are to be arranged by continent. Forexample, Great Britain is to be grouped under North America as well asunder Europe. In an example, this would appear as shown in the followingtable: Value Index Value ID of Predecessor 1 Europe 2 North America 3Germany 1 4 US 2 5 Great Britain 1, 2

(jjjjjjj) PropertyDataTypeFormatCode

The GDT PropertyDataTypeFormatCode 20100 is a coded representation ofthe format of a property data type. An example of 20100 is:

<PropertyDataTypeFormatCode>date</PropertyDataTypeFormatCode>.

The structure of GDT PropertyDataTypeFormatCode 20100 is depicted inFIG. 201. For the GDT PropertyDataTypeFormatCode 20100, the Object Classis Property Data Type 20102, the Property is Format 20104, theRepresentation/Association term is Code 20106, the Type term is CCT20108, the Type Name term is Code 20110, and the Length is ten 20112.The GDT PropertyDataTypeFormatCode 20100 may be a restricted GDT.

The values for 20100 may come from the data type system defined by W3C(www.w3.org/TR/xmlschema-2/#built-in-datatypes). The list contains thosedata types of the W3C data type system that are used for classificationpurposes.

The Code Boolean has the Name Boolean and has the value space to supportthe mathematical concept of binary-valued logic: {true, false}.

The Code complex has the Name complex and is a data type comprisingseveral simple or complex data types.

The Code date has the Name date and represents a calendar date. Thevalue space of date is the set of Gregorian calendar dates as defined in§ 5.2.1 of [ISO 8601]. For example it may be a set of one-day long,non-periodic instances e.g. lexical 1999-10-26 to represent the calendardate 1999-10-26, independent of how many hours this day has.

The Code decimal has the Name decimal and represents arbitrary precisiondecimal numbers. The value space of decimal is the set of the valuesi×10ˆ−n, where i and n are integers such that n>=0. The order-relationon decimal is: x<y iff y−x is positive.

The Code float has the Name float and corresponds to the IEEEsingle-precision 32-bit floating point type [IEEE 754-1985]. The basicvalue space of float consists of the values m×2ˆe, where m is an integerwhose absolute value is less than 2ˆ24, and e is an integer from 149 to104, inclusive. In addition to the basic value space described above,the value space of float also contains the following special values:positive and negative zero, positive and negative infinity andnot-a-number. The order-relation on float is: x<y iff y−x is positive.Positive zero is greater than negative zero. Not-a-number equals itselfand is greater than all float values including positive infinity.

The Code integer has the Name integer and is derived from decimal byfixing the value of fractionDigits to be 0. This results in the standardmathematical concept of the integer numbers. The value space of integeris the infinite set { . . . ,−2,−1,0,1,2, . . . }. The base type ofinteger is decimal.

The Code string has the Name string and represents character strings inXML. The value space of string is the set of finite-length sequences ofcharacters (as defined in [XML 1.0 (Second Edition)]) that match theChar production from [XML 1.0 (Second Edition)]. A character is anatomic unit of communication; it is not further specified except to notethat every character has a corresponding Universal Character Set codepoint, which is an integer.

The Code time has the Name time and represents an instant of time thatrecurs every day. The value space of time is the space of time of dayvalues as defined in § 5.3 of [ISO 8601]. Specifically, it may be a setof zero-duration daily time instances.

The Code dateTime has the Name dateTime and represents a specificinstant of time. The value space of dateTime is the space ofCombinations of date and time of day values as defined in § 5.4 of [ISO8601].

The Code anyURI has the Name anyURI and represents a Uniform ResourceIdentifier Reference (URI). An anyURI value can be absolute or relative,and may have an optional fragment identifier (i.e., it may be a URIReference). This type should be used to specify the intention that thevalue fulfills the role of a URI as defined by [RFC 2396], as amended by[RFC 2732].

The type is used in the GDT PropertyDataType 20100. The Code establisheswhich formats are possible for a data type entry and how associatedvalues are transferred and stored. The valuations for the formats (e.g.,the number of decimal places) are specified in the GDT PropertyDataType20100.

(kkkkkkk) PropertyDataTypeID

A GDT PropertyDataTypeID 20200 is a unique identifier for a propertydata type. PropertyDataType is the data type of a property. It describesthe syntax of the property values and can contain a list of permittedvalues. An example of 20200 is:

<PropertyDataTypeID

schemeAgencyID=‘005’>MY_DATATYPE_(—)01</PropertyDataTypeID>.

The structure of GDT PropertyDataTypeID 20200 is depicted in FIG. 202.(See CCT Identifier). The GDT PropertyDataTypeID 20200 includesattributes SchemeAgencyID 20216, SchemeAgencySchemeID 20234, andschemeAgencySchemeAgencyID 20252. For the GDT PropertyDataTypeID 20200,the Object Class is Property Data Type 20202, the Property isIdentification 20204, the Representation/Association term is Identifier20206, the Type term is CCT 20208, the Type Name term is Identifier20210, and the Length is from one to fifty 20212. The GDTPropertyDataTypeID 20200 may be a restricted GDT.

For the SchemeAgencyID 20216, the Category is Attribute 20218, theObject Class is Identification Scheme-Agency 20220, the Property isIdentification 20222, the Representation/Association term is Identifier20224, the Type term is xsd 20226, the Type Name term is Token 20228,and the Length is from one to sixty 20230. The Cardinality between theGDT PropertyDataTypeID 20200 and the SchemeAgencyID 20216 is one 20232.For the SchemeAgencySchemeID 20234, the Category is Attribute 20236, theObject Class is Identification Scheme-Agency 20238, the Property isScheme 20240, the Representation/Association term is Identifier 20242,the Type term is xsd 20244, the Type Name term is Token 20246, and theLength is from one to sixty 20248. The Cardinality between the GDTPropertyDataTypeID 20200 and the SchemeAgencySchemeID 20234 is zero orone 20250.

For the schemeAgencySchemeAgencyID 20252, the Category is Attribute20254, the Object Class is Identification Scheme-Agency 20256, theProperty is Scheme Agency 20258, the Representation/Association term isIdentifier 20260, the Type term is xsd 20262, the Type Name term isToken 20264, and the Length is three 20266. The Cardinality between theGDT PropertyDataTypeID 20200 and the schemeAgencySchemeAgencyID 20252 iszero or one 20268.

The GDT is used to assign an independently defined data type to aproperty. The concept is defined in ISO13584/42.

The GDT PropertyDataTypeReference 20200 is used to reference a versionof a property data type.

Related GDTs are: PropertyID, Property, DefinitionClassID,DefinitionClass, PropertyValues, and PropertyValuation

(lllllll) PropertyDataTypeReference

A GDT PropertyDataTypeReference 20300 is a unique reference to aproperty data type or a version of a property data type.PropertyDataType is the data type of a property. It describes the syntaxof the property values and can contain a list of permitted values. Anexample of the 20300 is: <PropertyDataTypeReference>   <IDschemeAgencyID=“005”>MY_DATATYPE_01</ID>   <VersionID>1</VersionID></PropertyDataTypeReference>   (005=ISO).

The structure of GDT PropertyDataTypeReference 20300 is depicted in FIG.203. The GDT PropertyDataTypeReference 20300 includes elements ID andVersionID. For the GDT PropertyDataTypeReference 20300, the Object Classis Property Data Type Reference 20302 and the Representation/Associationterm is Details 20304.

The ID 20306 is the identifier of the property data type. For the ID20306, the Category is Element 20308, the Object Class is Property DataType Reference 20310, the Property is Identification 20312, theRepresentation/Association term is Identifier 20314, the Type term isGDT 20316, and the Type Name term is PropertyDataTypeID 20318. TheCardinality between the GDT PropertyDataTypeReference 20300 and the ID20306 is one.

The VersionID 20320 is the version of the property data type. For theVersionID 20320, the Category is Element 20322, the Object Class isProperty Data Type Reference 20324, the Property is VersionIdentification 20326, the Representation/Association term is Identifier20328, the Type term is GDT 20330, and the Type Name term is VersionID20332. The Cardinality between the GDT PropertyDataTypeReference 20300and the VersionID 20320 is zero or one 20334.

For information about the property data type, see GDT PropertyDataType20000.

(mmmmmmm) PropertyDefinitionClass

A GDT PropertyDefinitionClass 20400 is a class for defining propertiesin a classification system. A PropertyDefinitionClass 20400 defines asubject area. The properties defined in a PropertyDefinitionClassrepresent the attributes of this subject area. ThePropertyDefinitionClass 20400 is not used directly for classifyingobjects. For this purpose, classes are defined that use the propertiesdefined in a PropertyDefinitionClass 20400.

The PropertyValuation environment, and relationships to other objects,is discussed below.

“Simple” properties are described first. A property definition class cancontain one or more properties. A property can have property valuations,each of which assigns one or more property values to a property. Aproperty is typed by a property data type, which specifies the possibleproperty values for the property valuations. The values permitted by theproperty data type can be specified by listing the values in“PropertyValue.”

Complex properties can also be defined. A complex property data type canbe used to define a complex property by referencing to a propertydefinition class. The property definition class contains severalproperties that structure the complex property data type. The propertiesare then typed by property data types. Properties can also be definedwithout a property definition class. In this case, each property isdefined globally, i.e., the “area of application” of the properties isnot specified by the property definition class. A PropertyValuation isused to valuate properties for any objects, or to assign values toproperties.

An example or instance is:   <PropertyDefinitionClass>     <IDschemeAgencyID=“005”>SCREW_PROPERTIES</ID>     <VersionID>1</VersionID>    <PreferredName languageCode=‘EN’>       ‘Properties for screwdescription’     </PreferredName>     <ShortName languagecode=‘EN’>      ‘Screws’     </ShortName>     <DefinedProperty>       <Reference>        <ID schemeAgencyID=“005”>LENGTH</ID>        <VersionID>1</VersionID>         <DefinitionClassReference>          <ID>SCREW_PROPERTIES</ID>           <VersionID>1</VersionID>        </DefinitionClassReference>       </Reference>    </DefinedProperty>     <DefinedProperty>       <Reference>        <ID schemeAgencyID=“005”>HEAD_TYPE</ID>        <VersionID>1</VersionID>         <DefinitionClassReference>          <ID>SCREW_PROPERTIES</ID>           <VersionID>1</VersionID>        </DefinitionClassReference>       </Reference><SubHierarchyDefinitionIndicator>true</ SubHierarchyDefinitionIndicator>    </DefinedProperty>   </PropertyDefinitionClass>.

The structure of GDT PropertyDefinitionClass 20400 is depicted in FIG.204. The GDT PropertyDefinitionClass 20400 includes attributesActionCode 20402 and elements ID 20410, VersionID 20418, RevisionID20427, CreationDateTime 20436, VersionDateTime 20444, RevisionDateTime20452, PreferredName 20460, SynonymousName 20469, ShortName 20478,IconAttachement 20487, DefiningDescription 20496,SourceDocumentWebAddress 20406 a, AdditionalDescription 20415 a,UsageDescription 20424 a, TypeCode 20433 a, SimplifiedGraphicAttachement20441 a, SubjectAreaCode 20450 a, ParentPropertyDefinitionClassReference20459 a, Defined Property 20468 a, and HierarchyPropertyValuation 20407b. For the GDT PropertyDefinitionClass 20400, theRepresentation/Association term is Details 20401.

The ActionCode 20402 is an instruction to the recipient of a messagetelling it how to process a transmitted business object. For theActionCode 20402, the Category is Attribute 20403, the Object Class isProperty Definition Class 20404, the Property is Action 20405, theRepresentation/Association term is Code 20406, the Type term is GDT20407, and the Type Name term is ActionCode 20408. The Cardinalitybetween the GDT PropertyDefinitionClass 20400 and the ActionCode 20402is zero or one 20409.

The ID 20410 is an unique identifier of the definition class (see GDTPropertyDefinitionClassID). For the ID 20410, the Category is Element20411, the Object Class is Property Definition Class 20412, the Propertyis Identification 20413, the Representation/Association term isPropertyDefinitionClassID 20414, the Type term is GDT 20415, and theType Name term is PropertyDefinitionClassID 20416. The Cardinalitybetween the GDT PropertyDefinitionClass 20400 and the ID 20410 is zeroor one 20417.

The VersionID 20418 is an unique identifier for a version of thedefinition class. For the VersionID 20418, the Category is Element20419, the Object Class is Property Definition Class 20420, the Propertyis Version Identification 20421, the Representation/Association term isVersionID 20422, the Type term is GDT 20423, and the Type Name term isVersionID 20424. The Cardinality between the GDT PropertyDefinitionClass20400 and the VersionID 20418 is zero or one 20425.

The RevisionID 20426 is an unique identifier for a revision of thedefinition class. The RevisionID is a sequential number that is assignedwhen changes are made. For the RevisionID 20426, the Category is Element20427, the Object Class is Property Definition Class 20428, the Propertyis Revision Identification 20429, the Representation/Association term isIdentifier 20430, the Type term is CCT 20431, the Type Name term isIdentifier 20432, and the Length is from one to ten 20433. TheCardinality between the GDT PropertyDefinitionClass 20400 and theRevisionID 20426 is zero or one 20434. The RevisionID 20426 may berestricted.

The CreationDateTime 20436 is a creation date/time of the definitionclass. For the CreationDateTime 20436, the Category is Element 20437,the Object Class is Property Definition Class 20438, the Property isCreation Date Time 20439, the Representation/Association term isDateTime 20440, the Type term is GDT 20441, and the Type Name term isDateTime 20442. The Cardinality between the GDT PropertyDefinitionClass20400 and the CreationDateTime 20436 is zero or one 20443.

The VersionDateTime 20444 is a creation date/time of the definitionclass version. For the VersionDateTime 20444, the Category is Element20445, the Object Class is Property Definition Class 20446, the Propertyis Version Date Time 20447, the Representation/Association term isDateTime 20448, the Type term is GDT 20449, and the Type Name term isDateTime 20450. The Cardinality between the GDT PropertyDefinitionClass20400 and the VersionDateTime 20444 is zero or one 20451.

The RevisionDateTime 20452 is a date/time of the last change to thedefinition class that resulted in a RevisionID. For the RevisionDateTime20452, the Category is Element 20453, the Object Class is PropertyDefinition Class 20454, the Property is Revision Date Time 20455, theRepresentation/Association term is DateTime 20456, the Type term is GDT20457, and the Type Name term is DateTime 20458. The Cardinality betweenthe GDT PropertyDefinitionClass 20400 and the RevisionDateTime 20452 iszero or one 20459.

The PreferredName 20460 is a name of the definition class with, forexample, maximum one entry per language. For the PreferredName 20460,the Category is Element 20461, the Object Class is Property DefinitionClass 20462, the Property Quality term is Preferred 20463, the Propertyis Name 20464, the Representation/Association term is Name 20465, theType term is GDT 20466, and the Type Name term is Name 20467. TheCardinality between the GDT PropertyDefinitionClass 20400 and thePreferredName 20460 is one or n 20468.

The SynonymousName 20469 is a synonym for the definition class. Severalsynonyms can be specified for each language. For the SynonymousName20469, the Category is Element 20470, the Object Class is PropertyDefinition Class 20471, the Property Quality term is Synonymous 20472,the Property is Name 20473, the Representation/Association term is Name20474, the Type term is GDT 20475, the Type Name term is Name 20476. TheCardinality between the GDT PropertyDefinitionClass 20400 and theSynonymousName 20469 is from zero to n 20477.

The ShortName 20478 is a short name for definition class. A short namecan be entered for each language. For the ShortName 20478, the Categoryis Element 20479, the Object Class is Property Definition Class 20480,the Property Quality term is Short 20481, the Property is Name 20482,the Representation/Association term is Name 20483, the Type term is GDT20484, and the Type Name term is Name 20485. The Cardinality between theGDT PropertyDefinitionClass 20400 and the ShortName 20478 is from zeroto n 20486.

The IconAttachment 20487 is a preferred symbol or character(alphanumeric character, symbol, or combination thereof) for thedefinition class that represents the definition class in conformancewith international standards, particularly as “symbols” in formulas. Forthe IconAttachement 20487, the Category is Element 20488, the ObjectClass is Property Definition Class 20489, the Property Quality term isIcon 20490, the Property is Attachement 20491, theRepresentation/Association term is Attachement 20492, the Type term isGDT 20493, and the Type Name term is Attachement 20494. The Cardinalitybetween the GDT PropertyDefinitionClass 20400 and the IconAttachement20487 is zero or one 20495.

The DefiningDescription 20496 is an unique definition of the definitionclass's meaning makes it possible to uniquely distinguish the definitionclass from other definition classes. A definition can be entered foreach language. For the DefiningDescription 20496, the Category isElement 20497, the Object Class is Property Definition Class 20498, theProperty Quality term is Defining 20499, the Property is Description20401 a, the Representation/Association term is Description 20402 a, theType term is GDT 20403 a, and the Type Name term is Description 20404 a.The Cardinality between the GDT PropertyDefinitionClass 20400 and theDefiningDescription 20496 is from zero to n 20405 a.

The SourceDocumentWebAddress 20406 a is an address of a documentavailable on the Internet in which the definition of the definitionclass or its meaning can be found. For example, the URI schemes “http”and “https” may be permitted. For the SourceDocumentWebAddress 20406 a,the Category is Element 20407 a, the Object Class is Property DefinitionClass 20408 a, the Property Quality term is Source 20409 a, the Propertyis Document 20410 a, the Representation/Association term is WebAddress20411 a, the Type is CCT 20412 a, and the Type Name term is WebAddress20413 a. The Cardinality between the GDT PropertyDefinitionClass 20400and the SourceDocumentWebAddress 20406 a is zero or one 20414 a.

The AdditionalDescription 20415 a is an additional information aboutparts of the definition class; aids the understanding of the definitionclass. The description can extend the definition. For theAdditionalDescription 20415 a, the Category is Element 20416 a, theObject Class is Property Definition Class 20417 a, the Property Qualityterm is Additional 20418 a, the Property is Description 20419 a, theRepresentation/Association term is Description 20420 a, the Type term isGDT 20421 a, and the Type Name term is Description 20422 a. TheCardinality between the GDT PropertyDefinitionClass 20400 and theAdditionalDescription 20415 a is from zero to n 20423 a.

The UsageDescription 20424 a is a description of special aspectsconcerning the usage of the property. This can be explanatory text ofgeneral/individual notes. For the UsageDescription 20424 a, the Categoryis Element 20425 a, the Object Class is Property Definition Class 20426a, the Property Quality term is Usage 20427 a, the Property isDescription 20428 a, the Representation/Association term is Description20429 a, the Type term is GDT 20430 a, and the Type Name term isDescription 20431 a. The Cardinality between the GDTPropertyDefinitionClass 20400 and the UsageDescription 20424 a is fromzero to n 20432 a.

A TypeCode 20433 a is similar in its general description to GDTPropertyDefinitionClassTypeCode. For the TypeCode 20433 a, the Categoryis Element 20434 a, the Object Class is Property Definition Class 20435a, the Property is Type 20436 a, the Representation/Association term isCode 20437 a, the Type term is GDT 20438 a, and the Type Name term isPropertyDefinitionClassTypeCode 20439 a. The Cardinality between the GDTPropertyDefinitionClass 20400 and the TypeCode 20433 a is zero or one20440 a.

The SimplifiedGraphicAttachment 20441 a is a reference to a graphic thatillustrates the meaning of the definition class. For theSimplifiedGraphicAttachement 20441 a, the Category is Element 20442 a,the Object Class is Property Definition Class 20443 a, the PropertyQuality term is Simplified Graphic 20444 a, the Property is Attachement20445 a, the Representation/Association term is Attachement 20446 a, theType term is GDT 20447 a, and the Type Name term is Attachement 20448 a.The Cardinality between the GDT PropertyDefinitionClass 20400 and theSimplifiedGraphicAttachement 20441 a is zero or one 20449 a.

The SubjectAreaCode 20450 a is a subject area in accordance with theInternational Classification of Standards (see GDT SubjectAreaCode). Forthe SubjectAreaCode 20450 a, the Category is Element 20451 a, the ObjectClass is Property Definition Class 20452 a, the Property Quality term isTopic 20453 a, the Property is SubjectArea 20454 a, theRepresentation/Association term is Code 20455 a, the Type term is GDT20456 a, and the Type Name term is SubjectAreaCode 20457 a. TheCardinality between the GDT PropertyDefinitionClass 20400 and theSubjectAreaCode 20450 a is from zero to n 20458 a.

The ParentPropertyDefinitionClassReference 20459 a is an assignment tothe parent property definition class. In the case of versioning, theversion of this definition class is specified in the reference. For theParentPropertyDefinitionClassReference 20459 a, the Category is Element20460 a, the Object Class is Property Definition Class 20461 a, theProperty Quality term is Parent 20462 a, the Property is DefinitionClass Reference 20463 a, the Representation/Association term isPropertyDefinitionClassReference 20464 a, the Type term is GDT 20465 a,and the Type Name term is PropertyDefinitionClassReference 20466 a. TheCardinality between the GDT PropertyDefinitionClass 20400 and theParentPropertyDefinitionClassReference 20459 a is zero or one 20467 a.

The DefinedProperty 20468 a is the property defined in this definitionclass. For the DefinedProperty 20468 a, the Category is Element 20469 a,the Object Class is Property Definition Class 20470 a, the Property isDefined Property 20471 a, and the Representation/Association term isDetails 20472 a. The Cardinality between the GDT PropertyDefinitionClass20400 and the DefinedProperty 20468 a is from zero to n 20473 a.

The Reference 20474 a is an assignment to the parent property definitionclass. In versioning, the version of this definition class is indicatedin the reference. For the Reference 20474 a, the Category is Element20475 a, the Object Class is Defined Property 20476 a, the Property isReference 20477 a, the Representation/Association term isPropertyReference 20478 a, the Type term is GDT 20479 a, and the TypeName term is PropertyReference 20480 a. The Cardinality between the GDTPropertyDefinitionClass 20400 and the DefinedProperty 20468 a Reference20474 a is one or one 20481 a.

The OrdinalNumberValue 20482 a is the position of a property in theproperty list of a definition class. The sequence of the property listis given by the desired display sequence of the properties. For theOrdinal Number Value 20482 a, the Category is Element 20475 a, theObject Class is Defined Property 20476 a, the Property is Ordinal Number20485 a, the Representation/Association term is Value 20486 a, the Typeterm is GDT 20487 a, and the Type Name term is OrdinalNumberValue 20488a. The Cardinality between the GDT PropertyDefinitionClass 20400 and theDefinedProperty 20468 a Ordinal Number Value 20482 is zero or one 20489a.

The SubHierarchyDefinitionIndicator 20490 a indicates whether or not theproperty creates hierarchies for the subordinate hierarchy level (see“Constraints”). For the SubHierarchy DefinitionIndicator 20490 a, theCategory is Element 20491 a, the Object Class is Defined Property 20492a, the Property is SubHierarchy 20493 a, the Representation/Associationterm is Definition 20494 a, the Type term is CCT 20495 a, and the TypeName term is Indicator 20496 a. The Cardinality between the GDTPropertyDefinitionClass 20400 and the DefinedProperty 20468 aSubHierarchy DefinitionIndicator 20490 a is zero or one 20497 a.

The VisibilityIndicator 20498 a indicates whether the property can beused at the current hierarchy level or not. For the VisibilityIndicator20498 a, the Category is Element 20499 a, the Object Class is DefinedProperty 20401 b, the Property is Visibility 20402 b, theRepresentation/Association term is Indicator 20403 b, the Type term isCCT 20404 b, and the Type Name term is Indicator 20405 b. TheCardinality between the GDT PropertyDefinitionClass 20400 and theDefinedProperty 20468 a VisibilityIndicator 20498 a is zero or one 20406b.

The HierarchyPropertyValuation 20407 b is the value restriction for theproperties indicated in the parent definition class as able to createhierarchies (see Integrity Conditions). For theHierarchyPropertyValuation 20407 b, the Category is Element 20408 b, theObject Class is Property Definition Class 20409 b, the Property Qualityterm is Hierarchy 20410 b, the Property is Property Valuation 20411 b,the Representation/Association term is PropertyValuation 20412 b, theType term is GDT 20413 b, and the Type Name term is PropertyValuation20414 b. The Cardinality between the GDT PropertyDefinitionClass 20400and the HierarchyPropertyValuation 20407 b is from zero to n 20415 b.

See ISO13584/42 (Definition of data model for properties), availablefrom the GDT owner, for illustrative Integrity Conditions.

In particular with regard to the hierarchy, Integrity Conditions may beobserved in accordance with ISO13584/42. This form of hierarchy creationmay be used to formalize the creation rules and to store these rules inthe form of properties and their values. This prevents information frombecoming lost and enables the hierarchies to be created both explicitlyand transparently. The hierarchy may be strict (i.e., one predecessor)and without cycles.

-   -   If a definition class is to contain subordinate definition        classes, at least one of the properties contained in the class        may be indicated as able to create hierarchies. The data types        for these properties may contain value ranges. Value ranges may        be specified for all the properties that have been indicated in        the parent definition class as able to create hierarchies. Value        ranges of subordinate definition classes that are created in        this way for such a property may represent a decomposition of        the value range for the data type of the property that creates        hierarchies.    -   Properties can be created for a definition class, but should        first be available at lower hierarchy levels. In this case, the        VisibilityIndicator is set just at the desired hierarchy level.        Once the indicator has been set once for a given property, it        cannot be reset at lower hierarchy levels.    -   The ID of the definition class may be identical to the        definition class ID of the properties contained in the        class—this involves two different views for the same subject.    -   The definition class is used to group together related business        properties. Since the definition class belongs to the property        key, the definition class ‘AUTOLACKE’ (car paint) and the        definition class ‘TEXTILFARBEN’ (textile colors) can contain,        e.g., the ‘FARBE’ (color) property, this then involves two        different properties that can have different attributes.    -   The definition class is also used as a technical aid to group        together properties implicitly by business topic; e.g., the        properties of a Knowledge Base in the Internet Pricing        Configurator can each be mapped to one definition class. This        prevents conflicts between data with the same name but from        different Knowledge Bases. Another example of this would be        different instances of an SAP catalog that group together        different properties with the same name in different definition        classes. The definition class is the starting point for        distributing properties. The properties of given definition        class are distributed.    -   In contrast to ISO13584/42 and the Classification Management        Engine, the definition class is optional in the GDTs for        properties. This enables the GDTs to also be used in simple        scenarios and to connect external users who are new to this data        model. Some elements that are mandatory in ISO13584/42 are        optional in this scheme. This is intended to enable wider use of        the schema. In a variation, the definition class does not        correspond to the R/3 class in R/3 classification (see Comment).        The R/3 class can also group together the properties of a        subject area. However, a property may be used in different        classes. In that case, a property is defined in one definition        class. This means that properties cannot be mapped between the        concepts.

(nnnnnnn) PropertyDefinitionClassID

A GDT PropertyDefinitionClassID 20500 is a unique identifier for aproperty definition class. A GDT PropertyDefinitionClass 20500 is aclass for defining properties (in a classification system). APropertyDefinitionClass defines a subject area. The properties definedin a PropertyDefinitionClass represent the attributes of this subjectarea. An example or instance is:   <PropertyDefinitionClassIDschemeAgencyID=“005”>MY_DEF_CLASS_01</ PropertyDefinitionClassID>  (005=ISO).

The structure of GDT PropertyDefinitionClassID 20500 is depicted in FIG.205. The GDT PropertyDefinitionClassID 20500 includes attributesschemeAgencyID 20516, schemeAgencySchemeID 20532, andschemeAgencySchemeAgencyID 20550. For the GDT PropertyDefinitionClassID20500, the Object Class is Property Definition Class 20502, the Propertyis Identification 20504, the Representation/Association term isIdentifier 20506, the Type term is CCT 20508, the Type Name term isIdentifier 20510, and the Length is from one to fifty 20512. The GDTPropertyDefinitionClassID 20500 may be a restricted GDT.

For the schemeAgencyID 20516, the Category is Attribute 20518, theObject Class is IdentificationSchemeAgency 20520, the Property isIdentification 20522, the Representation/Association term is Identifier20524, the Type term is xsd 20526, the Type Name term is Token 20528,and the Length is from one to sixty 20530. The Cardinality between theGDT PropertyDefinitionClassID 20500 and the schemeAgencyID 20516 is one20531.

For the schemeAgencySchemeID 20532, the Category is Attribute 20534, theObject Class is IdentificationSchemeAgency 20536, the Property is Scheme20538, the Representation/Association term is Identifier 20540, the Typeterm is xsd 20542, the Type Name term is Token 20544, and the Length isfrom one to sixty 20546. The Cardinality between the GDTPropertyDefinitionClassID 20500 and the schemeAgencySchemeID 20532 iszero or one 20548.

For the schemeAgencySchemeAgencyID 20550, the Category is Attribute20552, the Object Class is IdentificationSchemeAgency 20554, theProperty is SchemeAgency 20556, the Representation/Association term isIdentifier 20558, the Type term is xsd 20560, the Type Name term isToken 20562, and the Length is three 20564. The Cardinality between theGDT PropertyDefinitionClassID 20500 and the schemeAgencySchemeAgencyID20550 is zero or one 20566.

If there are several schemes for an Agency (e.g., the organization“ISO,” “DIN,” or “Siemens”), the GDT may be extended to include theschemeID attribute. The concept is defined, for example, in ISO13584/42.The GDT PropertyDefinitionClassReference is used to reference a versionof a property definition class.

(ooooooo) PropertyDefinitionClassReference

A GDT PropertyDefinitionClassReference 20600 is a unique reference to aproperty definition class or to a version of a property definitionclass. A GDT PropertyDefinitionClass 20600 is a class for definingproperties (in a classification system). A GDT PropertyDefinitionClass20600 establishes a subject area. The properties defined in a GDTPropertyDefinitionClass 20600 map the attributes of this subject area.An example or instance is: <PropertyDefinitionClassReference>   <IDschemeAgencyID=“005”>SCREW_PROPERTIES</ID>   <VersionID>1</VersionID></PropertyDefinitionClassReference> (005=ISO).

The structure of GDT PropertyDefinitionClassReference 20600 is depictedin FIG. 206. The GDT PropertyDefinitionClassReference 20600 includeselements ID and VersionID. For GDT PropertyDefinitionClassReference20600, the Object Class is Property Definition Class Reference 20602 andthe Representation/Association term is Details 20604.

The ID 20606 is the identifier for the property definition class. Forthe ID 20606, the Category is Element 20606, the Object Class isProperty Definition Class Reference 20610, the Property isIdentification 20612, the Representation/Association term is Identifier20614, the Type term is GDT 20616, and the Type Name term isPropertyDefinitionClassID 20618. The Cardinality between the GDTPropertyDefinitionClassReference 20600 and the ID 20606 is one 20620.

The VersionID 20622 is the version for the property definition class.For the VersionID 20622, the Category is Element 20624, the Object Classis Property Definition Class Reference 20626, the Property is VersionIdentification 20628, the Representation/Association term is Identifier20630, the Type term is GDT 20632, and the Type Name term is VersionID20634. The Cardinality between the GDT PropertyDefinitionClassReference20600 and the VersionID 20622 is zero or one 20636.

For information about the property definition class, see the GDTPropertyDefinitionClass.

(ppppppp) PropertyDefinitionClassTypeCode

The DefinitionClassTypeCode 20700 is a coded representation of thenature of a definition class. This may be determined based on itsbusiness purpose, from which the attributes may be derived. An exampleor instance is:

<DefinitionClassTypeCode>M</DefinitionClassTypeCode>.

The structure of GDT DefinitionClassTypeCode 20700 is depicted in FIG.207. For the GDT DefinitionClassTypeCode 20700, the Object Class isDefinition Class Type 20702, the Representation/Association term is Code20704, the Type term is CCT 20706, the Type Name term is Code 20708, andthe Length is one 20710. The GDT DefinitionClassTypeCode 20700 may be arestricted GDT.

In a variation, the illustrative Codes in accordance with ISO13584/42that are permitted are as follows:

The Code I has the Name Item class. A definition class of this type cancontain properties of all the specializations described below.

The Code C has the Name Component class, which is an ‘Item class’specialization; the properties that are contained in this type ofdefinition class are used to describe assemblies based on theirassignment relationships.

The Code M has the Name Material class, which is an ‘Item class’specialization; the properties that are contained in this type ofdefinition class are used to describe basic materials, materials, andthe like, based on their physical attributes.

The Code F has the Name Feature class, which is an ‘Item class’specialization; the properties that are contained in this type ofdefinition class are used to describe objects based on their geometry,form, and function.

(qqqqqqq) PropertyID

A GDT PropertyID 20800 is a unique identifier for a property. A propertyis an object attribute. An example is: <PropertyIDschemeAgencyID=“005”>LENGTH</PropertyID>rue, (005=ISO).

The structure of GDT PropertyID 20800 is depicted in FIG. 208. The GDTPropertyID 20800 includes attributes schemeAgencyID 20816,schemeAgencySchemeID 20834, and schemeAgencySchemeAgencyID 20852. Forthe GDT PropertyID 20800, the Object Class is Property 20802, theProperty is Identification 20804, the Representation/Association term isIdentifier 20806, the Type term is CCT 20808, the Type Name term isIdentifier 20810, and the Length is from one to fifty 20812. The GDTPropertyID 20800 may be a restricted GDT.

For schemeAgencyID 20816, the Category is Attribute 20818, the ObjectClass is Identification Scheme-Agency 20820, the Property isIdentification 20822, the Representation/Association term is Identifier20824, the Type term is xsd 20826, the Type Name term is Token 20828,and the Length is from one to sixty 20830. The Cardinality between theGDT PropertyID 20800 and the schemeAgencyID 20816 is one or one 20832.

For the schemeAgencySchemeID 20834, the Category is Attribute 20836, theObject Class is Identification Scheme-Agency 20838, the Property isScheme 20840, the Representation/Association term is Identifier 20842,the Type term is xsd 20844, the Type Name term is Token 20846, and theLength is from one to sixty 20848. The Cardinality between the GDTPropertyID 20800 and the schemeAgencySchemeID 20834 is zero or one20850.

For the schemeAgencySchemeAgencyID 20852, the Category is Attribute20854, the Object Class is Identification Scheme-Agency 20856, theProperty is SchemeAgency 20858, the Representation/Association. term isIdentifier 20860, the Type term is xsd 20862, the Type Name term isToken 20864, and the Length is three 20866. The Cardinality between theGDT PropertyID 20800 and the schemeAgencySchemeAgencyID 20852 is zero orone 20868.

If a definition class is used, the schemeAgency may be identical to theschemeAgency of the identifier for the property definition class inwhich the property was defined (see GDT PropertyDefinitionClassID).

The concept is defined in ISO13584/42. Related GDTs to 20800 areProperty, PropertyDataTypeIdentification, PropertyDataType,DefinitionClassIdentification, DefinitionClass, PropertyValues, andPropertyValuation. The object corresponds to the BOR object BUS1088(characteristic) and to the Characteristic Management Engine property(CME property) from the new classification.

(rrrrrrr)PropertyMultipleValueIndicator

A GDT PropertyMultipleValueIndicator 20900 indicates whether or not aproperty can incorporate a list of values. An example is:<PropertyMultipleValueIndicator>true</PropertyMultipleValueIndicator>.

The structure of GDT PropertyMultipleValueIndicator 20900 is depicted inFIG. 209. For the GDT PropertyMultipleValueIndicator 20900, the ObjectClass is Property 20902, the Property is Multiple Value 20904, theRepresentation/Association term is Indicator 20906, and the Type term isIndicator 20908.

Valid illustrative values for 20900 are:

-   -   1) true, meaning several values can be assigned to the property;        and    -   2) false, meaning one value can be assigned to the property.        (For the value range, see CCT: Indicator)

(sssssss) PropertyParametricSearchableIndicator

A GDT PropertyParametricSearchableIndicator 21000 indicates whether aproperty is suitable for a parametric search or not. A parametric search(also called an ‘attribute search’) is a search for an object usingexplicit information about which values a property in the object is tocontain. For example, in the case of a parametric search for a redvehicle with 100 HP, the illustrative properties are:

-   -   1) a Color equal to “red;” and    -   2) a Performance equal to “100 HP,” which are specified        explicitly.

An example is:<PropertyParametricSearchableIndicator>true</PropertyParametricSearchableIndicator>.

The structure of GDT PropertyParametricSearchableIndicator 21000 isdepicted in FIG. 210. For the GDT PropertyParametricSearchableIndicator21000, the Object Class is Property 21002, the Property is ParametricSearchable 21004, the Representation/Association term is Indicator21006, the Type term is CCT 21008, and the Type Name term is Indicator21010.

Valid illustrative values for 21000 are:

-   -   1) true, meaning the property is suitable for a parametric        search; and    -   2) false, meaning the property is not suitable for a parametric        search. The GDT PropertyParametricSearchableIndicator 21000 is        used in the context of the property definition.

(ttttttt) PropertyReference

A GDT PropertyReference 21100 is a unique reference to a property or aversion of a property. The referenced property can have been defined ina property definition class. An example is: <PropertyReference>   <IDschemeAgencyID=“005”>LENGTH</ID>   <VersionID>1</VersionID>  <DefinitionClassReference>     <IDschemeAgencyID=“005”>SCREW_PROPERTIES</ID>   </DefinitionClassReference></PropertyReference> (005 = ISO).

The structure of GDT PropertyReference 21100 is depicted in FIG. 211.The GDT PropertyReference 21100 includes elements ID 21106, VersionID21122, and DefinitionClassReference 21138. For the GDT PropertyReference21100, the Object Class is Property Reference 21102 and theRepresentation/Association term is Details 21104.

The ID 21106 is the identifier for the property. For the ID 21106, theCategory is Element 21108, the Object Class is PropertyReference 21110,the Property is Identification 21112, the Representation/Associationterm is Identifier 21114, the Type term is GDT 21116, and the Type Nameis PropertyID 21118. The Cardinality between the GDT PropertyReference21100 and the ID 21106 is one or one 21120.

The VersionID 21122 is the version of the property. For the VersionID21122, the Category is Element 21124, the Object Class isPropertyReference 21126, the Property is Version Identification 21128,the Representation/Association term is VersionID 21130, the Type term isGDT 21132, and the Type Name term is VersionID 21134. The Cardinalitybetween the GDT PropertyReference 21100 and the VersionID 21122 is zeroor one 21136.

The DefinitionClassReference 21138 is the reference to the definitionclass (or to a version of the definition class) of the property. If areference exists, the property is unique within the specified definitionclass. For the DefinitionClassReference 21138, the Category is Element21140, the Object Class is PropertyReference 21142, the Property isDefinition Class Reference 21144, the Representation/Association term isDefinitionClassReference 21146, the Type term is GDT 21148, and the TypeName term is DefinitionClassReference 21150. The Cardinality between theGDT PropertyReference 21100 and the DefinitionClassReference 21138 iszero or one 21152.

If a definition class is used, the property issuer may be identical tothe issuer of the property definition class. The conceptual context ofthe PropertyReference is defined in ISO13584/42. Related GDTs for 21100are: Property, PropertyDataTypeIdentification, PropertyDataType,PropertyDefinitionClass, PropertyDefinitionClassID, PropertyValues, andPropertyValuation.

PropertyReference corresponds to the BOR object BUS1088 “Characteristic”and to the CME property from the new classification.

(uuuuuuu) PropertyValuation

The GDT PropertyValuation 21200 is the assignment of values to aproperty. A property valuation is performed for an object as part of theclassification procedure in order to describe its attributes. An exampleor instance is:

Valuation of a property with a simple data type:     <PropertyValuation>      <PropertyReference>         <ID>LENGTH</ID>        <DefinitionClassReference>           <ID>SCREW_PROPERTIES</ID>          <Version>1</Version>         <DefinitionClassReference>      <PropertyReference>       <PropertyValue>        <MeasureSpecification>           <MeasureunitCode=“12”>3</Measure>         </MeasureSpecification>      <PropertyValue>     </PropertyValuation>   unitCode=“12”corresponds to centimeters in accordance with UN/CEFACT Rec. #20 (Unitsof Measure)

Valuation of a property with a complex data type:

The ‘VERBRAUCHSPROFIL’ (consumption profile) property consists of the‘STRASSENTYP’ (street type) and ‘VERBRAUCH’ (consumption) properties.The data type of the ‘VERBRAUCHSPROFIL’ property has a complex formatand references the ‘AUTOS’ (cars) definition class that contains thecomponent properties.

Complex (grouping) property ‘VERBRAUCHSPROFIL’:     <PropertyValuation>      <ID>1</ID>       <PropertyReference>        <ID>VERBRAUCHSPROFIL</ID>         <DefinitionClassReference>          <ID>AUTOS</ID>         </DefinitionClassReference>      </PropertyReference>     </PropertyValuation>   Property‘STRASSENTYP’:     <PropertyValuation>       <ID>2</ID>      <ParentID>1</ParentID>       <PropertyReference>        <ID>STRASSENTYP</ID>         <DefinitionClassReference>          <ID>VERBRAUCHSTYP</ID>         </DefinitionClassReference>      </PropertyReference>       <PropertyValue>        <NameSpecification>           <Name>LANDSTRASSE</Name>        </NameSpecification>       </PropertyValue>    </PropertyValuation>   Property ‘VERBRAUCH’:     <PropertyValuation>      <ID>3</ID>       <ParentID>1</ParentID>       <PropertyReference>        <ID>VERBRAUCH</ID>         <DefinitionClassReference>          <ID>VERBRAUCHSTYP</ID>         </DefinitionClassReference>      </PropertyReference>       <PropertyValue>        <MeasureSpecification>           <MeasureunitCode”49”>5</Measure>         </MeasureSpecification>      </PropertyValue>     </PropertyValuation>   unitCode=“49”corresponds to liters in accordance with UN/CEFACT Rec. #20 (Units ofMeasure)

The structure of GDT Property Valuation 21200 is depicted in FIG. 212.The GDT Property Valuation 21200 includes attribute ActionCode 21206 andelements ID 21222, ParentID 21240, PropertyReference 21258, andPropertyValue 21274. For the GDT Property Valuation 21200, the ObjectClass is Property Valuation 21202 a and the Representation/Associationterm is Details 21204.

The ActionCode 21206 is an instruction to the recipient of a messageabout how to process a transmitted property. For the ActionCode 21206,the Category is Attribute 21208, the Object Class is Property Valuation21210, the Property is Action 21212, the Representation/Association termis Code 21214, the Type term is GDT 21216, and the Type Name term isActionCode 21218. The Cardinality between the GDT Property Valuation21200 and the ActionCode 21206 is zero or one 21220.

The ID 21222 is an unique identifier of the property valuation. Theattribute may be used for valuating properties with a complex data type.ID is unique in the context of the valuated object. For the ID 21222,the Category is Element 21224, the Object Class is Property Valuation21226, the Property is Identification 21228, theRepresentation/Association term is Identifier 21230, the Type term isCCT 21232, the Type Name term is Identifier 21234, and the Length isfrom one to ten 21236. The Cardinality between the GDT PropertyValuation 21200 and the ID 21222 is zero or one 21238.

The ParentID 21240 is an identifier for the property valuation (for thevaluation of a complex data type) that is a parent to the currentproperty valuation. For the ParentID 21240, the Category is Element21242, the Object Class is Property Valuation 21244, the Property isParent Identification 21246, the Representation/Association term isIdentifier 21248, the Type term is CCT 21250, the Type Name term isIdentifier 21252, and the Length is from one to ten 21254. TheCardinality between the GDT Property Valuation 21200 and the ParentID21240 is zero or one 21256.

The PropertyReference 21258 is a reference to the underlying propertyfor which the property valuation is mapped. For the PropertyReference21258, the Category is Element 21260, the Object Class is PropertyValuation 21262, the Property is Property Reference 21264, theRepresentation/Association term is Reference 21266, the Type term is GDT21268, and the Type Name term is PropertyReference 21270. TheCardinality between the GDT Property Valuation 21200 and thePropertyReference 21258 is one 21272.

The PropertyValue 21274 is a value of the above property. For thePropertyValue 21274, the Category is Element 21276, the Object Class isProperty Valuation 21278, the Property is Property Value 21280, theRepresentation/Association term is Property Value 21282, the Type termis GDT 21284, and the Type Name term is PropertyValue 21286. TheCardinality between the GDT Property Valuation 21200 and thePropertyValue 21274 is from zero to n 21288.

See ISO13584/42 (Definition of data model for properties) available fromthe GDT owner, for illustrative integrity conditions for 21200. Thevaluations may correspond to the formats specified by the data type (seeGDT: PropertyDataType) of the valuated property (see GDT: Property). Ifthe data type contains a value list, valuations may be included in thisvalue list. The number of property values in the valuation may generallycorrespond to the value assignment type (any, as required) defined inthe property. These integrity conditions apply in the case of a finalactual valuation and not in the case of specifications for a finalvaluation. In this case, the valuation restricts the permitted valuerange of the property. An example of this is the valuation of a batchmaterial that merely specifies the valuation range for the actualbatches. Several valuations can also be specified for single-valueproperties. In a variation, a property with a complex data type may notbe valuated directly. However, the components of its data type can be.In this case, PropertyValue 21274 is empty. PropertyValue 21274 isfilled for the relevant components and the ParentID 21240 contains theID 21222 of the parent property with the complex data type.

PropertyValuation is used by classified objects such as, e.g., batch: aproperty valuation consists of the key of the property to be valuatedand the associated values. Thus, e.g., if the ‘color’ (property) of abatch is ‘red’ (value) or its ‘weight’ (property) is ‘5 kg’ (value,) thecombination of property and value constitutes the property valuation.PropertyValuation is also used for a formal description of the creationof definition class hierarchies (See GDT PropertyDefinitionClass).

(vvvvvvv) PropertyValuationRequiredIndicator

A GDT PropertyValuationRequiredIndicator 21300 indicates whether or nota value has to be specified for a property. An example is:

<PropertyValuationRequiredIndicator>true</PropertyValuationRequiredIndicator>.

The structure of GDT PropertyValuationRequiredIndicator 21300 isdepicted in FIG. 213. For the GDT PropertyValuationRequiredIndicator21300, the Object Class is Property 21302, the Property is ValuationRequired 21304, the Representation/Association term is Indicator 21306,the Type term is CCT 21308, and the Type Name term is Indicator 21310.

Valid illustrative values for 21300 are 1) true, meaning that a valuemay be specified; or 2) false, meaning that a value does not have to bespecified. For the value range, see CCT: Indicator.

(wwwwww) PropertyValue

A GDT PropertyValue 21400 describes a value that can be assigned to aproperty. The value can also be an interval. An example is:<PropertyValue>   <IntegerSpecification>     <Value>1</Value>  </IntegerSpecification>   <PreferredNamelanguageCode=“DE”>Eins</PreferedName>   <PreferredNamelanguageCode=“EN”>one</PreferedName> </PropertyValue>.

The structure GDT Property Value 21400 is depicted in FIG. 214. The GDTProperty Value 21400 includes elements AmountSpecification 21404,QuantitySpecification 21436, DecimalSpecification 21468,FloatSpecification 21404 a, IntegerSpecification 21439 a,DateSpecification 21474 a, TimeSpecification 21404 b,DateTimeSpecification 21433 b, NameSpecification 21462 b,IndicatorSpecification 21476 b, and IntervalTypeCode 21490 b. For theGDT Property Value 21400, the Category is Element 21401, the ObjectClass is Property Value 21402, and the Representation/Association termis Details 21403.

The AmountSpecification 21404 contains the specification ofcurrency-based values (amounts). For the AmountSpecification 21404, theCategory is Element 21405, the Object Class is Property Value 21406, theProperty is Amount Specification 21407, and theRepresentation/Association term is Details 21408. The Cardinalitybetween the GDT Property Value 21400 and the AmountSpecification 21404is zero or one 21409.

The Amount 21410 is a discrete, currency-based single value or amount.The Amount 21410 is of type GDT: Amount. For the Amount 21410, theCategory is Element 21411, the Object Class is Amount Specification21412, the Property is Amount 21413, the Representation/Association termis Amount 21414, the Type term is GDT 21415, and the Type Name term isAmount 21416. The Cardinality between the GDT Property Value 21400 andthe AmountSpecification 21404 Amount 21410 is between zero or one 21417.

The LowerAmount 21418 is a lower limit in a currency-based valueinterval. The LowerAmount 21418 is of type GDT: Amount. For theLowerAmount 21418, the Category is Element 21419, the Object Class isAmount Specification 21420, the Property Quality term is Lower 21421,the Property is Amount 21422, the Representation/Association term isAmount 21423, the Type term is GDT 21424, and the Type Name term isAmount 21425. The Cardinality between the GDT Property Value 21400 andthe AmountSpecification 21404 LowerAmount 21418 is zero or one 21426.

The UpperAmount 21427 is an upper limit in a currency-based valueinterval. The UpperAmount is of type GDT: Amount. For the UpperAmount21427, the Category is Element 21428, the Object Class is amountSpecification 21429, the Property Quality term is Upper 21430, theProperty is Amount 21431, the Representation/Association term is Amount21432, the Type term is GDT 21433, and the Type Name term is Amount21434. The Cardinality between the GDT Property Value 21400 and theAmountSpecification 21404 UpperAmount 21427 is zero or one 21435.

The QuantitySpecification 21436 contains the specification of quantitiesin a unit of measurement/measure. For the QuantitySpecification 21436,the Category is Element 21437, the Object Class is Property Value 21438,the Property is Quantity Specification 21439, and theRepresentation/Association term is Details 21440. The Cardinalitybetween the GDT Property Value 21400 and the QuantitySpecification 21436is zero or one 21441.

The Quantity 21442 is an individual quantity in a unit of measurement.The Quantity 21442 is of type GDT: Quantity. For the Quantity 21442, theCategory is Element 21443, the Object Class is Quantity Specification21444, the Property is Quantity 21445, the Representation/Associationterm is Quantity 21446, the Type term is GDT 21447, and the Type Nameterm is Quantity 21448. The Cardinality between the GDT Property Value21400 and the QuantitySpecification 21436 Quantity 21442 is zero or one21449.

The LowerQuantity 21450 is a lower limit in a quantity interval. TheLowerQuantity 21450 is of type GDT: Quantity. For the LowerQuantity21450, the Category is Element 21451, the Object Class is QuantitySpecification 21452, the Property Quality term is Lower 21453, theProperty is Quantity 21454, the Representation/Association term isQuantity 21455, the Type term is GDT 21456, and the Type Name term isQuantity 21457. The Cardinality between the GDT Property Value 21400 andthe LowerQuantity 21450 is zero or one 21458.

The UpperQuantity 21459 is an upper limit in a quantity interval. TheUpperQuantity 21459 is of type GDT: Quantity. For the UpperQuantity21459, the Category is Element 21460, the Object Class is QuantitySpecification 21461, the Property Quality term is Upper 21462, theProperty is Quantity 21463, the Representation/Association term isQuantity 21464, the Type term is GDT 21465, and the Type Name term isQuantity 21466. The Cardinality between the GDT Property Value 21400 andthe UpperQuantity 21459 is zero or one 21467.

The DecimalSpecification 21468 contains the specification of decimalnumbers. For the DecimalSpecification 21468, the Category is Element21469, the Object Class is Property Value 21470, the Property is NumericSpecification 21471, and the Representation/Association term is Details21472. The Cardinality between the GDT Property Value 21400 and theDecimalSpecification 21468 is zero or one 21473.

The DecimalValue 21474 is a discrete decimal value. The DecimalValue21474 is of type GDT: DecimalValue. For the DecimalValue 21474, theCategory is Element 21475, the Object Class is Decimal Specification21476, the Property is Decimal Value 21477, theRepresentation/Association Quality term is Decimal 21478, theRepresentation/Association term is Value 21479, the Type term is GDT21480, and the Type Name term is DecimalValue 21481. The Cardinalitybetween the GDT Property Value 21400 and the DecimalValue 21474 is zeroor one 21482.

The LowerDecimalValue 21483 is a lower limit in a value interval ofdecimal values. The LowerDecimalValue 21483 is of type GDT:DecimalValue. For the LowerDecimalValue 21483, the Category is Element21484, the Object Class is Decimal Specification 21485, the PropertyQuality term is Lower 21486, the Property is Decimal Value 21487, theRepresentation/Association Quality term is Decimal 21488, theRepresentation/Association term is Value 21489, the Type term is GDT21490, and the Type Name term is DecimalValue 21491. The Cardinalitybetween the GDT Property Value 21400 and the LowerDecimalValue 21483 iszero or one 21492.

The UpperDecimalValue 21493 is an upper limit in a value interval ofdecimal values. The UpperDecimalValue 21493 is of type GDT:DecimalValue. For the UpperDecimalValue 21493, the Category is Element21494, the Object Class is Decimal Specification 21495, the PropertyQuality term is Upper 21496, the Property is Decimal Value 21497, theRepresentation/Association Quality term is Decimal 21498, theRepresentation/Association term is Value 21499, the Type term is GDT21401, and the Type Name term is DecimalValue 21402 a. The Cardinalitybetween the GDT Property Value 21400 and the UpperDecimalValue 21493 iszero or one 21403 a.

The FloatSpecification 21404 a contains the specification of thefloating point values. For the FloatSpecification 21404 a, the Categoryis Element 21405 a, the Object Class is Property Value 21406 a, theProperty is Float Specification 21407 a, and theRepresentation/Association term is Details 21408 a. The Cardinalitybetween the GDT Property Value 21400 and the FloatSpecification 21404 ais zero or one 21409 a.

The FloatValue 21410 a is a discrete floating point value. TheFloatValue is type GDT: FloatValue. For the FloatValue 21410 a, theCategory is Element 21411 a, the Object Class is Float Specification21412 a, the Property is FloatValue 21413 a, theRepresentation/Association Quality term is Float 21414 a, theRepresentation/Association term is Value 21415 a, the Type term is GDT21416 a, and the Type Name term is FloatValue 21417 a. The Cardinalitybetween the GDT Property Value 21400 and the FloatValue 21410 a is zeroor one 21418 a.

The LowerFloatValue 21419 a is a lower limit in a value interval offloating point values. The LowerFloatValue 21419 a is of type GDT:FloatValue. For the LowerFloatValue 21419 a, the Category is Element21420 a, the Object Class is Float Specification 21421 a, the PropertyQuality term is Lower 21422 a, the Property is Float Value 21423 a, theRepresentation/Association Quality term is Float 21424 a, theRepresentation/Association term is Value 21425 a, the Type term is GDT21426 a, and the Type Name term is FloatValue 21427 a. The Cardinalitybetween the GDT Property Value 21400 and the LowerFloatValue 21419 a iszero or one 21428 a.

The UpperFloatValue 21429 a is an upper limit in a value interval offloating point values. The UpperFloatValue 21429 a is of type GDT:FloatValue. For the UpperFloatValue 21429 a, the Category is Element21430 a, the Object Class is Float Specification 21431 a, the PropertyQuality term is Upper 21432 a, the Property is Float Value 21433 a, theRepresentation/Association Quality term is Float 21434 a, theRepresentation/Association term is Value 21435 a, the Type term is GDT21436 a, and the Type Name term is FloatValue 21437 a. The Cardinalitybetween the GDT Property Value 21400 and the UpperFloatValue 21429 a iszero or one 21438 a.

The IntegerSpecification 21439 a contains the specification of integervalues. For the IntegerSpecification 21439 a, the Category is Element21440 a, the Object Class is Property Value 21441 a, the Property isInteger Specification 21442 a, and the Representation/Association termis Details 21443 a. The Cardinality between the GDT Property Value 21400and the IntegerSpecification 21439 a is zero or one 21444 a.

The IntegerValue 21445 a is a discrete integer value. The IntegerValue21445 a is of type GDT: IntegerValue. For the IntegerValue 21445 a, theCategory is Element 21446 a, the Object Class is Integer Specification21447 a, the Property is Integer Value 21448 a, theRepresentation/Association Quality term is Integer 21449 a, theRepresentation/Association term is Value 21450 a, the Type term is GDT21451 a, and the Type Name term is IntegerValue 21452 a. The Cardinalitybetween the GDT Property Value 21400 and the IntegerValue 21445 a iszero or one 21453 a.

The LowerIntegerValue 21454 a is a lower limit in a value interval ofinteger values. The LowerIntegerValue 21454 a is of type GDT:IntegerValue. For the LowerIntegerValue 21454 a, the Category is Element21455 a, the Object Class is Integer Specification 21456 a, the PropertyQuality term is Lower 21457 a, the Property is Integer Value 21458 a,the Representation/Association Quality term is Integer 21459 a, theRepresentation/Association term is Value 21460 a, the Type term is GDT21461 a, and the Type Name term is IntegerValue 21462 a. The Cardinalitybetween the GDT Property Value 21400 and the LowerIntegerValue 21454 ais zero or one 21463 a.

The UpperIntegerValue 21464 a is an upper limit in a value interval ofinteger values. The UpperIntegerValue 21464 a is of type GDT:IntegerValue. For the UpperIntegerValue 21464 a, the Category is Element21465 a, the Object Class is Integer Specification 21466 a, the PropertyQuality term is Upper 21467 a, the Property is Integer Value 21468 a,the Representation/Association Quality term is Integer 21469 a, theRepresentation/Association term is Value 21470 a, the Type term is GDT9971, and the Type Name term is IntegerValue 21472 a. The Cardinalitybetween the GDT Property Value 21400 and the UpperIntegerValue 21464 ais zero or one 21473 a.

The DateSpecification 21474 a contains the specification of calendardays or date intervals. For the DateSpecification 21474 a, the Categoryis Element 21475 a, the Object Class is Property Value 21476 a, theProperty is Date Specification 21477 a, and theRepresentation/Association term is Details 21478 a. The Cardinalitybetween the GDT Property Value 21400 and the DateSpecification 21474 ais zero or one 21479 a.

The Date 21480 a is a calendar day. The Date 21480 a is of type GDT:Date. For the Date 21480 a, the Category is Element 21481 a, the ObjectClass is Date Specification 21482 a, the Representation/Association termis Date 21483 a, the Type term is GDT 21484 a, and the Type Name term isDate 21485 a. The Cardinality between the GDT Property Value 21400 andthe Date 21480 a is zero or one 21486 a.

The StartDate 21487 a is a date that defines the start of a daily timeinterval. The StartDate 21487 a is of type GDT: Date. For the StartDate21487 a, the Category is Element 21488 a, the Object Class is DateSpecification 21489 a, the Property is Start 21490 a, theRepresentation/Association term is Date 21491 a, the Type term is GDT21492 a, and the Type Name term is Date 21493 a. The Cardinality betweenthe GDT Property Value 21400 and the StartDate 21487 a is zero or one21494 a.

The EndDate 21495 a is a date that defines the end of a daily timeinterval. The EndDate 21495 a is of type GDT: Date. For the EndDate21495 a, the Category is Element 21496 a, the Object Class is DateSpecification 21497 a, the Property is End 21498 a, theRepresentation/Association term is Date 21499 a, the Type term is GDT21401 b, and the Type Name term is Date 21402 b. The Cardinality betweenthe GDT Property Value 21400 and the EndDate 21495 a is zero or one21403 b.

The TimeSpecification 21404 b contains the specification, accurate tothe second, of a particular time or time interval (time span). For theTimeSpecification 21404 b, the Category is Element 21405 b, the ObjectClass is PropertyValue 21406 b, the Property is Time Specification 21407b, and the Representation/Association term is Details 21408 b. TheCardinality between the GDT Property Value 21400 and theTimeSpecification 21404 b is zero or one 21409 b.

The Time 21410 b is a particular time, accurate to the second. The Time21410 b is of type GDT: Time. For the Time 21410 b, the Category isElement 21411 b, the Object Class is Time Specification 21412 b, theRepresentation/Association term is Time 21413 b, the Type term is GTD21414 b, and the Type Name term is Time 21415 b. The Cardinality betweenthe GDT Property Value 21400 and the Time 21410 b is zero or one 21416b.

The StartTime 21417 b is a time that defines the start of a particulartime interval, accurate to the second. The StartTime 21417 b is of typeGDT: Time. For the StartTime 21417 b, the Category is Element 21418 b,the Object Class is Time Specification 21419 b, the Property is Start21420 b, the Representation/Association term is Time 21421 b, the Typeterm is GDT 21422 b, and the Type Name term is Time 21423 b. TheCardinality between the GDT Property Value 21400 and the StartTime 21417b is zero and one 21424 b.

The EndTime 21425 b is a time that defines the end of a particular timeinterval, accurate to the second. The EndTime 21425 b is of type GDT:Time. For the EndTime 21425 b, the Category is Element 21426 b, theObject Class is Time Specification 21427 b, the Property is End 21428 b,the Representation/Association term is Time 21429 b, the Type term isGDT 21430 b, and the Type Name term is Time 21431 b. The Cardinalitybetween the GDT Property Value 21400 and the EndTime 21425 b is zero orone 21432 b.

The DateTimeSpecification 21433 b contains the specification of timestamps (date and time), accurate to the second, or the specification ofa timeframe, accurate to the second. For the DateTimeSpecification 21433b, the Category is Element 21434 b, the Object Class is Property Value21435 b, the Property is Date Time Specification 21436 b, and theRepresentation/Association term is Details 21437. The Cardinalitybetween the GDT Property Value 21400 and the DateTimeSpecification 21433b is zero or one 21438 b.

The DateTime 21439 b is a time stamp (date and time), accurate to thesecond. The DateTime 21439 b is of type GDT: DateTime. For the DateTime21439 b, the Category is Element 21440 b, the Object Class is Date TimeSpecification 21441 b, the Representation/Association term is Date Time21442 b, the Type term is GDT 21443 b, and the Type Name term isDateTime 21444 b. The Cardinality between the GDT Property Value 21400and the DateTime 21439 b is zero or one 21445 b.

The StartDateTime 21446 b is a time stamp that defines the start of atime interval or timeframe. The StartDateTime 21446 b is of type GDT:DateTime. For the StartDateTime 21446 b, the Category is Element 21447b, the Object Class is Date Time Specification 21448 b, the Property isStart 21449 b, the Representation/Association term is Date Time 21450 b,the Type term is GDT 21451 b, and the Type Name is DateTime 21452 b. TheCardinality between the GDT Property Value 21400 and the StartDateTime21446 b is zero or one 21453 b.

The EndDateTime 21454 b is a time stamp that defines the end of a timeinterval or timeframe. The EndDateTime 21454 b is of type GDT: DateTime.For the EndDateTime 21454 b, the Category is Element 21455 b, the ObjectClass is Date Time Specification 21456 b, the Property is End 21457 b,the Representation/Association term is Date Time 21458 b, the Type termis GDT 21459 b, and the Type Name term is DateTime 21460 b. TheCardinality between the GDT Property Value 21400 and the EndDateTime21454 b is zero or one 21461 b.

The NameSpecification 21462 b contains the specification of qualitativeand human-readable values. For the NameSpecification 21462 b, theCategory is Element 21463 b, the Object Class is Property Value 21464 b,the Property is Name Specification 21465 b, and theRepresentation/Association term is Details 21466 b. The Cardinalitybetween the GDT Property Value 21400 and the NameSpecification 21462 bis zero or one 21467 b.

The Name 21468 b is an individual qualitative and human-readable value.The Name 21468 b is of type GDT: Name. For the Name 21468 b, theCategory is Element 21469 b, the Object Class is Name Specification21470 b, the Property is Name 21471 b, the Representation/Associationterm is Name 21472 b, the Type term is GDT 21473 b, and the Type Nameterm is Name 21474 b. The Cardinality between the GDT Property Value21400 and the Name 21468 b is zero or one 21475 b.

The IndicatorSpecification 21476 b contains the specification of binarylogical values (such as, yes and no). For the IndicatorSpecification21476 b, the Category is Element 21477 b, the Object Class is PropertyValue 21478 b, the Property is Indicator Specification 21479 b, and theRepresentation/Association term is Details 21480 b. The Cardinalitybetween the GDT Property Value 21400 and the IndicatorSpecification21476 b is zero or one 21481 b.

The Indicator 21482 b is an individual binary logical value. TheIndicator 21482 b is of type GDT: Indicator. For the Indicator 21482 b,the Category is Element 21483 b, the Object Class is IndicatorSpecification 21484 b, the Property is Indicator 21485 b, theRepresentation/Association term is Indicator 21486 b, the Type term isGDT 21487 b, and the Type Name term is Indicator 21488 b. TheCardinality between the GDT Property Value 21400 and the Indicator 21482b is zero or one 21489 b.

The IntervalTypeCode 21490 b is a coded representation for typingintervals. The IntervalTypeCode 21490 b is of type GDT:IntervalTypeCode. For the IntervalTypeCode 21490 b, the Category isElement 21491 b, the Object Class is Property Value 21492 b, theProperty is Interval Type 21493 b, the Representation/Association termis Code 21494 b, the Type term is GDT 21495 b, and the Type Name term isIntervalTypeCode 21496 b. The Cardinality between the GDT Property Value21400 and the IntervalTypeCode 21490 b is zero or one 21497 b.

The PreferredName 21498 b is a name of the value or value interval, ifone exists. The PreferredName 21498 b is of type GDT: Name. For thePreferredName 21498 b, the Category is Element 21499 b, the Object Classis Property Value 21401 c, the Property is Preferred Name 21402 c, theRepresentation/Association term is Name 21403 c, the Type term is GDT21404 c, and the Type Name is Name 21405 c. The Cardinality between theProperty Value 21400 and the PreferredName 21498 b is from zero to n21406 c.

The SynonymousName 21407 c is a synonymous term for the PreferredName.The SynonymousName 21407 c is of type GDT: Name. For the SynonymousName21407 c, the Category is Element 21408 c, the Object Class is PropertyValue 21409 c, the Property is Synonymous Name 21410 c, theRepresentation/Association term is Name 21411 c, the Type term is GDT21412 c, and the Type Name term is Name 21413 c. The Cardinality betweenthe Property Value 21400 and the SynonymousName 21407 c is from zero ton 21414 c.

The AbbreviationName 21415 c is an abbreviation of the PreferredName.The AbbreviationName 21415 c is of type GDT: Name. For theAbbreviationName 21415 c, the Category is Element 21416 c, the ObjectClass is Property Value 21417 c, the Property is Abbreviation Name 21418c, the Representation/Association term is Name 21419 c, the Type term isGDT 21420 c, and the Type Name term is Name 21421 c. The Cardinalitybetween the Property Value 21400 and the AbbreviationName 21415 c isfrom zero to n 21422 c.

The IconAttachment 21423 c is a graphic that illustrates the meaning ofthe value or value interval. The IconAttachment 21423 c is of type GDT:Attachment. For the IconAttachment 21423 c, the Category is Element21424 c, the Object Class is Property Value 21425 c, the Property isIcon 21426 c, the Representation/Association term is Attachment 21427 c,the Type term is GDT 21428 c, and the Type Name term is Attachment 21429c. The Cardinality between the Property Value 21400 and theIconAttachment 21423 c is zero or one 21430 c.

The AttachmentWebAddress 21431 c is a reference to a WebAddress on thebasis of which the value was defined. This attachment could be anexplanatory drawing or a colored pattern. The AttachmentWebAddress 21431c is of type GDT: WebAddress. For the AttachmentWebAddress 21431 c, theCategory is Element 21432 c, the Object Class is Property Value 21433 c,the Property is Attachment 21434 c, the Representation/Association termis Web Address, the Type term is GDT 21436 c, and the Type Name term isWebAddress 21437 c. The Cardinality between the Property Value 21400 andthe AttachmentWebAddress 21431 c is zero or one 21438 c.

Illustrative integrity conditions for 21400 are as follows. WhenAmountSpecification, QuantitySpecification, DecimalSpecification,FloatSpecification, IntegerSpecification, DateSpecification,TimeSpecification, or DateTimeSpecification are used, single values maybe specified by Amount, Measure, Quantity, Value, Date, Time, orDateTime. Single values and intervals cannot be specified at the sametime. When LowerAmount or UpperAmount, LowerQuantity or UpperQuantity,LowerDecimal or UpperDecimal, LowerFloat or UpperFloat, LowerInteger orUpperInteger, StartDate or EndDate, StartTime or EndTime, orStartDateTime or EndDateTime are used, the respective complementaryUpper or Lower field or Start or End field may be filled. ThePreferredName and AbbreviationName fields may be filled once perlanguage. IntervalTypeCode may be specified when the value is aninterval (also <, <=, and the like). See for example, ISO13584/42.

Examples of AmountSpecification include defining a price interval,either a LowerAmount or UpperAmount for a product.

Examples of QuantitySpecification include valuating properties whosedata types are in units, e.g., 5 pieces, 7 kg.

Examples of DecimalSpecification/FloatSpecification include valuatingnondimensional, numeric properties e.g., ratios, calculation indexes,key figures, and so on.

Examples of IntegerSpecification include valuating nondimensional,integer properties, e.g., codes, indexes, and sequential numbers.

Examples of DateSpecification include an expiration date or best-beforedate, a date of manufacture, a filling date, a packaging date, a releasedate, a lock date, an order date, a delivery date, a storage period, andthe like.

Examples of TimeSpecification/DateTimeSpecification include time stamp,accurate to the second, for specifying a filling time, production time,inspection time, and the like.

Examples of NameSpecification include red, green, and the like, for thecolor of the property.

Examples of Indicator Specification include properties that can have oneof two statuses as their valuation, e.g., yes/no, on/off.

(xxxxxxx) PurchaseOrderOrderedIndicator

A GDT PurchaseOrderOrderedIndicator 21500 indicates whether a purchaseorder has been sent to a vendor or not. An example is: (In the contextof the PurchaseOrder)

<OrderedIndicator>true</OrderedIndicator>.

The structure of GDT Purchase Order Ordered Indicator 21500 is depictedin FIG. 215. For the GDT Purchase Order Ordered Indicator 21500, theObject Class is Purchase Order 21502, the Property is Ordered Indicator21504, the Representation/Association term is Indicator 21506, and theType term is CCT: Indicator 21508.

The PurchaseOrderOrderedIndicator 21500 can have the following values,either 1) true, meaning that the purchase order has been sent to avendor; or 2) false, meaning that the purchase order has not yet beensent to a vendor.

For value range, see CCT Indicator.

The PurchaseOrderOrderedIndicator 21500 indicates whether or not apurchase order has been sent to a vendor. This makes it possible todistinguish between purchase orders that have already been sent to avendor and purchase orders that are still being processed.

(yyyyyyy) PurchasingGroupID

A GDT PurchasingGroupID 21600 is a unique identifier for a group ofbuyers who are responsible for certain purchasing activities. An exampleis:

<PurchasingGroupID>1234567</PurchasingGroupID>.

The structure of GDT Purchasing Group ID 21600 is depicted in FIG. 216.For the GDT Purchasing Group ID 21600, the Object Class is PurchasingGroup 21602, the Property is Identification 21604, theRepresentation/Association term is Identifier 21606, the Type term isCCT 21608, the Type Name term is Identifier 21610, and the Length isfrom one to twenty 21612.

An in-house purchasing group may be responsible for procuring a productor class of products. Externally, the group acts as a contact forvendors. The PurchasingGroupID 21600 can be a maximum of 20alphanumerical characters long. For the external representation,role-based IDs (e.g., BuyerPurchasingGroupID) based on the CCT:Identifier can be used without additional attributes—they are unique inconjunction with the identification of the party described by the role(e.g., BuyerID). The PurchasingGroupID 21600 is used externally incooperative business processes, in particular in the vendor-managedinventory (VMI) business process, to uniquely identify the purchasinggroup of the party involved. In this scenario, the buyer, such as aretail company, sends purchase order numbers to the vendor, togetherwith its PurchasingGroupID (i.e., the “BuyerPurchasingGroupID,” from thevendor's point of view) so that the purchase orders created by thevendor can be generated depending on the buyer's purchasing groupidentification.

(zzzzzzz) Quantity

A GDT Quantity 21700 is the non-monetary numerical specification of anamount in a unit of measurement. An example is: <OrderedQuantityunitCode=“CT”>100</OrderedQuantity>(CT =Carton).

The structure of GDT Quantity 21700 is depicted in FIG. 217. A quantityis the result of the numerical comparison of the number, amount, or sizeof a given item or attribute and a standard number, amount, or size.Depending on the item or attribute to be qualified and the businesscontext, the comparison can be made by physically measuring or counting.Positive and negative entries are possible using the built-in data type“xsd: decimal.” Negative entries may be prefixed with a negative sign(“−”). However, positive entries do not have to be prefixed with apositive sign (”+”). The GDT Quantity 21700 includes attribute unitCode21710. For the GDT Quantity 21700, the Representation/Association termis Quantity 21702, the Type term is xsd 21704, the Type Name term isDecimal 21706, and the Length is thirteen six 21708. For the unitCode21710, the Category is Attribute 21712, the Object Class is Quantity21714, the Property is Unit 21716, the Representation/Association termis Coe 21718, the Type term is xsd 21720, the Type Name term is Token21722, and the Length is from one to three 21724. The Cardinalitybetween the GDT Quantity 21700 and the unitCode 21710 is one 21726.

The permitted variations of the “unitCode” attribute are described inmore detail in the “MeasureUnitCode” GDT.

Quantity 21700 may be used to specify the amount of a (manufactured,ordered, transported, delivered, and the like) product. In each givencontext, a decision may be made as to whether an amount (Quantity) or aphysical measurement (Measure) is being specified. For this purpose, thephysical units (PhysicalMeasureUnits) used in Measure form a subset ofthe measurement units (MeasureUnits) used in Quantity.

MeasureUnitCode helps to determine the “unitCode 21710” attribute.

(aaaaaaaa) QuantityDiscrepancyCode

The GDT QuantityDiscrepancyCode 21800 is a coded representation of thecause of or reason for a quantity discrepancy. An example is:

<QuantityDiscrepancyCode>AE</QuantityDiscrepancyCode>.

The structure of GDT QuantityDiscrepancyCode 21800 is depicted in FIG.218. For the GDT QuantityDiscrepancyCode 21800, the Object Class isQuantity 21802, the Property is Discrepancy 21804, theRepresentation/Association term is Code 21806, the Type term is CCT21808, the Type Name term is Code 21810, and the Length is from one tofour 21812. The GDT QuantityDiscrepancyCode 21800 may be a restrictedGDT.

Illustrative GDT QuantityDiscrepancyCode 21800 values in the “goodsreceipt process” are as follows: 1) AC, which represents an overdelivery (on receipt of the goods, a surplus quantity was established inrelation to the previously notified delivery); 2) AE, which representsgoods delivered but not notified (on receipt of the goods, quantities ofgoods were established that were delivered without prior notification inthe form of a shipping notification); 3) AF, which represents deliveredgoods are damaged (on receipt of the goods, damaged quantities werefound); and 4) AG, which represents goods delivered too late (on receiptof the goods, quantities of goods were established that were alreadynotified in an earlier delivery).

The GDT QuantityDiscrepancyCode 21800 refers to UN/EDIFACT 4221(Discrepancy nature identification code) and contains the codes fromthis list that are relevant for quantity discrepancies. The GDTQuantityDiscrepancyCode 21800 describes the cause of a quantitydiscrepancy in a delivery that was established in the goods receiptprocess (generally with regard to a location product.) This codedinformation may be returned to the sender of the goods by means of agoods receipt notification. The codes for indicating under deliveries ofgoods and goods that are delivered too late could not be found in thecurrent UN/EDIFACT code list. These two codes may still need to berequested and added as list values.

(bbbbbbbb) QuantityTimeSeries

A CDT QuantityTimeSeries 21900 is time series information that consistsof items that each contain a period with a start time and end time and aperiod-based quantity. An example is:     <QuantityTimeSeries>      <Item>           <ValidityPeriod>          <StartDateTime>2002-04- 19T15:00:00Z</StartDateTime>          <EndDateTime>2002-04- 19T17:00:00Z</EndDateTime>          </ValidityPeriod>           <QuantityunitCode=“PC” >150</Quantity>       </Item>     </QuantityTimeSeries>.

The structure of GDT Quantity-TimeSeries 21900 is depicted in FIG. 219.The GDT Quantity-TimeSeries 21900 includes element Item 21914. For theGDT Quantity-TimeSeries 21900, the Object Class Quality term is Quantity21902, the Object Class is TimeSeries 21904, theRepresentation/Association term is Details 21906, the Type term is GDT21908, and the Type Name term is TimeSeries 21910. The GDTQuantity-TimeSeries 21900 may be a restricted GDT.

The QuantityTimeSeriesItem 21914 is an item in a time series and can berepeated as often as required. For the Item 21914, the Category isElement 21916, the Object Class is TimeSeries 21918, the Property isItem 21920, and the Representation/Association term is Details 21922.The Cardinality between the GDT Quantity-TimeSeries 21900 and the Item21914 is from one to n 21924.

The ValidityPeriod 21926 describes the validity period of the timeseries item with a start time stamp and an end time stamp. For theValidity Period 21926, the Category is Element 21928, the Object Classis TimeSeries 21930, the Property is ValidityPeriod 21932, theRepresentation/Association term is Details 21934, the Type term is GDT21936, and the Type Name term is DateTimePeriod 21938. The Cardinalitybetween the GDT Quantity-TimeSeries 21900 and the Item 21914 ValidityPeriod 21926 is one 21940.

The Quantity 21942 describes the quantity connected with the time seriesitem. For the Quantity 21942, the Category is Element 21944, the ObjectClass is TimeSeries 21946, the Property is Quantity 21948, theRepresentation/Association term is Quantity 21950, the Type term is GDT21952, and the Type Name term is Quantity 21954. The Cardinality betweenthe GDT Quantity-TimeSeries 21900 and the Quantity 21942 is one 21956.

The FixedIndicator 21958 describes whether the corresponding item isblocked for changes or not. For the Fixed-Indicator 21958, the Categoryis Element 21960, the Object Class is TimeSeries 21962, the Property isFixedIndicator 21964, the Representation/Association term is Indicator21966, the Type term is GDT 21968, and the Type Name term isFixedIndicator 21970. The Cardinality between the GDTQuantity-TimeSeries 21900 and the Fixed-Indicator 21958 is zero or one21972.

CDT QuantityTimeSeries 21900 is used as a generic data type that canhave various specifications in an interface depending on the contextcategory used, e.g., “Sales,” to describe sales quantities;“Consumption,” to describe consumption quantities, and the like.

(cccccccc) QuantityTolerance

A GDT QuantityTolerance 22000 is the tolerated difference between arequested and an actual quantity (e.g., a delivery quantity) as apercentage. An example is: <QuantityTolerance>  <OverPercent>33.0</OverPercent>   <UnderPercent>1.0</UnderPercent></QuantityTolerance>.

The structure of GDT QuantityTolerance 22000 is depicted in FIG. 220.The GDT QuantityTolerance 22000 includes elements OverPercent 22008,OverPercentUnlimitedIndicator 22024, and UnderPercent 22040. For the GDTQuantityTolerance 22000, the Object Class is QuantityTolerance 22002,the Property is Details 22004, and the Representation/Association termis Details 22006. GDT QuantityTolerance 22000 comprises the threeelements OverPercent 22008 and UnderPercent 22040 from “CCT: Numeric”and OverPercentUnlimitedIndicator from the CCT: Indicator.

For the OverPercent 22008, the specification of a value x in this fieldmeans that for an ordered quantity of Y, up to x % of Y are acceptedadditionally. Therefore, the specification in this field is to beunderstood as a percentually relative specification. The specificationis made as a decimal with a total of 4 digits, including one positionafter the decimal point, without plus/minus sign (e.g., 15.5). Aspecification of 0 in OverPercent 22008 means that the ordered quantitymay not be exceeded. If the OverPercent 22008 and also theOverPercentUnlimitedIndicator 22024 are not specified, this also meansthat the ordered quantity may not be exceeded. For example, for anordered quantity of 50 pieces and an OverPercent 22008 entry equal to10, up to 5 more pieces would be accepted, thus altogether a maximumquantity of 55 pieces. For the OverPercent 22008, the Category isElement 22010, the Object Class is QuantityTolerance 22012, the Propertyis Over 22014, the Representation/Association term is Percent 22016, theType term is GDT 22018, and the Type Name term is GDT: Percent 22020.The Cardinality between the GDT QuantityTolerance 22000 and theOverPercent 22008 is zero or one 22022.

For the OverPercentUnlimitedIndicator 22024, making an entry in thisfield means that no limitations may be made regarding the degree offulfillment upwards. The OverPercentUnlimitedIndicator 22024 applies tothe upper limit. The OverPercent 22008 and theOverPercentUnlimitedIndicator 22024 cannot be specified at the sametime; however, the UnderPercent 22040 and theOverPercentUnlimitedIndicator 22024 can be set simultaneously. For theOverPercentUnlimitedIndicator 22024, the Category is Element 22026, theObject Class is QuantityTolerance 22028, the Property isOverPercentUnlimited 22030, the Representation/Association term isIndicator 22032, the Type term is GDT 22034, and the Type Name term isGDT: ValueUnlimitedIndicator 22036. The Cardinality between the GDTQuantityTolerance 22000 and the OverPercentUnlimitedIndicator 22024 iszero or one 22038.

If no OverPercentUnlimitedIndicator 22024 is set, the default value maybe “false.” The specification is made as a Boolean entry of length 1.The following illustrative values are allowed: 1) true, meaning that anyoverrun is accepted; and 2) false, meaning that overruns are notaccepted.

For the UnderPercent 22040, the entry of a value x in this field meansthat for an ordered quantity of Y, up to x % of Y less are accepted.Therefore, the specification in this field is to be understood as apercentually relative specification. The specification is made as adecimal with a total of 4 digits, including one position after thedecimal point, without plus/minus sign (e.g., 15.5). A specification of0 in UnderPercent 22040 means that the ordered quantity may not beshort. If the UnderPercent 22040 is not entered, this also means thatthe ordered quantity may not be short. For example: For an orderedquantity of 50 pieces and an UnderPercent 22040 entry=10, up to 5 piecesless would be accepted, so altogether at least 45 pieces. Using aseparate entry of OverPercent 22008 and UnderPercent 22040, it ispossible, e.g., to accept too high a quantity as this could perhaps becovered by a particular stock, but to reject the delivery of too small aquantity, e.g., to avoid a production standstill. For the UnderPercent22040, the Category is Element 22042, the Object Class isQuantityTolerance 22044, the Property is Under 22046, theRepresentation/Association term is Percent 22048, the Type term is GDT22050, and the Type Name term is GDT: Percent 22052. The Cardinalitybetween the GDT QuantityTolerance 22000 and the UnderPercent 22040 iszero or one 22054.

The fields OverPercent and OverPercentUnlimitedIndicator are mutuallyexclusive, i.e., entering “true” in the OverPercentUnlimitedIndicatorand, at the same time, filling the OverPercent does not make sense.

The QuantityTolerance specifies (as a percentage) the difference tobe/that can be tolerated between a required or requested quantity and anactual quantity (delivery quantity). The specification is madeseparately for an over quantity or shortfall.

See, for example, UN/EDIFACT: Segment QVR (QUANTITY VARIANCES)—DataElements 6064 (Quantity variance value): n. 1 5 (up to 15 numericcharacters), and R/3: DEC 3.1 (calculation or amount field with commaand plus/minus sign).

(dddddddd) Recurrence

A GDT Recurrence 22100 is a representation for the repeated occurrenceof an event within a time period or within a timeframe. There may befour types of recurrence: 1) a number of recurrences within a timeperiod; 2) the recurrences each take place after a determined periodduration within a time period; 3) a number of recurrences within atimeframe; and 4) the recurrences each take place after a determinedperiod duration within a timeframe.

The structure of GDT Recurrence 22100 is depicted in FIG. 221. The GDTRecurrence 22100 includes Duration 22106 and Value 22120. For GDTRecurrence 22100, the Object Class is Recurrence 22102 and theRepresentation/Association term is Details 22104.

A timeframe (duration) is a time without reference to a specificstarting point or end point. Examples of a time frame include: “Day,”“Week,” or “Year.” A time period (period) is a concrete time in terms ofa starting point and/or an end point. Examples of a time period include:“Jan. 10, 2003 to Jan. 20, 2003” or “40 days starting on Jan. 2, 2004.”The 4 cases listed in the definition of 22100 differ in terms of thetype of basic range that the recurrences refer to (time period ortimeframe), and the type in which the recurrences are specified (fixednumber or specification of a period duration for which a recurrenceoccurs).

In summary, the Time period has a Fixed number of Case a) and a Periodduration of Case b). The Timeframe has a Fixed number of Case c) and aPeriod duration of Case d). See the table below. Fixed number Periodduration Time period Case a) Case b) Timeframe Case c) Case d)

-   -   Examples of the 4 types of Recurrence 22100 are as follows:    -   Type 1: “4 recurrences between Jul. 1, 2003 and Oct. 15, 2003.”    -   Type 2: “weekly recurrences between 12.4.2004 and 6.6.2004.”    -   Type 3: “2 recurrences in one month,” “8 recurrences in 50        days.”    -   Type 4: “weekly recurrences in one month,” “daily recurrences in        50 days.”    -   The timeframe as “abstract” time specification should not be        confused with time period as the “concrete” time specification.        The number of recurrences in a timeframe is valid for each        “occurrence” of this timeframe. For example, after one week, the        same number of recurrences also takes place in the following        week.    -   Since a time period is a concrete time and may not occur more        than once, the number of recurrences relates to this time        period. A recurrence does not have to be regular. The Recurrence        22100 covers both regular and irregular recurrences.

Below is an example (instance): <Recurrence>   <Duration>P7D</Duration>  <Value>1</Value> </Recurrence>

The structure of GDT Recurrence 22100 is depicted in FIG. 221. The GDTfirst supports type 3 from the types of recurrence specified in thedefinition. The GDT Recurrence 22100 includes Duration 22106 and Value22120. For GDT Recurrence 22100, the Object Class is Recurrence 22102and the Representation/Association term is Details 22104.

The Duration 22106 specifies the timeframe within which the specifiednumber of recurrences takes place. For the Duration 22106, the ObjectClass is Recurrence 22108, the Property is Duration 22110, theRepresentation/Association term is Duration 22112, the Type term is GDT22114, and the Type Name term is Duration 22116. The Cardinality betweenthe GDT Recurrence 22100 and the Duration 22106 is one 22118.

The Value 22120 specifies the number of recurrences (in terms of thetimeframe). For the Value 22120, the Object Class is Recurrence 22122,the Property is Value 22124, the Representation/Association term isValue 22126, the Type term is GDT 22128, the Type Name is IntegerValue22130, and the Length is from one to three 22132. The Cardinalitybetween the GDT Recurrence 22100 and the Value 22120 is one 22134.

The timeframe, or duration, may not be a timeframe in the sense of avalidity duration.

(eeeeeeee) RegionCode

The GDT RegionCode 22200 is a coded representation of logically orphysically linked geographical or political regions that have one ormore attributes in common. An example is: <RegionCode>BW</RegionCode>.

The structure of GDT RegionCode 22200 is depicted in FIG. 222. Thedefault setting of RegionCode is the list of Country Subdivision Codesaccording to ISO 3166-2. If the region is not available within ISO3166-2, the code list from the relevant country or the issuing agencyshould be used instead. The GDT RegionCode 22200 includes attributeslistID 22212, listVersionID 22230, listAgencyID 22248,listAgencySchemeID 22266, and listAgencySchemeAgencyID 22284. For theGDT RegionCode 22200, the Object Class is Region 22202, the Property isIdentification 22204, the Representation/Association term is Code 22206,the Type term is CCT 22208, and the Type Name term is Code 22210.

The listID 22212 identifies a list of the codes that belong together.The listID 22212 is unique within the agency that manages this codelist. For the listID 22212, the Category is Attribute 22214, the ObjectClass is CodeList 22216, the Property is Identification 22218, theRepresentation/Association term is Identifier 22220, the Type term isxsd 22222, the Type Name term is Token 22224, and the Length is from oneto sixty 22226. The Cardinality between the GDT RegionCode 22200 and thelistID 22212 is zero or one 22228.

The listVersionID 22230 identifies the version of a code list. For thelistVersionID 22230, the Category is Attribute 22232, the Object Classis CodeList 22234, the Property is Version 22236, theRepresentation/Association term is Identifier 22238, the Type term isxsd 22240, the Type Name term is Token 22242, and the Length is from oneto fifteen 22244. The Cardinality between the GDT RegionCode 22200 andthe listVersionID 22230 is zero or one 22246.

The listAgencyID 22248 identifies the agency that manages the code list.The agencies from DE 3055 may be used as the default, but in a variationthe roles defined in DE 3055 may not be used. For the listAgencyID22248, the Category is Attribute 22250, the Object Class isCodeListAgency 22252, the Property is Identification 22254, theRepresentation/Association term is Identifier 22256, the Type term isxsd 22258, the Type Name term is Token 22260, and the Length is from oneto sixty 22262. The Cardinality between the GDT RegionCode 22200 and thelistAgencyID 22248 is zero or one 22264.

The listAgencySchemeID 22266 identifies the identification scheme thatrepresents the context for agency identification. For thelistAgencySchemeID 22266, the Category is Attribute 22268, the ObjectClass is CodeListAgency 22270, the Property is Scheme 22272, theRepresentation/Association term is Identifier 22274, the Type term isxsd 22276, the Type Name term is Token 22278, and the Length is from oneto sixty 22280. The Cardinality between the GDT RegionCode 22200 and thelistAgencySchemeID 22266 is zero or one 22282.

The listAgencySchemeAgencyID 22284 identifies the agency that managesthe listAgencySchemeID. This attribute can contain values from DE 3055(excluding roles). For the listAgencySchemeAgencyID 22284, the Categoryis Attribute 22286, the Object Class is CodeListAgency 22288, theProperty is SchemeAgency 22290, the Representation/Association term isIdentifier 22292, the Type term is xsd 22294, the Type Name term isToken 22296, and the Length is three 22298. The Cardinality between theGDT RegionCode 22200 and the listAgencySchemeAgencyID 22284 is zero orone 22201.

Examples of the RegionCode are: structure regions (e.g., Munichmetropolitan area ); program regions (e.g., promotion programs),settlements, administrative regions (e.g., federal states), gridsquares, economic regions, and the like.

The RegionCode may be restricted to ISO 3166-2. However, to ensure thatfurther code lists can be used, the optional attributes “listID 22212,”“listVersionID 22230,” “listAgency 22248,” “listAgencySchemeID 22266,”and “listAgencySchemeAgencyID 22284” are also included in thatillustrative case. For more details, see the “SAP Core Component Types”specification document.

(ffffffff) RequiredIndicator

A GDT RequiredIndicator 22300 indicates whether something is required ornot. The word “something” generally stands for specific procedures,operations or events. An example is:<SeparatorSignRequiredIndicator>true</SeparatorSignRequiredIndicator>.

The structure of GDT RequiredIndicator 22300 is depicted in FIG. 223.

The RequiredIndicator can have the following values, either 1) true,meaning that something is required; or 2) false, meaning that somethingis not required. (For value range, see CCT: Indicator.)

For each GDT RequiredIndicator 22300, what is required or not requiredis specified. This is reflected in an appropriate name prefix. Forexample, a SeparatorSignRequiredIndicator indicates whether a separatoris required or not. The GDT RequiredIndicator 22300 can be used, e.g.,to indicate whether prices always have to be specified with a thousandsseparator. In the context of an interface, the business significance of“what is required” may be. described for the GDT RequiredIndicator 22300in addition to its name prefix (see Integrity Conditions).

(gggggggg) RevisionQuantityTimeSeries

A GDT RevisionQuantityTimeSeries 22400 is revised time seriesinformation that consists of items that each contain a period with astart time and end time, a period-based quantity, and the reason for thechanges. An example or instance is:     <RevisionQuantityTimeSeries>      <Item>           <ValidityPeriod>          <StartDateTime>2002-04- 19T15:00:00Z</StartDateTime>          <EndDateTime>2002-04- 19T17:00:00Z</EndDateTime>          <ValidityPeriod>           <QuantityunitCode=“PC” >150</Quantity>  <AdjustmentReasonCode>Cancelled_Promotion</   AdjustmentReasonCode>      <Item>     </RevisionQuantityTimeSeries>.

The structure of GDT RevisionQuantityTimeSeries 22400 is depicted inFIG. 224. The GDT RevisionQuantityTimeSeries 22400 includes elementsItem 22414, Validity Period 22426, StartDateTime 22442, EndDateTime22458, Quantity 22474, Fixed-Indicator 22490, Adjustment-ReasonCode22407, and Note 22423. For the GDT RevisionQuantityTimeSeries 22400,Object Class Quality term is RevisionQuantity 22402, the Object Class isTimeSeries 22404, the Representation/Association term is Details 22406,the Type term is GDT 22408, and the Type Name term is TimeSeries 22410.The GDT RevisionQuantityTimeSeries 22400 may be a restricted GDT.

RevisionQuantityTimeSeriesItem 22414 is an item in a time series and canbe repeated as often as required. For the Item 22414, the Category isElement 22416, the Object Class is TimeSeries 22418, the Property isItem 22420, and the Representation/Association term is Details 22422.The Cardinality between the GDT RevisionQuantityTimeSeries 22400 and theItem 22414 is from one to n 22424.

ValidityPeriod 22426 describes the validity period of the time seriesitem. For the Validity Period 22426, the Category is Element 22428, theObject Class is TimeSeries 22430, the Property is ValidityPeriod 22432,the Representation/Association term is Details 22434, the Type term isGDT 22436, and the Type Name term is DateTimePeriod 22438. TheCardinality between the GDT RevisionQuantityTimeSeries 22400 and theValidity Period 22426 is one 22440. For the StartDateTime 22442, theCategory is Element 22444, the Object Class is TimeSeries 22446, theProperty is ValidityPeriodStart 22448, the Representation/Associationterm is DateTime 22450, the Type term is GDT 22452, and the Type Nameterm is DateTime 22454. The Cardinality between the GDTRevisionQuantityTimeSeries 22400 and the StartDateTime 22442 is one22456. For the EndDateTime 22458, the Category is Element 22460, theObject Class is TimeSeries 22462, the Property is ValidityPeriodEnd22464, the Representation/Association term is DateTime 22466, the Typeterm is GDT 22468, and the Type Name term is DateTime 22470. TheCardinality between the GDT RevisionQuantityTimeSeries 22400 and theEndDateTime 22458 is one 22472.

Quantity 22474 describes the quantity connected with the time seriesitem. For the Quantity 22474, the Category is Element 22476, the ObjectClass is TimeSeries 22478, the Property is Quantity 22480, theRepresentation/Association term is Quantity 22482, the Type term is GDT22484, and the Type Name term is Quantity 22486. The Cardinality betweenthe GDT RevisionQuantityTimeSeries 22400 and the Quantity 22474 is one22488.

FixedIndicator 22490 indicates whether the corresponding item is blockedfor changes or not. For the Fixed-Indicator 22490, the Category isElement 22492, the Object Class is TimeSeries 22494, the Property isFixedIndicator 22496, the Representation/Association term is Indicator22498, the Type term is GDT 22401, and the Type Name term isFixedIndicator 22403. The Cardinality between the GDTRevisionQuantityTimeSeries 22400 and the Fixed-Indicator 22490 is zeroor one 22405.

AdjustmentReasonCode 22407 describes the reason for a change to theitem, if there is one. For the Adjustment-ReasonCode 22407, the Categoryis Element 22409, the Object Class is TimeSeries 22411, the Property isAdjustmentReason 22413, the Representation/Association term is Code22415, the Type term is GDT 22415, the Type Name term isAdjustmentReasonCode 22419. The Cardinality between the GDTRevisionQuantityTimeSeries 22400 and the Adjustment-ReasonCode 22407 iszero or one 22421.

For the Note 22423, the Category is Element 22425, the Object Class isTimeSeries 22427, the Property is Note 22429, theRepresentation/Association term is Note 22431, the Type term is GDT22433, the Type Name term is Note 22435. The Cardinality between the GDTRevisionQuantityTimeSeries 22400 and the Note 22423 is zero or one22437.

RevisionQuantityTimeSeries is used for the revision of aQuantityTimeSeries or of a RevisionQuantityTimeSeries itself. In aninterface, the data type can have various specifications, depending onthe context category used, e.g., “Sales,” to describe sales quantities;“Consumption,” to describe consumption quantities, and the like.

(hhhhhhhh) ScaleAxisIntervalBoundaryTypeCode

The GDT ScaleAxisIntervalBoundaryTypeCode 22500 is a codedrepresentation of the typing of the discrete values in a scale axis asinterval boundaries. An example is:

<ScaleAxisIntervalBoundaryTypeCode>2</ScaleAxisIntervalBoundaryTypeCode>.

The structure of GDT Scale Axis Interval Boundary Type Code 22500 isdepicted in FIG. 225. For the GDT Scale Axis Interval Boundary Type Code22500, the Object Class is Scale Axis 22502, the Property is IntervalBoundary Type Code 22504, the Representation/Association term is Code22506, the Type term is CCT 22508, the Type Name term is Code 22510, andthe Length is one 22512. The GDT Scale Axis Interval Boundary Type Code22500 may be a restricted GDT.

An element of type GDT ScaleAxisIntervalBoundaryTypeCode 22500 can havethe following illustrative values:

-   -   1) The value 1 represents the “lower boundary of an interval”        from the current scale axis value to the next highest scale axis        value, but excluding the next higher scale axis value; and    -   2) The value 2 represents the “upper boundary of an interval” to        the current scale axis value from the next lowest scale axis        value, but excluding the next lower scale axis value.

The scale axis values of a scale may be of the same GDTScaleAxisIntervalBoundaryTypeCode 22500. It may be possible to arrangethe scale axis values of a scale axis uniquely.

The meaning of scale axis values, determined via theScaleAxisIntervalBoundaryTypeCode, is described as “scale axis type’ inthe context of pricing scales. It is used in this context in thefollowing way. A scale axis is used to determine the “domain” of a(one-dimensional) pricing scale. In this context, the values of thescale axis are described as scale levels. The pricing scale defines ascale rate for each scale level (e.g., net price, or discount).Consequently, a pricing scale comprises the scale levels as “inputvalues” and the scale rates defined for the levels as “output values.”The “output values” of a pricing scale are accessed using the scalelevel(s) to determine conditions in the context of pricing, on valuessuch as, e.g., the order quantity.

A scale level and the scale axis type jointly determine the interval towhich the scale rate applies, either 1) from the current scale level upto the next higher level, but excluding the subsequent next level, or 2)up to the current scale level, from the next lowest level, but excludingthe next lower level. In the first case, the pricing scale is called the“from-pricing scale,” in the second case it is called the “to-pricingscale”. Scales axes for pricing scales may explicitly have a minimum andmaximum scale axis value.

The scale levels of a pricing scale may be defined in terms of a pricingscale base type. The scale levels for the scale base types quantity,gross value, and number are scale quantity with scale quantity unit,scale rate with scale currency, and scale quantity without unit,respectively. Scale levels are divided into the scale axis of a pricingscale (or the dimension of the pricing scale represented by it). Thescale type is valid for all scale levels of a pricing scale, i.e., thedifferent scale levels of a (one-dimensional) pricing scale are alwaysinterpreted in the same way as interval boundaries.

The scale levels of a pricing scale may imply disconnected and consumingintervals. For variations of the input value, a scale level (andtherefore, the interval implied) is relevant for determining the scaleamount when using scale types “lower boundary” and “upper boundary.”

The following is an example of a one-dimensional pricing scale of scaletype “2” or “upper boundary” with scale base type quantity. Scale levelas “input value” Scale rate with currency, price unit and Scalequantity Scale unit unit of measure as “output value”$\overset{︷}{\begin{matrix}{10\quad{Pieces}} \\{100{\quad\quad}{Pieces}} \\{1000\quad{Pieces}} \\{10000{\quad\quad}{Pieces}}\end{matrix}}$ 10 ε/1 piece  9 ε/piece  8 ε/1 piece  8 ε/1 piece

When determining a pricing condition for an order quantity of, e.g., 150pieces, the third scale level is used and the price (150 ST×8

/1 pc) equal to 1200

is determined based on the scale type “upper boundary.”

The ScaleAxisIntervalBoundaryTypeCode may be a proprietary code listwith fixed predefined values. Changes to the permitted values involvechanges to the interface. The focus here is on one-dimensional pricingscales, even if multi-dimensional pricing scales can be used for thescale type and possess one scale type per dimension. The same conceptsas for pricing conditions are used for scales for free goods and rebateconditions, i.e., the ScaleAxisIntervalBoundaryTypeCode can also be usedfor these scales. (See also pricing conditions and pricing scales.)

(iiiiiiii) ScheduleLineCommitmentCode

The GDT ScheduleLineCommitmentCode 22600 is a coded representation thatdescribes the planning-related meaning of the schedule line informationfor a purchase order, such as a delivery schedule, and thus determinesthe (legal) binding nature for the ordered quantity and specifieddelivery dates for a material/product. An example is:

<ScheduleLineCommitmentCode>AE</ScheduleLineCommitmentCode>.

The structure of GDT ScheduleLineCommitmentCode 22600 is depicted inFIG. 226. For the GDT ScheduleLineCommitmentCode 22600, the Object Classis ScheduleLine 22602, the Property is Commitment 22604, theRepresentation/Association term is Code 22606, the Type term is CCT22608, the Type term is Code 22610, and the Length is from one to three22612. The GDT ScheduleLineCommitmentCode 22600 may be a restricted GDT.

The following illustrative values of the ScheduleLineCommitmentCode arein the framework of “scheduling-agreement-based release order”:

1) Fixed dates and quantities, which indicates that the schedule lineinformation regarding the specified product quantities and dates isfixed.

2) Production and material go-ahead, which authorizes the vendor tostart manufacturing the required products.

3) Material go-ahead, which authorizes the vendor to order the requiredmaterial for the products to be delivered.

4) Forecast/preview, which represents a non-binding forecast of futurepurchase orders that currently depend on planned requirements.

5) Shortfall quantity/backlog, which represents a product quantity thathas already been ordered but did not arrive by the planned delivery dateand therefore may be delivered subsequently.

10) Immediate requirement, which represents an immediately requiredproduct quantity that may be included immediately in the next delivery.

The ScheduleLineCommitmentCode refers to the representation UN/EDIFACT4017: Delivery plan commitment level code. TheScheduleLineCommitmentCode is used to inform a vendor about the bindingnature and the meaning of the schedule line information of a releaseorder/forecast delivery schedule. It may be used, for example, in theautomotive industry.

(jjjjjjjj) ScoreCardID

A GDT ScoreCardID 22700 is the identification of a scorecard. Ascorecard is a procedure for assessing a party or subject usingdifferent characteristics. An example is:

<ScoreCardID>A</ScoreCardID>.

The structure of GDT ScoreCardID 22700 is depicted in FIG. 227. For theGDT ScoreCardID 22700, the Object Class is Score Card 22702, theProperty is Identification 22704, the Representation/Association term isIdentifier 22706, the Type term is CCT 22708, the Type Name isIdentifier 22710, and the Length is from one to twenty 22712. The GDTScoreCardID 22700 may be a restricted GDT.

The following may apply to 22700:

-   -   1) Scorecards are internal to a company and confidential; and    -   2) The company that specifies the scorecard assigns an ID.

ScoreCardID is unique in the context of the company that specifies thescorecard. Scorecards are used, e.g., by credit agencies to ratecompanies. In this case, the credit agency assigns the IDs; ScoreCardIDis then unique in the context of a credit agency. Another possible useis the company internal identification of a scorecard that is created aspart of the “Balanced Scorecard” concept for determining businessperformance.

(kkkkkkkk) SubContractingIndicator

A GDT SubContractingIndicator 22800 indicates whether the transactionform is subcontracting or not. An example is:

<SubContractingIndicator>true</SubContractingIndicator>.

The structure of GDT SubContractingIndicator 22800 is depicted in FIG.228. The GDT SubContractingIndicator 22800 is from the core componenttype Indicator. For the GDT SubContracting Indicator 22800, the ObjectClass is Sub Contracting 22802, the Property is Indicator 22804, theRepresentation/Association term is 22806, the Type term is CCT 22808,and the Type Name term is Indicator 22810.

The SubContractingIndicator can have the following illustrative values,either 1) true, meaning that the transaction is subcontracting; or 2)false, meaning that the transaction is not subcontracting.“Subcontracting” is a transaction form in which the vendor receives anorder to produce the final product from the delivered materialscomponents.

(llllllll) SubHierarchyDefinitionIndicator

A GDT SubHierarchyDefinitionIndicator 22900 indicates whether somethingis used to establish a subhierarchy or not. The word “something” as usedin this context may generally relate to specific properties or facts. Anexample is:

<PropertySubHierarchyDefinitionIndicator>true</PropertySubHierarchyDefinitionIndicator>.

The structure of GDT SubHierarchyDefinitionIndicator 22900 is depictedin FIG. 229. For the GDT SubHierarchyDefinitionIndicator, the Propertyis SubHierarchyDefinition 22902, the Representation/Association term isIndicator 22904, the Type term is CCT 22906, and the Type Name term isIndicator 22908.

The GDT SubHierarchyDefinitionIndicator 22900 can have the followingillustrative values, either 1) true, meaning that something is used toestablish a subhierarchy; or 2) false, meaning that something is notused to establish a subhierarchy. (For value range, see CCT: Indicator.)

For each SubHierarchyDefinitionIndicator, there may be defined what isused or not used to define a subhierarchy. This may be reflected in anappropriate name prefix. For example, aPropertySubHierarchyDefinitionIndicator indicates whether a property isused to define a subhierarchy. The SubHierarchyDefinitionIndicator canbe used, for example, with a training catalog to indicate which of theproperties “Training Contents,” “Training Location,” “TrainingLanguage,” and the like, are used to define a subhierarchy of thetraining offering.

(mmmmmmmm) SubjectAreaCode

The GDT SubjectAreaCode 23000 is a coded representation of a subjectarea. An example is: <SubjectAreaCode>25.040.40</SubjectAreaCode>.25.040.40 stands for ‘Industrial process measurement and control’; thisclassifies ISO13584/42, e.g., where the property is defined.

The structure of GDT SubjectAreaCode 23000 is depicted in FIG. 230. ForGDT SubjectAreaCode 23000, the Object Class is Subject Area 23002, theRepresentation/Association term is Code 23004, the Type term is CCT23006, the Type Name term is DCode 23008, and the Length is nine 23010.The GDT SubjectAreaCode 23000 is a restricted GDT.

The possible illustrative values for the GDT SubjectAreaCode 23000 canbe found in the ‘International Classification for Standards’ (ICS).These standards were created under the overall control of ISO. Forexplanations and values, see the “World Standards Service Network” atwww.wssn.net/WSSN/RefDocs/ics2001-en.pdf. For a comprehensivealphabetical index of subject areas, go towww.wssn.net/WSSN/RefDocs/ics01index-en.pdf.

GDT SubjectAreaCode 23000 is used for classifying normative documentsand standardized objects, and for classifying an object, e.g., aproperty, into subject areas

(nnnnnnnn) TaxJurisdictionCode

The GDT TaxJurisdictionCode 23100 is the tax jurisdiction code part ofthe address. This code is used in various countries and can be deriveduniquely from the address. However, it may depend on the code list ofthe provider. A country can have multiple code-list providers. Anexample is: <TaxJurisdictionCode listID=“VeraZip System,”listVersionID=“,” listAgencyID=“Taxware,” listAgencySchemeID=“,”listAgencySchemeAgencyID=“ ”>PA 1914101</TaxJurisdictionCode>.

The structure of GDT TaxJurisdictionCode 23100 is depicted in FIG. 231.The GDT TaxJurisdictionCode 23100 includes attributes listID 23116,listVersionID 23136, listAgencyID 23156, listAgencySchemeID 23176, andlistAgencySchemeAgencyID 23196. For the GDT TaxJurisdictionCode 23100,the Category is Element 23102, the Object Class is TaxJurisdiction-Code23104, the Property is Tax-JurisdictionCode 23106, theRepresentation/Association term is Code 23108, the Type term is CCT23110, the Type Name term is Code 23112, and the Length is from one tofifteen 23114. For the listID 23116, the Category is Attribute 23118,the Object Class is CodeList 23120, the Property is Identification23122, the Representation/Association term is Identifier 23124, the Typeterm is xsd 23126, the Type Name term is Token 23128, and the Length isfrom one to sixty 23130. The Cardinality between the GDTTaxJurisdictionCode 23100 and the listID 23116 is zero or one 23132. ThelistID 23116 may be optional 23134. For the listVersionID 23136, theCategory is Attribute 23138, the Object Class is CodeList 23140, theProperty is Version 23142, the Representation/Association term isIdentifier 23144, the Type term is xsd 23146, the Type Name term isToken 23148, and the Length is from one to fifteen 23150. TheCardinality between the GDT TaxJurisdictionCode 23100 and thelistVersionID 23136 is zero or one 23152. The listVersionID 23136 may beoptional 23154. For the listAgencyID 23156, the Category is Attribute23158, the Object Class is CodeListAgency 23160, the Property isIdentification 23162, the Representation/Association term is Identifier23164, the Type term is xsd 23166, the Type Name term is Token 23188,and the Length is from one to sixty 23170. The Cardinality between theGDT TaxJurisdictionCode 23100 and the listAgencyID 23156 is zero or one23172. The listAgencyID 23156 may be optional 23174. For thelistAgencySchemeID 23176, the Category is Attribute 23178, the ObjectClass is CodeListAgency 23180, the Property is Scheme 23182, theRepresentation/Association term is Identifier 23184, the Type term isxsd 23186, the Type Name term is Token 23188, and the Length is from oneto sixty 23190. The Cardinality between the GDT TaxJurisdictionCode23100 and the listAgencySchemeID 23176 is zero or one 23192. ThelistAgencySchemeID 23176 may be optional 23194. For thelistAgencySchemeAgencyID 23196, the Category is Attribute 23198, theObject Class is CodeListAgency 23101, the Property is SchemeAgency23103, the Representation/Association term is Identifier 23105, the Typeterm is xsd 23107, the Type Name term is Token 23109, and the Length isthree 23111. The Cardinality between the GDT TaxJurisdictionCode 23100and the listAgencySchemeAgencyID 23196 is zero or one 23113. ThelistAgencySchemeAgencyID 23196 may be optional 23115.

The GDT TaxJurisdictionCode 23100 specifies the tax jurisdiction codeand has a maximum length of 15 characters. The meaning of the attributeslistID, listVersionID, listAgencyID, listAgencySchemeID, andlistAgencySchemeAgencyID is described in the definition of the CCT Code.For example, in the USA there are many providers of software forcalculating taxes that manage TaxJurisdictionCodes. The name of one ofthese providers is specified in the listAgencyID attribute. The GDTTaxJurisdictionCode 23100 specifies the tax jurisdiction code for aphysical address.

(oooooooo) TextSearchableIndicator

A GDT TextSearchableIndicator 23200 indicates whether or not an objectis available for text search. A search is performed for a text that iscontained either entirely or in part in objects indicated by theindicator. An example is:

<TextSearchableIndicator>true</TextSearchableIndicator>.

The structure of GDT TextSearchIndicator 23200 is depicted in FIG. 232.For the GDT TextSearchIndicator 23200, the Property is Text Searchable23202, the Representation/Association term is Indicator 23204, the Typeterm is CCT 23206, and the Type Name term is Indicator 23208.

Valid illustrative values for the 23200 are either: 1) true, meaningthat the object is suitable for “text search,” or 2) false, meaning thatthe object is not suitable for “text search.”

Both parametric searches and text searches can be possible for an objectand one does not preclude the other.

(pppppppp) Time

A GDT Time 23300 represents the time in a 24 hour day. An example is:

<WakeUpTime>08:00:00+01:00</WakeUpTime>.

The structure of GDT Time 23300 is depicted in FIG. 233. For the GDTTime 23300, the Property is Time 23302, the Representation/Associationterm is DateTime 23304, the Type term is CCT 23306, and the Type Nameterm is Time 23308.

GDT Time 23300 uses the W3C “built-in data type” xsd: time. This isstructured according to the extended representation of ISO 8601 (seewww.w3.org/TR/NOTE-datetime).

The extended representation is as follows: 1) hh:mm:ss(.sss)Z; or 2)hh:mm:ss(.sss)(+/−)hh:mm. An example for GDT Time 23300 is: 1)15:30:00Z; or 2) 10:30:00+05:00.

The extended representation for GDT Time 21800 uses the followingliterals:

-   -   1) “hh” for hours, 00-23;    -   2) “mm” for minutes, 00-59;    -   3) “ss” for seconds, 00-59;    -   4) “.sss” where one or more characters after the decimal point        represent fractions of a second, where the representation is        limited to a maximum of three decimal places, i.e., it is        possible to be accurate up to one hundredth of a second;    -   5) “:” where there may be a colon between the hours, minutes,        and seconds;    -   6) “Z” which may be specified when the represented time is also        the UTC time;    -   7) “+hh:mm” which may be specified when the represented time is        a local time that is ahead of UTC time; and    -   8) “−hh:mm” which may be specified when the represented time is        a local time that is behind UTC time.    -   The following value ranges are defined for GDT Time 21800:    -   1) Time, which represents exactly 24 hours (0-23);    -   2) Minutes, which represents exactly 60 minutes (0-59);    -   3) Seconds, which represents exactly 60 seconds (0-59); and    -   4) Time zone, which is usually expressed in UTC (Coordinated        Universal Time). If GDT Time 23300 represents a local time, the        time difference with respect to UTC time may be specified.

Time is used to represent a time on any day. Examples of times arewake-up times each day or the time start and end time of a period oftime such as the working day or lunch hour.

The time can also be specified without the additional information (Z,+hh:mm, −hh:mm) relating to the coordinated world time (UTC time).

(qqqqqqqq) TimePeriod

A GDT TimePeriod 23400 is a period that is defined by two points intime. These points in time are expressed by a time of day. This timeperiod is determined by a start time and an end time, a start time witha duration, or a duration with an end time. An example is:<WorkingTimePeriod>   <StartTime>08:00:00</StartTime>  <EndTime>16:00:00</EndTime> </WorkingTimePeriod>

The structure GDT TimePeriod 23400 is depicted in FIG. 234. The GDTTimePeriod 23400 includes elements StartTime 23406, EndTime 23422, andDuration 23438. For the GDT TimePeriod 23400, the Object Class is TimePeriod 23402 and the Property is Details 23404.

The GDT TimePeriod 23400 is an aggregation and includes the followingsub-elements: 1) StartTime 23406, 2) EndTime 23422, and 3) Duration23438.

The StartTime 23406 represents the start time in the time periodaccording to the extended representation of ISO 8601. For the StartTime23406, the Category is Element 23408, the Object Class is Time Period23410, the Property is Start Time 23412, the Representation/Associationterm is Time 23414, the Type term is GDT 23416, and the Type Name termis Time 23418. The Cardinality between the GDT TimePeriod 23400 and theStartTime 23406 is zero or one 23420.

The EndTime 23422 represents the end time in the time period accordingto the extended representation of ISO 8601. For the EndTime 23422, theCategory is Element 23424, the Object Class is Time Period 23426, theProperty is End Time 23428, the Representation/Association term is Time23430, the Type term is GDT 23432, and the Type Name term is Time 23434.The Cardinality between the GDT TimePeriod 23400 and the EndTime 23422is zero or one 23436.

The Duration 23438 may represent the relative duration according to theISO 8601 convention. The following time conventions may be used: hours(nH), minutes (nM), and seconds (n.nnnS). For the Duration 23438, theCategory is Element 23440, the Object Class is Time Period 23442, theProperty is Duration 23444, the Representation/Association term isDuration 23446, the Type term is GDT 23448, and the Type Name term isDuration 23450. The Cardinality between the GDT TimePeriod 23400 and theDuration 23438 is zero or one 23452. An example of Duration 23438 is asfollow:

<Duration>P12H10M13.3S</Duration>.

The GDT TimePeriod 23400 may contain, for example, two different times.The following illustrative combinations are possible: 1) StartTime23406+EndTime 23422; 2) StartTime 23406+Duration 23438; and 3) EndTime23422+Duration 23438. StartTime 23406 and EndTime 23422 cannot be morethan 24 hours apart. For example, if StartTime 23406 is “18:00” andEndTime 23422 “06:00,” then the value in EndTime automatically refers tothe next day.

An example of StartTime 23406 and EndTime 23422 is as follows:

<StartTime>18:00:00</StartTime><EndTime>06:00:00</EndTime>.

The period of time represented by Duration 23438 can be more than 24hours. Note that the largest value that can be specified is, forexample, hours (nH). In other words, multiple days can be expressed interms of hours.

An example of Duration 23438 is as follows: <Duration>P76H</Duration>.P76H corresponds to a duration of 3 days and 4 hours.

GDT TimePeriod 23400 can be used to express periods of time in hours,minutes, and seconds. For example, it can define the daily start timeand end time for the working day or the start time and duration of atransport.

The value in GTD TimePeriod 23400 is a relative value and is not aday-related representation of a time period that is determined by atime. If the optional reference to coordinated world time (UTC time) isnot specified, then the time should be either in the same time zone orimplicitly interpreted in the same way by the business partner so as toavoid confusion. The term “Time” in the “Object Class” of the CDT isredundant. Therefore, it consists of the term “Period.” This is becausethe term “Time” is given by the “Property” of the sub-elements. As aresult, the semantic of this CDT is unique.

(rrrrrrrr) TimeSeries

A GDT TimeSeries 23500 is time series information that consists of itemsthat each contain a period with a start time and an end time, and aperiod-based quantity or price. An example is: <TimeSeries>   <Item>      <ValidityPeriod>      <StartDateTime>2002-04-19T15:00:00Z</StartDateTime>      <EndDateTime>2002-04-19T17:00:00Z</EndDateTime>      </ValidityPeriod>       <Quantity unitCode=“PC” >150</Quantity>  </Item> </TimeSeries>.

The structure of GTD TimeSeries 23500 is depicted in FIG. 235.

The TimeSeriesItem 23506 is an item in a time series and can be repeatedas often as required.

The ValidityPeriod 23518 describes the validity period of the timeseries item with a start time stamp and an end time stamp.

The Quantity 23534 is of type GDT: Quantity and describes the quantityconnected with the time series item.

The Price 23550 describes the price connected with the time series item.

The FixedIndicator 23566 describes whether the corresponding item isblocked for changes or not.

The AdjustmentReasonCode 23582 describes the reason for a change thathas been made.

The Note 23596 is a short note for the time series item. This can be anote for the entire time series item or a note for a part of the timeseries item, e.g., a more detailed explanation of anAdjustmentReasonCode.

For the Integrity Conditions for 23500, a element Quantity or Price maybe filled. The TimeSeries 23500 is used as a generic data type that canhave various specifications in an interface depending on the contextcategory used, e.g., “Sales,” to describe sales quantities;“Consumption,” to describe consumption quantities, and the like.

(ssssssss) TimeZoneDifferenceValue

A GDT TimeZoneDifferenceValue 23600 is the difference (in hours) betweenthe local time zone and UTC (Coordinated Universal Time), which is givenas a point of reference. An example is:<TimeZoneDifferenceValue>4.5</TimeZoneDifferenceValue >.

The structure of GDT TimeZoneDifferenceValue 23600 is depicted in FIG.236. For the GDT TimeZoneDifferenceValue 23600, the Property is TimeZone Difference 23602, the Representation/Association term is Value23604, the Type term is GDT 23606, the Type Name term is DecimalValue23608, and the Length is two 23610. The GDT TimeZoneDifferenceValue23600 has, for example, a maximum value of twelve and a minimum value oftwelve 23612.

Since the W3C built-in data type “xsd: decimal” is used forTimeZoneDifference, the hours precede the comma and the minutes followit. Positive values do not need to be prefixed with a positive sign (+).However, negative values may be prefixed with a negative sign (−). Theminutes after the comma are expressed in hundredths of a minute. Forexample, the value “0,5” corresponds to 30 minutes. A facet “xsd:enumeration” is created for each valid time zone value. In this way,values in valid time zones are supported.

TimeZoneDifferenceValue is used to determine the local time zone of therelevant business partner or to determine the current time zone. Minutesare also displayed in the time difference. This is because somecountries or regions are divided into half-hour or three-quarters of anhour time zones. For example, Afghanistan (4,5), northern Australia(9,5), southern Australian (10,5), India (5,5), Nepal (5, 75), and thelike.

(tttttttt) TotalNumberValue

A GDT TotalNumberValue 23700 is the total number of elements containedin a set. An example is: <TotalNumberValue>20</TotalNumberValue>.

The structure of GDT TotalNumberValue 23700 is depicted in FIG. 237. Ina variation, non-negative, whole numbers smaller than one billion arepermitted (0-999999999) for GDT TotalNumberValue 23700. TotalNumberValuecan be used, e.g., to specify the number of objects contained in a list.The structure of GDT TotalNumberValue 23700 is depicted in FIG. 237. Forthe GDT TotalNumberValue 23700, the Representation/Association Qualityterm is Total Number 23702, the Representation/Association term is Value23704, the Type term is xsd 23706, the Type Name term isnonNegativeInteger 23708, and the Length is from one to nine 23710.

(uuuuuuuu) TransmissionID

A GDT TransmissionID 23800 is a unique identifier for a transmission.Transmission is the transfer of information that belongs together by asequence of (sub) messages. The sequence can comprise a single message.An example is:

<TransmissionID>4/7_CatalogXYZ</TransmissionID>.

The structure of GDT TransmissionID 23800 is depicted in FIG. 238.

GDT TransmissionID 23800 is a string with a maximum of forty characters.The following illustrative values are permitted: 1) Upper case lettersfrom A to Z (without German umlauts); 2) Digits from 0 to 9; 3) − (minussign); 4) _ (underscore); 5)/(forward slash); 6) \ (back slash); and 7). (period). It may be ensured that the sender and receiver use the sameGDT TransmissionID 23800 once in the communication. The structure of GDTTransmissionID 23800 is depicted in FIG. 238. For the GDT TransmissionID23800, the Object Class is Transmission 23802, the Property isIdentification 23804, the Representation/Association term is Identifier23806, the Type term is CCT 23808, the Type Name term is Identifier23810, and the Length is from one to forty 23812. The GDT TransmissionID23800 may be a restricted GDT.

GDT TransmissionID 22300 is used to transfer objects that can be dividedup and sent in multiple messages due to their large size. GDTTransmissionID can be used in such cases in the following illustrativemessages: I) In the (sub) messages, which actually transmit the object,to identify uniquely a sequence of (sub) messages that belong together;2) In messages that confirm the receipt and processing of individual(sub) messages; 3) In messages that confirm the receipt and processingof the complete sequence of (sub) messages and therefore of the completeobject; and 4) In messages that display the cancellation of thetransmission.

(vvvvvvvv) TransportMeans

A GDT TransportMeans 23900 is the description of a means of transportand can also include information for a more detailed identification. Anexample is: <TransportMeans>   <ID>HD - ES 1234</ID>  <DescriptionCode>31</DescriptionCode> </TransportMeans>.

The structure of GDT TransportMeans 23900 is depicted in FIG. 239. GDTTransportMeans 23900 is composed of the two sub-elementsTransportMeansID 23908 and TransportMeansDescriptionCode 23928 from theGlobal Data Type TransportMeansDescriptionCode 23928. The GDTTransportMeans 23900 includes elements ID 23908 and DescriptionCode23928. For the GDT TransportMeans 23900, the Object Class isTransport-Means 23902, the Property is Details 23904, and theRepresentation/Association term is Details 23906.

The TransportMeansID 23908 is used to identify the means of transport.The TransportMeansID 23908 can be, e.g., a license number for a truck orthe identification number of a container. For the ID 23908, the Categoryis Element 23910, the Object Class is Transport-Means 23912, theProperty is Identification 23914, the Representation/Association term isIdentifier 23916, the Type term is CCT 23918, the Type Name term isIdentifier 23920, and the Length is from one to twenty 23922. TheCardinality between the GDT TransportMeans 23900 and the ID 23908 iszero or one 23924. The ID 23908 may be restricted.

The TransportMeansDescriptionCode 23928 is a coded representation of thetransport means description (see also GDT:TransportMeansDescriptionCode). For the DescriptionCode 23928, theCategory is Element 23930, the Object Class is Transport-Means 23932,the Property is Description 23934, the Representation/Association termis Code 23936, the Type term is GDT 23938, and the Type Name term isTransportMeansDescriptionCode 23940. The Cardinality between the GDTTransportMeans 23900 and the DescriptionCode 23928 is one 23942.

The TransportMeansID 23908 can have a maximum of 20 characters, takinginto account the restrictions defined in the xsd: token. TheTransportMeansID 23908 refers to the transport means descriptionspecified using the TransportMeansDescriptionCode 23928. For theIntegrity Conditions for TransportMeansDescriptionCode 23928, see itsdocumentation.

The GDT: TransportMeans 23900 is used within the shipping notificationto provide a goods recipient the description and exact identification ofthe means of transport with which the goods are delivered. TheTransportMeansID 23908 corresponds to the “Means of transport ID”(TRAID) used in the R/3 in the IDOC DELVRY03. TheTransportMeansDescriptionCode 23928 corresponds with the “Means ofTransport Type” (TRATY) used in the R/3 in the IDOC DELVRY03.

(wwwwwwww) TransportMeansDescriptionCode

The GDT TransportMeansDescriptionCode 24000 is a coded representation ofthe transport means type with which goods or persons are to betransported (e.g., road tanker, barge, airplane, or refrigerated roadtanker.) An example is: <TransportMeansDescriptionCode>   1<TransportMeansDescriptionCode>.

Transportation per barge with equipment for loading and transportationof liquid chemicals.

The structure of GDT TransportMeansDescriptionCode 24000 is depicted inFIG. 240. The GDT TransportMeansDescriptionCode 24000 is of theCoreComponentType “Code.” For the GDT TransportMeansDescriptionCode24000, the Object Class is TransportMeans 24002, the Property isDescription 24004, the Representation/Association term is Code 24006,the Type term is CCT 24008, the Type Name term is Code 24010, and theLength is from one to four 24012. The GDT TransportMeansDescriptionCode24000 may be a restricted GDT.

According to the UN/EDIFACT: Data Element 8179 is the “Transport meansdescription code” allowing up to 8 alpha-numeric characters. The CodeValues for the 24000 (as copied from UN/EDIFACT) are as follows:

1) 1 Barge chemical tanker—

A barge equipped to transport liquid chemicals;

2) 2 Coaster chemical tanker—

A coaster vessel equipped to transport liquid chemicals;

3) 3 Dry bulk carrier—

Vessel designed to carry dry bulk (expellers);

4) 4 Deep sea chemical tanker—

An ocean-going vessel equipped to transport liquid chemicals;

5) 5 Gas tanker—

A vessel equipped to transport gas;

6) 6 Aircraft—

A machine capable of flight;

7) 7 Car with caravan—

A caravan towed by a car;

8) 8 Container ship—

Vessel capable of carrying containers and other cargo;

9) 9 Exceptional transport—

Transport for which common characteristics are not applicable (e.g. bigtransformers requiring special wagons, special tackles, special routingand the like.);

10) 10 Bus—

To specify that the means of transportation is a bus;

11) 11 Ship—

A large vessel navigating deep water;

12) 12 Ship tanker—

A large vessel equipped to transport liquids;

13) 13 Ocean vessel—

An ocean-going vessel that is not a ship;

14) 14 Flatbed trailer—

A means of transport identification code indicating a flatbed trailer;

Note:

1. This code value will be removed effective with directory D.02B;

15) 15 Taxi—

A means of transport identification code indicating a taxi;

16) 16 Barge—

A category of boat used to transport material over water;

17) 17 Customer determined means of transport—

The type of means of transport is to be determined by the customer;

18) 18 Seller determined means of transport—

The type of means of transport is to be determined by the seller;

19) 19 Tip-up truck—

A truck capable of tipping up in order to deliver its load;

20) 20 Furniture truck—

A truck used explicitly for the conveyance of furniture;

21) 21 Rail tanker—

A rail wagon equipped to transport liquids;

22) 22 Rail silo tanker—

Self explanatory;

Note:

1. This code value will be removed effective with directory D.04B;

23) 23 Rail bulk car—

A rail wagon equipped to transport bulk cargo;

24) 24 Customer rail tanker—

A customer-owned rail wagon equipped to transport liquids;

25) 25 Rail express—

Description to be provided;

Note:

1. This code value will be removed effective with directory D.04B;

26) 26 Tip-up articulated truck—

An articulated truck capable of tipping up in order to deliver its load;

27) 27 Rigid truck with tank—

A rigid truck fitted with a tank capable of carrying liquids or bulkgoods;

28) 28 Refrigerated truck and trailer—

A combined truck and trailer equipped to maintain refrigeratedtemperatures;

29) 29 Freezer truck and trailer—

A combined truck and trailer equipped to maintain freezing temperatures;

30) 30 Tautliner 25 ton, combined with 90 cubic meter trailer withremovable roof—

A truck with non-ridged sides, 25 ton capacity combined with a 90 cubicmeter trailer with removable roof;

31) 31 Truck—

An automotive vehicle for hauling goods;

32) 32 Road tanker—

An over-the-road tank trucker or trailer;

33) 33 Road silo tanker—

Description to be provided;

Note:

1. This code value will be removed effective with directory D.04B;

34) 34 Tautliner truck—

A truck with non-ridged sides;

35) 35 Truck/trailer with tilt—

A truck and trailer combination with a tilting capability;

36) 36 Pipeline—

A line of pipes for conveying water, gas, oil, and the like.;

37) 37 Hydrant cart—

Vehicle used at large airports with installed distribution systems tomake into-plane deliveries of fuel; distinguished from other types offuelling vehicles;

38) 38 Car—

Car;

39) 39 Tautliner truck with removable roof—

A truck with non-ridged sides and removable roof;

40) 40 Truck with opening floor—

A truck with an opening floor mechanism which is used to discharge thecargo;

41) 41 Freezer truck—

A truck equipped to maintain freezing temperatures;

42) 42 Isothermic truck—

A truck equipped to maintain controlled temperatures;

43) 43 Refrigerated truck—

A truck equipped to maintain refrigerated temperatures;

44) 44 Freezer van—

A small rigid covered vehicle for conveying frozen goods;

45) 45 Isothermic van—

A small rigid covered vehicle for conveying temperature controlledgoods;

46) 46 Refrigerated van—

A small rigid covered vehicle for conveying refrigerated goods;

47) 47 Bulk truck—

A truck suitable for transporting bulk goods;

48) 48 Van—

A small vehicle suitable for carrying small volume loads;

49) 49 Roadrailer—

Used for shipments that travel by multimodal rail or highway trailer(roadrailer);

50) 50 Passenger vessel—

Vessel for carrying passengers;

51) 51 Cargo and passenger vessel—

Vessel for carrying cargo and passengers;

52) 52 General cargo vessel—

Vessel for carrying general cargo;

53) 53 Crude oil tanker—

Vessel for carrying crude oil;

54) 54 Liquefied Petroleum Gas (LPG) carrier—

Vessel for carrying Liquefied Petroleum Gas (LPG);

55) 55 Liquefied Natural Gas (LNG) carrier—

Vessel for carrying Liquefied Natural Gas (LNG);

56) 56 Grain carrier—

Vessel for carrying grain;

57) 57 Timber or log carrier—

Vessel for carrying timber or logs;

58) 58 Wood chip carrier—

Vessel for carrying wood chips;

59) 59 Steel products vessel—

Vessel for carrying steel products;

60) 60 Gravel vessel—

Vessel for carrying gravel;

61) 61 Cement vessel—

Vessel for carrying cement in bulk;

62) 62 Coal vessel—

Vessel for carrying coal;

63) 63 Ore carrier—

Vessel for carrying ore in bulk;

64) 64 Car carrier—

Vessel for carrying complete cars and/or their knock-down parts;

65) 65 Container only vessel—

Vessel for carrying containers only;

66) 66 Roll on-roll off vessel—

A vessel capable of carrying roll on-roll off cargo;

67) 67 Ferry—

A means of transport for carrying passengers and/or vehicles on aregular basis;

68) 68 Fishing vessel—

Vessel used in the catching of fish;

69) 69 Work vessel;

A vessel engaged in “port and harbor work,” which means construction,improvement, maintenance or rehabilitation of port and harborfacilities. Dredger, floating crane, sand carrier with grab bucket areincluded in this type of the means of transport.

70) 70 Patrol vessel—

A vessel to patrol port or coastal area;

71) 71 Tug and/or push boat—

A vessel to push and/or pull other vessels;

72) 72 Train with one wagon—

A train with a single wagon used to carry goods;

73) 73 Train with more than one and less than 20 wagons—

A train with more than one and less than 20 wagons used to carry goods;

74) 74 Train with 20 or more wagons—

A train with 20 or more wagons used to carry goods;

75) 75 Oil products tanker—

A vessel for carrying products derived from crude oil;

76) 76 Training vessel—

A vessel for learning maritime skills;

77) 77 Freezer truck and isothermic trailer—

A combined freezer truck and isothermic trailer;

78) 78 Isothermic truck and isothermic trailer—

A truck and a trailer equipped to maintain controlled temperatures;

79) 79 Refrigerated truck and isothermic trailer—

A combined refrigerated truck and isothermic trailer;

80) 80 Freezer truck and refrigerated trailer—

A combined freezer truck and refrigerated trailer;

81) 81 Isothermic truck and refrigerated trailer—

A combined isothermic truck and refrigerated trailer;

82) 82 Rigid truck with tank and tank trailer—

A combined rigid truck with tank and tank trailer;

83) 83 Bulk truck and tank trailer—

A combined truck capable of carrying liquids or bulk goods and a tanktrailer;

84) 84 Rigid truck with tank and bulk trailer—

A combined rigid truck with tank and a trailer capable of carryingliquids or bulk goods;

85) 85 Bulk truck and bulk trailer—

A combined truck and a trailer both capable of carrying liquids or bulkgoods;

86) 86 Tautliner truck and extendable trailer—

A combined tautliner truck and extendable trailer;

87) 87 Tautliner truck with removable roof and extendable trailer—

A combined tautliner truck with removable roof and extendable trailer;

88) 88 Truck with opening floor and extendable trailer—

A combined truck with opening floor and extendable trailer;

89) 89 Bulk truck and extendable trailer—

A combined truck capable of carrying liquids or bulk goods and anextendable trailer;

90) 90 Isothermic truck and freezer trailer—

A combined isothermic truck and freezer trailer;

91) 91 Refrigerated truck and freezer trailer—

A combined refrigerated truck and freezer trailer;

92) 92 Tip-up truck and gondola trailer—

A combined tip-up truck and gondola trailer. A gondola trailer is asplit level trailer suitable for the transport of heavy machinery;

93) 93 Tautliner truck and gondola trailer—

A combined tautliner truck and gondola trailer. A gondola trailer is asplit level trailer suitable for the transport of heavy machinery;

94) 94 Tautliner truck with removable roof and gondola trailer—

A combined tautliner truck with removable roof and gondola trailer. Agondola trailer is a split level trailer suitable for the transport ofheavy machinery;

95) 95 Truck with opening floor and gondola trailer—

A combined truck with opening floor and gondola trailer. A gondolatrailer is a split level trailer suitable for the transport of heavymachinery;

96) 96 Bulk truck and gondola trailer—

A combined truck capable of carrying liquids or bulk goods and a gondolatrailer. A gondola trailer is a split level trailer suitable for thetransport of heavy machinery;

97) 97 Tip-up truck and extendable gondola trailer—

A combined tip-up truck with extendable gondola trailer. An extendablegondola trailer is a trailer fitted with a rear axle which can beextended to cater for variable length and is suitable for the transportof heavy machinery;

98) 98 Tautliner truck and extendable gondola trailer—

A combined tautliner truck and extendable gondola trailer. An extendablegondola trailer is a trailer fitted with a rear axle that can beextended to cater for variable length and is suitable for the transportof heavy machinery;

99) 99 Tautliner truck with removable roof and extendablegondolatrailer—

A combined tautliner truck with removable roof and extendable gondolatrailer. An extendable gondola trailer is a trailer fitted with a rearaxle that can be extended to cater for variable length and is suitablefor the transport of heavy machinery;

100) 100 Truck with opening floor and extendable gondola trailer—

A combined truck with opening floor and extendable gondola trailer. Anextendable gondola trailer is a trailer fitted with a rear axle that canbe extended to cater for variable length and is suitable for thetransport of heavy machinery;

101) 101 Bulk truck and extendable gondola trailer—

A combined truck capable of carrying liquids or bulk goods and aextendable gondola trailer. An extendable gondola trailer is a trailerfitted with a rear axle that can be extended to cater for variablelength and is suitable for the transport of heavy machinery;

102) 102 Tip-up truck and trailer with opening floor—

A combined tip-up truck and trailer with opening floor;

103) 103 Tautliner truck and trailer with opening floor—

A combined tautliner truck and trailer with opening floor;

104) 104 Tautliner truck with removable roof and trailer with openingfloor—

A combined tautliner truck with removable roof and trailer with openingfloor;

105) 105 Truck and trailer with opening floor—

A combined truck and a trailer with an opening floor;

106) 106 Bulk truck and trailer with opening floor—

A combined truck capable of carrying liquids or bulk goods and a trailerwith opening floor;

107) 107 Removal truck and trailer—

A combined truck and trailer capable of carrying household effects;

108) 108 Tautliner truck and removal trailer—

A combined tautliner truck and trailer capable of carrying householdeffects;

109) 109 Tautliner truck with removable roof and removal trailer—

A combined tautliner truck with a removable roof and a trailer capableof carrying household effects; and

110) 110 Vessel, temperature controlled cargo—

A vessel to carry temperature controlled cargo.

The TransportMeansDescriptionCode is used to determine concrete means oftransportation. (See R/3: Means-of-Transport Type: CHAR 4).

(xxxxxxxx) TransportModeCode

The GDT TransportModeCode 24100 is a coded representation of the mode oftransportation used for delivery. An example is: <TransportModeCode>   1<\TransportModeCode>

Conveyance per transportation by sea

The structure of GDT TransportModeCode 24100 is depicted in FIG. 241.For the GDT TransportModeCode 24100, the Object Class is Transport Mode24102, the Property is Code 24104, the Representation/Association termis Code 24106, the Type term is CCT 24108, the Type Name term is Code24110, and the Length is from one to two 24112. The GDTTransportModeCode 24100 may be a restricted GDT.

See UN/EDIFACT: Data Element 8067 (“Transport mode name code”): an.3 (upto 3 alpha-numeric characters), Code values as UN/EDIFACT Recommendation19 (“Code for Modes of Transport”).

This code list can be represented in a 2-character field. Therefore, thefield is defined here as a 2-character field using the corresponding R/3applications to avoid mapping problems.

The GDT TranportModeCode 24100 can contain codes that are included inthe following code list. 0 Transport mode not specified Transport modehas not been specified Notes: 1) This code can be used when the mode isnot known or when information on it is not available at the time ofissuing the document concerned. 1 Maritime transport Transport of goodsand/or persons is by sea. 2 Rail transport Transport of goods and/orpersons is by rail. 3 Road transport Transport of goods and/or personsis by sea. 4 Air transport Transport of goods and/or persons is by air.5 Mail Method to convey goods is by mail Notes: 1) This code is providedfor practical reasons, despite the fact that mail is not a genuine modeof transport. In many countries, the value of merchandise exported andimported by mail is considerable, but the exporter or importer concernedwould be unable to state by which mode postal items had been conveyed. 6Multimodal transport Method to convey goods and/or persons is bymultimodal transport. Notes: 1) This code is provided for practicalreasons, despite the fact that multimodal transport is not a genuinemode of transport. It can be used when goods are carried by at least twodifferent modes from a place at which the goods are taken in charge by atransport operator to a place designated for delivery, on the basis ofone transport contract. (Operations of pick-up and delivery of goodscarried out in the performance of a single mode of transport, as definedin such a contract, shall not be considered as multimodal transport). 7Fixed transport installation Transport of item is via a fixed transportinstallation. Notes: 1) This code applies to installations forcontinuous transport such as pipelines, ropeways and electric powerlines. 8 Inland water transport Transport of goods and/or persons is byinland water. 9 Transport mode not applicable The mode of transport isnot applicable.

With the specification of the TransportMode, other conditions areusually linked in the general business conditions that are implicitlyagreed upon/defined by specifying a TransportMode (e.g., price, timeduring which delivery can be made, or any service agent. TheTransportModeCode acts for the executing partner/vendor as a criterionfor grouping deliveries into transports and for route determination inR/3, for example. Furthermore, it is the basis for determining concretetransportation routes, means of transport, and responsible organizationunits (e.g., materials planning point). The TransportMode“MaritimeTransport” implies a sea route and the necessity ofcustoms/port procedures, for example. These specifications may also berequired for contractual reasons. In many countries, they are requiredfor customs clearance and statistical purposes.

The 24100 illustratively corresponds to R/3: Shipping Type: CHAR 2. TheGDT TranportModeCode 24100 is included in the ordered service. It maynot define any concrete route or means of transportation.

(yyyyyyyy) TransportServiceLevelCode

The GDT TransportServiceLevelCode 24200 is a coded representation of theagreed/defined services in terms of the delivery of goods with respectto the speed of the delivery (as part of the ordered service). Anexample or instance is:

-   -   <TransportServiceLevelCode>01<\TransportServiceLevelCode>.

Customer wants express transportation and accepts the associatedincreased cost of transport. Delivery made in 24 hours by the latest.”

The structure of GDT TransportServiceLevelCode 24200 is depicted in FIG.242. For the GDT TransportServiceLevelCode 24200, the Object Class isTransport 24202, the Property is ServiceLevelCode 24204, theRepresentation/Association term is Code 24206, the Type term is CCT24208, the Type Name term is Code 24210, and the Length is from one totwo 24212. The GDT TransportServiceLevelCode 24200 may be a restrictedGDT. (Comment: Length 2 using the analogous field in R/3)

The GDT TransportServiceLevelCode 24200 is represented by a 2-characterstring and can include codes from the following code list:. (UN/EDIFACT:Data Element 4219 (“Transport service priority code”): an.3 (up to 3alpha-numeric characters) BUT). This code list can be represented in a2-character field. Therefore, the field is defined here as a 2-characterfield in accordance with the corresponding R/3 applications to avoidmapping problems. The code list includes the following codes:

-   -   1) 1—Express which is for express treatment (if by rail, legal        express regime for parcels transport).    -   2) 2—High speed which is for transport under legal international        rail convention (CIM) concluded between rail organizations and        based on fast routing and specified timetables.    -   3) 3—Normal speed which is for Transport under legal        international rail convention (CIM) concluded between rail        organizations.    -   4) 4—Post service which is for Transport under conditions        specified by UPU (Universal Postal Union) and Rail organizations        (parcels transport only).

With the specification of the GDT TranportServiceLevelCode 24200, otherconditions may be linked in the general business conditions that areimplicitly agreed on/defined by specifying a TransporServiceLevel (e.g.,price, guaranteed time during which delivery may be made, any agent,entitlements in case of non-compliance).

The buyer and seller/service agent use the GDT TransportServiceLevelCode24200 to agree on the modalities to be used for delivery and the buyeraccepts the corresponding conditions.

Using this specification, the seller can determine (depending on thebusiness process) the internal shipping point to be used for thisdelivery, which service agent is to be used under what conditions, andthe like.

In the framework of this agreement, the service agent/seller guaranteesthe customer a maximum period (e.g., 24 hours) within which delivery isto be made, and the like. If these conditions are breached, liabilityclaims against the seller may arise.

In R/3, a TransportServiceLevelCode is assigned either to a salesdocument type or to a sold-to party.

Depending on the specified TransportServiceLevelCode (along with loadinggroup and plant), a suitable shipping point can be determined that isresponsible for the corresponding process.

Along with the country and the geographic zone of the shipping point,the ship-to party and the transportation group, a suitable route can bedetermined. (The same applies to deliveries—the geography of the sellerand the goods receiving point determines the transportation group andshipping conditions.)

The 24200 may correspond to R/3: Shipping Condition: CHAR 2. Thedifference between PriorityCode and TransportServiceLevelCode is thatwhen using the PriorityCode an urgency, from the buyer's perspective, isassigned to an object (e.g., an item) in terms of delivery, e.g., fromwhich a ServiceLevel may be derived within the business process at theseller. When specifying a TransportServiceLevel, a business agreementwith the partner occurs. For example, when the buyer gives his seller apriority. Seller agrees on a Service Level with his transportationservice provider according to buyer's priority.

(zzzzzzzz) TransportTracking

A GDT TransportTracking 24300 contains transport-related informationthat can be used for tracking deliveries, e.g., in the framework ofgoods deliveries. An example or instance is:   <TransportTracking>  <ID>4711</ID>     <WebAddress>www.mayerexpressdienst.com/TrackingHomePage.htm</WebAddress>   </TransportTracking>.

The structure of GDT TransportTracking 24300 is depicted in FIG. 243.The GDT TransportTracking 24300 includes elements ID 24308 andWebAddress 24326. For the GDT TransportTracking 24300, the Object Classis TransportTracking 24302, the Property is Details 24304, and theRepresentation/Association term is Details 24306.

The GDT TransportTrackingID 24308 is a unique identifier of a shipment,for example, a package or a container. For the ID 24308, the Category isElement 24310, the Object Class is TransportTracking 24312, the Propertyis Identification 24314, the Representation/Association term isIdentifier 24316, the Type term is CCT 24318, the Type Name term isIdentifier 24320, and the Length is from one to thirty-five 24322. TheCardinality between the GDT TransportTracking 24300 and the ID 24308 isone 24323. The ID 24308 may be restricted 24324. TheTransportTrackingWebAddress 24326 specifies an address in the World WideWeb that can be used to track delivery with the TransportTrackingID. Forthe WebAddress 24326, the Category is Element 24328, the Object Class isTransportTracking 24330, the Property is WebAddress 24332, theRepresentation/Association term is ElectronicAddress 24334, the Typeterm is GDT 24336, and the Type Name term is WebAddress 24338. TheCardinality between the GDT TransportTracking 24300 and the WebAddress24326 is zero or one 24340.

If a courier, express, and package service provider is responsible forthe goods delivery, it may determine the format of theTransportTrackingID. The TransportTrackingWebAddress includes, e.g., thehomepage of the supplier of the delivery tracking service.

The TransportTrackingID can have a maximum of 35 characters, taking intoaccount the restrictions defined in the xsd: token. TheTransportTrackingID is unique in connection with the business partnerproviding the delivery tracking service. The identification of thebusiness partner is carried out as context information in the message.It can also take place using the TransportTrackingWebAddress.

The TransportTrackingWebAddress can include every URI (see also thedefinition of GDT: WebAddress) and can have a maximum 255-characterstring.

The GDT TransportTracking is used in the framework of the shippingnotification to provide a goods recipient an identification and anInternet address for the online delivery tracking of the currentdelivered goods. The TransportTrackingID corresponds to the TrackingNumber (TRACKN) used in the R/3 in the IDOC DELVRY03. TheTransportTrackingWebAddress may correspond to the “URL for ForwardingAgent” (XSIURL_MULTI_TRACK) used in the R/3 in the IDOC DELVRY03.

(aaaaaaaaa) TupleLengthValue

A GDT TupleLengthValue 24400 is the number of entries in a tuple. Atuple is a linear set with a fixed number of elements. The elements of atuple are also referred to as entries and can be of different types. Anexample is:

<TupleLengthValue>7</TupleLengthValue>.

The structure of GDT TupleLengthValue 24400 is depicted in FIG. 244. Forthe GDT TupleLengthValue 24400, the Representation/Association Qualityterm is Tuple Length 24402, the Representation/Association term is Value24404, the Type term is xsd 24406, the Type Name term isnonNegativeInteger 24408, and the Length is from one to two 24410.

The GDT TupleLengthValue 24400 is a qualified basic GDT based on thesecondary Representation/Association Value of the CCT Numeric and arestriction of xsd: decimal. In a variation, non-negative whole numbersless than one hundred are permitted. The tuple length indicates whethera tuple is a pair (length=2), triple (length=3), quadruple (length=4),quintuple (length=5), and the like. Tuple lengths greater than 3 areusually referred to as 4-tuples, 5-tuples, and so on (or generally asn-tuples). A list differs from a tuple in that its length is flexible.An array is different from a tuple in that its elements can be indexedand in that it can have a higher dimension (2-dimensional arrays,3-dimensional arrays, and the like). Furthermore, the entries in a listand the elements in an array are usually of the same type. A vector is aspecial instance of a one-dimensional array that is subject toadditional mathematical rules (such as, e.g., vector addition).

(bbbbbbbbb) UnplannedItemPermissionCode

The GDT UnplannedItemPermissionCode 24500 is a coded representation ofthe permission to enter additional, unplanned items in a businessfollow-up document. An example is:<UnplannedItemPermissionCode>01</UnplannedItemPermissionCode>.

The structure of GDT Unplanned Item Permission Code 24500 is depicted inFIG. 245. For the GDT Unplanned Item Permission Code 24500, the ObjectClass is Unplanned Item 24502, the Property is Permission Code 24504,the Representation/Association term is Code 24506, the Type term is CCT24508, the Type Name term is Code 24510, and the Length is two 24512.The GDT Unplanned Item Permission Code 24500 may be a restricted GDT.

UnplannedItemPermissionCode can have the following illustrativevalues: 1) “01” which means NotAllowed. In follow-up documents,unplanned items are not allowed to refer to an item indicated in thisway. 2) “02” which means WithContractReferenceOnly. In follow-updocuments, unplanned items with a contract reference are allowed torefer to an item indicated in this way. 3) “03” which means Allowed. Infollow-up documents, unplanned items are allowed to refer to an itemindicated in this way.

The GDT UnplannedItemPermissionCode 24500 is used to show businesspartners whether or not they are allowed to enter additional items foran item in a document in a subsequent process. For example, in apurchase order, the buyer informs the seller whether or not it canspecify additional unplanned items for a purchase order item in theinvoice. This is useful if the requirements are unknown at the time ofordering. This can be the case for repairs, where the spare partsrequired are not known until the repair has been made. The GDTUnplannedItemPermissionCode 24500 may be a proprietary code list withfixed predefined values. Changes to the permitted values may involvechanges to the interface.

(ccccccccc) ValueDifferenceIndicator

A GDT ValueDifferenceIndicator 24600 indicates whether or not avalue-related difference exists. An example is:

<ValueDifferenceIndicator>true</ValueDifferenceIndicator>.

The structure of GDT ValueDifferenceIndicator 24600 is depicted in FIG.246. For the GDT ValueDifferenceIndicator 24600, the Property isValueDifference 24602, the Representation/Association term is Indicator24604, the Type term is CCT 24606, and the Type Name term is Indicator246808.

The GDT ValueDifferenceIndicator 24600 can have the followingillustrative values: 1) true, which means the difference isvalue-related; or 2) false, which means the difference is notvalue-related. (See CCT: Indicator for value range).

Each ValueDifferenceIndicator may refer to a business object or to alist of similar business objects. This relationship is reflected in acorresponding refinement of the “value” name prefix. This name prefix isomitted when actually used in tag names. For example, anAmountDifferenceIndicator is the specification of whether there is avalue-related difference for a money amount. Other possible forms areQuantityDifferenceIndicator, MeasureDifferenceIndicator, andPriceDifferenceIndicator.

The ValueDifferenceIndicator can be used to display whether the currentvalue is specified for a business variable or the difference to anearlier value. Another possible use is the specification of whether itis an actual or a target value or the difference between the two. In thecontext of an interface, the business meaning of the values for theValueDifferenceIndicator may be described in addition to the name prefix(see Integrity Conditions) being specified.

(ddddddddd) ValueUnlimitedIndicator

A GDT ValueUnlimitedIndicator 24700 indicates whether a value isunlimited or not. An example is:<ValueUnlimitedIndicator>true</ValueUnlimitedIndicator>.

The structure of GDT Value Unlimited Indicator 24700 is depicted in FIG.247. For the GDT Value Unlimited Indicator 24700, the Object Class isValue 24702, the Property is Unlimited Indicator 24704, theRepresentation/Association term is Indicator 24706, the Type term is CCT24708, and the Type Name term is Indicator 24710.

The ValueUnlimitedIndicator can have the following illustrativevalues: 1) true, which means a value is unlimited; or 2) false, whichmeans a value is not unlimited. (See CCT Indicator for value range).

The default for a ValueUnlimitedIndicator may be ‘false’ so that whenValueUnlimitedIndicator is not present it is equal to aValueUnlimitedIndicator with the value ‘false’. If aValueUnlimitedIndicator has the value ‘true’, then the correspondingnumerical element may be nonexistent, empty or initial. AValueUnlimitedIndicator is used with reference to a numerical element ifthis element can have values that are unlimited in size. The referenceto a particular element may be apparent when usingValueUnlimitedIndicator. The relationship to a numerical element isreflected in a corresponding refinement of the “value” name prefix. Thisname prefix is omitted when actually used in tag names. A good exampleof the use of the ValueUnlimitedIndicator is the QuantityTolerance GDT.The ValueUnlimitedIndicator is used in this GDT to display any sizetolerance.

(eeeeeeeee) VersionID

A GDT VersionID 24800 is a unique identifier for a version. A version isa differentiation of objects of an object type in accordance with thesequence in which they were created. An example is:<VersionID>1.1.5<VersionID>.

The structure of GDT VersionID 24800 is depicted in FIG. 248. For theGDT VersionID 24800, the Category is Element 24802, the Object Class isVersion 24804, the Property is Identification 24806, theRepresentation/Association term is Identifier 24808, the Type term isCCT 24810, the Type Name term is Identifier 24812, and the Length isfrom one to thirty-two 24814. The GDT VersionID 24800 may be arestricted GDT.

Versions can be differentiated using the criteria before-after. They aresorted “in turn.” A version can be referenced directly externally byspecifying the object and its GDT VersionID 23300. It has the followingcharacteristics: 1) It describes different characteristics of an objectfor external users; 2) It represents a significant change compared toother versions from a user perspective; 3) It is independent andself-contained, i.e., changes to one version do not affect otherversions; 4) Versions can be developed further in parallel; and 5) Theformat of the version is up to the application in which the object islocated. Examples are X.Y.Z or a time stamp. A variant is thedifferentiation of objects of an object type at the same point in time.

(fffffffff) VisibleIndicator

A GDT VisibleIndicator 24900 indicates whether something is visible ornot. The word “something” generally stands for specific characters,documents, properties, or facts. An example is:<PropertyVisibleIndicator>true</PropertyVisibleIndicator>.

The structure of GDT VisibleIndicator 24900 is depicted in FIG. 249. Forthe GDT VisibleIndicator 24900, the Property is Visible 24902, theRepresentation/Association term is Indicator 24904, the Type term is CCT24906, and the Type Name term is Indicator 24908.

The GDT VisibleIndicator 24900 can have the following values: 1) true,which means something is visible; or 2) false, which means something isnot visible. (For value range, see CCT: Indicator)

For each GDT VisibleIndicator 24900, there may be specified what isvisible or not visible. This is reflected in an appropriate name prefix.For example, a PropertyVisibleIndicator indicates whether a property isvisible or not. The GDT VisibleIndicator 24900 can be used, e.g., toindicate whether certain properties of a product are to be visible to acustomer. In the context of an interface, the business significance of“what is visible” may be described in greater detail for the GDTVisibleIndicator 24900 in addition to its name prefix (see IntegrityConditions).

(ggggggggg) WebAddress

A GDT WebAddress 25000 is a unique digital address for a document thatis available on the World Wide Web. The document contains informationrequired by the user and is based on hypertext technology. An exampleis:

<WebAddress>

-   -   www.sap.com/GlobalDataTypes.htm

</WebAddress>

The structure of GDT Web Address 25000 is depicted in FIG. 250. The GDTWeb Address 25000 includes attribute language Code 25016. For the GDTWeb Address 25000, the Object Class is WebAddress 25002, the Property isAddress 25004, the Representation/Association term is Electronic Address13506, the Type term is CCT 25008, the Type Name term is ElectronicAddress 25010, and the Length is from one to two-hundred fifty-five25012.

The syntax of the built-in data type “xsd: anyURI” is defined in theIETF RFC 2396 recommendation. For more details, see the “SAP CoreComponent Types” specification document.

The following URI schemes can be used from the list of available URIschemes (see also Uniform Resource Identifier (URI) Schemes): SchemeName Description Reference ftp File Transfer Protocol [IETF RFC 1738]http Hypertext Transfer Protocol [IETF RFC 2616] Gopher The GopherProtocol [IETF RFC 1738] News USENET news [IETF RFC 1738] nntp USENETnews using NNTP access [IETF RFC 1738] wais Wide Area InformationServers [IETF RFC 1738] File Host-specific file names [IETF RFC 1738]prospero Prospero Directory Service [IETF RFC 1738] Service servicelocation [IETF RFC 2609] Nfs network file system protocol [IETF RFC2224] https Hypertext Transfer Protocol Secure [IETF RFC 2818]

The following attribute can be used for the GDT WebAddress 25000:

-   -   languageCode, which defines the language of the hypertext        contents in accordance with the RFC 3066 recommendation. The        language code can also be included if a translation service is        to be automatically triggered at the receiver. For the language        Code 25016, the Category is Attribute 25018, the Object Class is        WebAddress 25020, the Property is Language Code 25022, the        Representation/Association term is code 25024, the Type term is        xsd 25026, the Type Name term is Language 25028, and the Length        is from two to nine 25030. The Cardinality between the GDT Web        Address 25000 and the language Code 25016 is zero or one 25032.    -   GDT WebAddress 25000 may be used for linking to further        information for the user. For example, the information might be        detailed, hypertext-based information about a product,        organization, or company. In a variation, the hypertext        documents linked to by means of WebAddress may not be used for        further process-dependent processing.

(hhhhhhhhh) WorkAgreementID

A GDT WorkAgreementID 25100 is a unique ID for a work agreement. A workagreement is an agreement between an employee and an employer. Theemployee agrees to perform work and the employer agrees to provideremuneration for the work performed. A work agreement comprises numerousother obligations, in addition to the main obligation (remuneration forwork), e.g., obligations in terms of loyalty, reporting, and benefits.Examples of work agreements include employment contracts, placementcontracts, traineeships, and training contracts. An example is:

<WorkAgreementID>1234567890123456</WorkAgreementID>.

The structure of GDT WorkAgreementID 25100 is depicted in FIG. 251.

The schemeID indicates the scheme according to which the identifier wasassigned. Currently, the following illustrative schemes aresupported: 1) WorkAgreementGUID, which identifies the work agreementusing a Global Unique Identifier, and 2) WorkAgreementID, whichidentifies the work agreement using an internal identifier of theschemeAgency.

The schemeAgencyID specifies the business system in which the ID wasassigned. If the “WorkAgreementGUID” is used for the schemeID, theWorkAgreementID may comprise one to forty places. If the WorkAgreementIDis used, the WorkAgreementID may comprise 1 to 16 places and may bealphanumeric.

If the schemeID or schemeAgencyID have not been specified, it may bepossible to determine them from the context. The WorkAgreementID may beused in the same way as the personnel number in the R/3 System.

(iiiiiiiii) BusinessTransactionDocumentItemProcessingTypeCode

A BusinessTransactionDocumentItemProcessingTypeCode 31800 is the codedrepresentation of the way in which an item in a business document isprocessed. In a variation, aBusinessTransactionDocumentItemProcessingTypeCode 31800 is defined as atransaction item type in the business transaction of the SAP CRM/EBP 4.0object model. The code can control the internal behavior of a documentand its structure, among other things. An example (instance) ofBusinessTransactionDocumentItemProcessingTypeCode 31800 is:

<BusinessTransactionDocumentItemProcessingTypeCode>DLV</BusinessTransactionDocumentItemProcessingTypeCode>.

The GDT BusinessTransactionDocumentItemProcessingTypeCode 31800 isdepicted in FIG. 318. For the GDTBusinessTransactionDocumentItemProcessingTypeCode 318, the Object Classterm is Business Transaction Document Item 31802, the Property term isProcessing Type 31804, the Representation/Association term is Code31806, the Type term is CCT 31808, the Type Name term is Code 31810, andthe Length is from one to four 31812.

The BusinessTransactionDocumentItemProcessingTypeCode 31800 is acustomer-specific code list. In a variation, aBusinessTransactionDocumentItemProcessingTypeCode 31800 refers to asingle BusinessTransactionDocumentItemTypeCode. ABusinessTransactionDocumentProcessingTypeCode may be used for businessobjects. The BusinessTransactionDocumentItemProcessingTypeCode 31800 canbe used to control the processes relating to a document item (defined bythe BusinessTransactionDocumentItemTypeCode). The following are examplesof code semantics:

Delivery: DLV Standard delivery item type

Delivery: RET Standard returns item type

Sales order: TAN Standard order item type

In an illustrative examples, delivery item type, purchase order itemtype, order item type, or CRM/SRM item type are equivalents in R/3 andCRM/SRM. A GDT length of four was selected, in line with these.

The code differs from the BusinessTransactionDocumentItemTypeCode asfollows: BusinessTransactionDocumentItemTypeCode is the codedrepresentation of an item type in a document occurring in the context ofbusiness transactions. The document item type describes the (business)nature of document items that are similar and defines the basicproperties of document items of this type. The code differs from theDeliveryTypeCode as follows: DeliveryTypeCode is the codedrepresentation of a delivery type, which describes the business natureand basic properties of the delivery for the purposes of its logisticalprocessing.

(jjjjjjjjj) BusinessTransactionDocumentProcessingTypeCode

The GDT BusinessTransactionDocumentProcessingTypeCode 31900 is the codedrepresentation of the way in which a business document is processed. Ina variation, the GDT BusinessTransactionDocumentProcessingTypeCode 31900is a transaction type in the business transaction of the SAP CRM/EBP 4.0object model. The code can control the internal behavior of a documentand its structure, among other things. An example of GDTBusinessTransactionDocumentProcessingTypeCode 31900 is:

<BusinessTransactionDocumentProcessingTypeCode>DLVO</BusinessTransactionDocumentProcessingTypeCode>

The GDT BusinessTransactionDocumentProcessingTypeCode 31900 is depictedin FIG. 319. For the GDT BusinessTransactionDocumentProcessingTypeCode31900, the Object Class term is Business Transaction Document 31902, theProperty term is Processing Type 31904, the Representation/Associationterm is Code 31906, the Type term is CCT 31908, the Type Name term isCode 31910, and the Length is from one to four 31912.

The BusinessTransactionDocumentProcessingTypeCode 31900 is acustomer-specific code list and refers to a singleBusinessTransactionDocumentTypeCode. ABusinessTransactionDocumentProcessingTypeCode 31900 may be used forbusiness objects. The BusinessTransactionDocumentProcessingTypeCode31900 may be used to control the methods of processing a document(defined by the BusinessTransactionDocumentTypeCode). The following areexamples of code semantics:

Delivery: Standard delivery type (DLVO)

Sales order: Standard order type (TA)

In a variation, delivery type, purchase order type, order type, orCRM/SRM transaction type are equivalents in R/3 and CRM/SRM. A GDTlength of four was selected, in line with these.

The BusinessTransactionDocumentProcessingTypeCode 31900 differs fromBusinessTransactionDocumentTypeCode as follows:BusinessTransactionDocumentTypeCode is the coded representation of atype of document occurring in the context of business transactions. Thedocument type describes the (business) nature of documents that are verysimilar and defines the basic properties of documents of this type. TheBusinessTransactionDocumentTypeCode is a prefix for references, amongother things.

The BusinessTransactionDocumentProcessingTypeCode 31900 differs fromBusinessTransactionTypeCode as follows: BusinessTransactionTypeCode isthe coded representation of a business transaction type.BusinessTransactionTypeCode is cross-BTD and describes the businesstransaction as such.

The BusinessTransactionDocumentProcessingTypeCode 31900 differs fromDeliveryTypeCode as follows: DeliveryTypeCode is the codedrepresentation of a delivery type, which describes the business natureand basic properties of the delivery for the purposes of its logisticalprocessing.

(kkkkkkkkk) CancellationReasonCode

The GDT CancellationReasonCode 32000 is a coded representation for thereason for a cancellation. An example (instance) for the GDTCancellationReasonCode 32000 is: <ReplenishmentOrder>   ...   <Item>    <CancellationReasonCode>1</CancellationReasonCode>   </Item>   ...</ReplenishmentOrder>.

The GDT CancellationReasonCode 32000 is depicted in FIG. 320. For theGDT CancellationReasonCode 320, the Property term is Cancellation Reason32002, the Representation/Association term is Code 32004, the Type termis CCT 32006, the Type Name term is Code 32008, and the Length is fromone to four 32010.

In a variation, the CancellationReasonCode 32000 may be, for example, aSAP-owned code list. Illustrative values (tailored first to thelogistics demand) may be as shown in the following table: Code NameDescription 1 Delivery date too The delivery date is too late for thesuccessful late processing of the business transaction. 2 Delivery datetoo The delivery date is too early for the successful early processingof the business transaction. 3 Delivery quantity The delivery quantityis too large for the too large successful processing of the businesstransaction. 4 Delivery quantity The delivery quantity is too small forthe too small successful processing of the business transaction. 5Quality of the The quality of the substitute product is substituteproduct inadequate for successful processing of the is inadequatebusiness transaction.

For each type of BusinessTransactionDocument it may be specified whichCancellationReasonCodes 32000 are permitted. The CancellationReasonCode32000 is used to motivate a cancellation from a business point of view.A reason for the cancellation may be specified, in particular in thecase of document changes on the basis of previous confirmations by thebusiness partner.

In an example, in SAP R/3, the data element ABGRU (cancellation reasoncode for quotations and orders) may correspond to theCancellationReasonCode 32000.

(lllllllll) CashDiscountDeductibleIndicator

The GDT CashDiscountDeductibleIndicator 32100 specifies whether a cashdiscount can be deducted from something or not. That “something” may be,for example, an invoice, credit memo, purchase order, sales order, or acorresponding item. An example (instance) for the GDTCashDiscountDeductibleIndicator 32100 is:

<CashDiscountDeductibleIndicator>true</CashDiscountDeductibleIndicator>.

The GDT CashDiscountDeductibleIndicator 32100 is depicted in FIG. 321.For the GDT CashDiscountDeductibleIndicator 32100, the Property term isCashDiscountDeductible 32102, the Representation/Association term isIndicator 32104, the Type term is CCT 32106, and the Type Name term isIndicator 32108.

Illustrative values of the CashDiscountDeductibleIndicator 32100 may beas follows:

true: Discount can be deducted.

false: Discount cannot be deducted.

(for the value range, see CCT: Indicator).

CashDiscountDeductibleIndicator 32100 may be used to specify whether acash discount can be deducted, for example, from an invoice item at thetime of payment.

(mmmmmmmmm) CustomsCommodityClassificationCode

The GDT CustomsCommodityClassificationCode 32200 is a codedrepresentation of the customs-related classification of trading goods.An example (instance) of the GDT CustomsCommodityClassificationCode32200 is:

<CustomsCommodityClassificationCode>85281252000</CustomsCommodityClassificationCode>.

In the above example, the code stands for “Television receivers, color,with integral tube, with a screen width/height ratio kl. 1, 5, with adiagonal measurement of the screen of kl.=42 cm (excluding incorporatingvideo-recording or reproducing apparatus and video monitors).”

The GDT CustomsCommodityClassificationCode 32200 is depicted in FIG.322. For the GDT CustomsCommodityClassificationCode 32200, the ObjectClass term is Customs 32202, the Property term isCommodityClassification 32204, the Representation/Association term isCode 32206, the Type term is CCT 32208, the Type Name term is Code32210, and the Length is between four and eleven 32212. The GDTCustomsCommodityClassificationCode 32200 may be restricted 32214.

In a variation, all character strings from four to 11 characters areallowed as value ranges. The CustomsCommodityClassificationCode 32200may be structured as follows:

One-two characters: Chapter (for example, clothing made of wovenfabric—Chapter 62)

Three-four characters: Item (for example, ladies' coats—Item 6202)

Five-six characters: Subitem Harmonized System (for example, ladies'coats made of wool—Subitem 6202 11)

Seven-eight characters: Combined Nomenclature (for example, ladies'coats made of wool, hand-made—6202 11 00)

Nine-11 characters: International and National Features (for example,ladies' coats made of wool, hand-made, ponchos—6202 11 00 0)

The basis for the first six characters of the code may be the HarmonizedSystem (HS) that is managed by the World Customs Organization (WCO) andmay provide an internationally valid classification for all tradinggoods. The WCO has the entry “1” in the DE3055. However, attributes suchas schemeAgencyID may be optional.

In the example, the characters seven to 11 are used to classify productsnationally or internationally (for example, seeeuropa.eu.int/comm/taxation_customs/dds/en/tarhome.htm or TARIC).

The CustomsCommodityClassificationCode 32200 may be used primarily forclassifying trading goods with tariff code numbers and for implementingregulatory measures.

(nnnnnnnnn) CustomsPreferentialStatementStatusCode

The GDT CustomsPreferentialStatementStatusCode 32300 is a codedrepresentation of the status of a customs preferential statement of avendor. An example (instance) of the GDTCustomsPreferentialStatementStatusCode 32300 is:

<CustomsPreferentialStatementStatusCode>02</CustomsPreferentialStatementStatusCode>.

The GDT CustomsPreferentialStatementStatusCode 32300 is depicted in FIG.323. For the GDT CustomsPreferentialStatementStatusCode 32300, theObject Class term is Customs 32302, the Property term is PreferentialStatement Status 32304, the Representation/Association term is Code32306, the Type term is CCT 32308, the Type Name term is Code 32310, andthe Length is two 32312. The GDT CustomsPreferentialStatementStatusCode32300 may be a restricted GDT 32314.

In a variation, the CustomsPreferentialStatementStatusCode 32300 mayhave the following values: Code Name Description 01 Negative NegativeVendorDeclaration 02 Detailed Detailed Negative VendorDeclarationNegative 03 Positive Positive VendorDeclaration

(ooooooooo) DeliveryTypeCode

The GDT DeliveryTypeCode 32400 is a coded representation of the type ofa delivery. This type describes the (business) nature and basic featuresof the delivery for its logistical processing. An example (instance) ofthe GDT DeliveryType Code 32400 is:

<DeliveryTypeCode>0002</DeliveryTypeCode>.

The GDT DeliveryTypeCode 32400 is depicted in FIG. 324. For the GDTDeliveryTypeCode 32400, the Object Class term is Delivery 32402, theProperty term is Type 32402, the Representation/Association term is Code32406, the Type term is CCT 32408, the Type Name term is Code 32410, andthe Length is four 32412.

In a variation, illustrative values may be as follows: Code NameDescription 0001 Delivery of Delivery of new undamaged products orproducts in new goods their original packaging with the relevantlogistical handling (such as use of special transport packaging,consideration of special picking instructions). 0002 Delivery ofDelivery of new but damaged products or products damaged requiringrepair with the relevant logistical handling goods or (such as use ofspecial transport packaging, new goods consideration of special pickinginstructions). requiring repair 0003 Delivery of Delivery of usedproducts with the relevant used goods logistical handling (such as useof simple transport packaging, no consideration of pickinginstructions). 0004 Delivery of Delivery of products for scrapping withthe relevant scrap logistical handling (such as no use of transportpackaging, no consideration of picking instructions).

The DeliveryTypeCode 32400 describes the features of the delivery thathave an affect on its logistical processing; for example, on the typeand quality of the packaging, the selection of the means of transport,and the handling of the goods in transit. The DeliveryTypeCode 32400 canbe used for the ascertainment of goods for inbound and outbounddeliveries. It can also be used to describe return deliveries.

In a variation, if there is communication with SAP R/3, the attributesof the DeliveryTypeCode 32400 can correspond to the SAP R/3 deliverytypes. The GDT may be defined with four digits in accordance with theLFART (CHAR4) field.

(ppppppppp) DueClearingIndicator

The GDT DueClearingIndicator 32500 indicates whether receivables andpayables are cleared against each other or not. An example (instance) ofthe GDT DueClearingIndicator 32500 is

<DueClearingIndicator>true</DueClearingIndicator>.

The GDT DueClearingIndicator 32500 is depicted in FIG. 325. For the GDTDueClearingIndicator 32500, the Category is element 32502, the ObjectClass term is Due 32504, the Property term is Clearing 32506, theRepresentation/Association term is Indicator 32508, the Type term is CCT32510, and the Type Name term is Indicator 32512.

In a variation, the DueClearingIndicator 32500 can have the followingvalues:

‘true’ Receivables and payables are cleared against each other.

‘false’ Receivables and payables are not cleared against each other.

With the DueClearingIndicator 32500, the tax office can be informed in atax return whether an existing receivable to the tax office is to bereimbursed by it or cleared against existing or future payables.

(qqqqqqqqq) KanbanCardID

The CDT KanbanCardID 32600 is a unique identifier of a kanban card. In avariation, a kanban card is a reusable card with which a production arearequests material “just-in-time” from a supplying location in thecontext of production and material flow control (Kanban is the Japaneseword for “card”). An example (instance) for the CDT KanbanCardID 32600is:

<KanbanCardID schemeAgencyID=“MPL_(—)002”>4711</Kanban CardID>.

In the example, schemeAgencyID=“MPL_(—)002” indicates that the schemewas assigned by the business system “MPL_(—)002”.

The CDT KanbanCardID 32600 is depicted in FIG. 326. The CDT KanbanCardID32600 includes attribute schemeAgencyID 32616. For the CDT KanbanCardID32600, the Object Class term is Kanban Card 32602, the Property term isIdentification 32604, the Representation/Association term is Identifier32606, the Type term is CCT 32608, the Type Name term is Identifier32610, and the Length is from one to ten 32612. The CDT KanbanCardID32600 may be restricted 32614.

For the schemeAgencyID 32616, the Category is attribute 32618, theObject Class term is IdentificationSchemeAgency 32620, theRepresentation/Association term is Identifier 32622, the Type term isxsd 32624, the Type Name term is token 32626, and the Length is from oneto sixty 32628. The cardinality between the schemeAgencyID 32616 and theCDT KanbanCardID 32600 is either zero or one 32630. The schemeAgencyID32616 is optional 32632.

KanbanCardID 32600 is an alphanumeric identifier (with no distinctionbetween uppercase and lowercase) that is compliant with the rules forxsd: token. SchemeAgencyID is the business system in which theidentifier was assigned.

KanbanCardIDs 32600 are used, for example, in purchase orders andforecast delivery schedules that have been generated within the contextof kanban-based replenishment control.

Identifiers such as SchemeID may be included.

(rrrrrrrrr) Log

The CDT Log 32700 is a sequence of messages that result when anapplication executes a task. An example (instance) of the CDT Log 32700is: <Log>  <MaximumLogItemSeverityCode>3</MaximumLogItemSeverityCode> <Item>   <TypeID>001(/CCM/)</TypeID>   <SeverityCode>3</SeverityCode>  <Note>Catalog cameras could not be published</Note>  </Item>  <Item>  <TypeID>002(/CCM/)</TypeID>   <SeverityCode>1</SeverityCode>  <Note>Catalog cell phones successfully published</Note>  </Item></Log>.

The CDT Log 32700 is depicted in FIG. 327. The CDT Log 32700 includeselements MaximumLogItemSeverityCode 32706 and Item 32724. For the CDTLog 32700, the Object Class term is Log 32702 and theRepresentation/Association term is Details 32704.

For the MaximumLogItemSeverityCode 32706, the Category is element 32708,the Object Class term is Log 32710, the Property Qualifier term isMaximum 32712, the Property term is LogItem Severity 32714, theRepresentation/Association term is Code 32716, the Type term is GDT32718, and the Type Name term is LogItemSeverityCode 32720. Thecardinality between the MaximumLogItemSeverityCode 32706 and the CDT Log32700 is either zero or one 32722.

For the Item 32724, the Category is element 32726, the Object Class isLog 32728, the Property term is Item 32730, theRepresentation/Association term is Details 32732, the Type term is GDT32734, and the Type Name term is LogItem 327336. The cardinality betweenthe Item 32724 and CDT Log 32700 is one or more 32738.

MaximumLogItemSeverityCode 32706 is the coded representation of themaximum severity of a log message in a given log. Item 32724 is anindividual log message (see GDT LogItem).

A Log 32700 can be used to transmit log messages with different levelsof severity such as warnings and errors.

(sssssssss) NaturalPersonIndicator

The GDT NaturalPersonIndicator 32800 specifies whether the party is anatural person or not. In a variation, people are natural persons. Anexample (instance) of the GDT NaturalPersonIndicator 32800 is:<NaturalPersonIndicator>true</NaturalPersonIndicator>.

The GDT NaturalPersonIndicator 32800 is depicted in FIG. 328. For theGDT NaturalPersonIndicator 32800, the Property term is Natural Person32802, the Representation/Association term is Indicator 32804, the Typeterm is CCT 32806, and the Type Name term is Indicator 32808.

In a variation, illustrative values of the NaturalPersonIndicator 32800may be:

‘True’ The party is a natural person.

‘False’ The party is not a natural person.

(See the CCT: Indicator for the value range).

The GDT NaturalPersonIndicator 32800 is used to indicate that a party isa natural person or a legal person.

In a variation, the following dictionary objects are assigned to thisGDT in mySAP systems:

Data element: BU_NATURAL_PERSON

Domain: BU_NATURAL_PERSON

(ttttttttt) PackingListID

The GDT PackingListID 32900 is a unique identifier for a packing list.In a variation, a packing list is a list of packing data for theproducts from one or more delivery items. The packing list may containdata for the load carriers used to pack these products (such as cratesor mesh box pallets), as well as for the weight, volume and quantity ofthe packed products. An example (instance) of the GDT PackingListID32900 is:

<PackingListID>XYZ1234AZ5</PackingListID>.

The GDT PackingListID 32900 is depicted in FIG. 329. For the GDTPackingListID 32900, the Object Class term is Packing List 32902, theProperty term is Identification 32904, the Representation/Associationterm is Identifier 32906, the Type term is CCT 32908, the Type Name termis Identifier 32910, and the Length is from one to thirty-five 32912.The GDT PackingListID 32900 may be a restricted GDT 32914.

In a variation, the vendor creates packing lists for the products of oneor more delivery items. These lists accompany the physical shipment butmay not exist as independent documents in the application systems. ThePackingListID 32900 assigned by the vendor can be used to identify thepacking lists that belong to a delivery. In contrast to theHandlingUnit, which has data for packaging materials and a packinghierarchy, a packing list contains simplified, but sufficient, packinginformation for products from a delivery.

(uuuuuuuuu) PartyTaxID

The GDT PartyTaxID 33000 is an identifier for a taxpayer assigned by atax authority. An example (instance) for the GDT PartyTaxID 33000 is:<BuyerParty>   <TaxID schemeID=“DE0”>DE118618422</TaxID> </BuyerParty>.

The GDT PartyTaxID 33000 is depicted in FIG. 330. The GDT PartyTaxID33000 includes attribute schemeID 33018. For the GDT PartyTaxID 33000,the Object Class term is Party 33002, the Property Qualifier term is Tax33004, the Property term is Identification 33006, theRepresentation/Association term is Identifier 33008, the Type term isCCT 33010, the Type Name term is Identifier 33012, and the Length isfrom one to twenty 33014. The GDT PartyTaxID 33000 may be a restrictedGDT 33016.

For the schemeID 33018, the Category is attribute 33020, the ObjectClass term Identification Scheme 33022, the Property term isIdentification 33024, the Representation/Association term is Identifier33026, the Type term is xsd 33028, the Type Name term is token 33030,and the Length is from three to four 33032. The cardinality between theschemeID 33018 and the GDT PartyTaxID 33000 is one.

PartyTaxID 33000 contains a tax number that is up to 20 characters long.The schemeID 33018 attribute specifies what kind of tax number the taxnumber is. The schemeIDs 33018 may be defined in the GDTTaxIdentificationNumberTypeCode, for example, by DE0 for a German VATregistration number.

Tax numbers are used to identify taxpayers. A taxpayer may have morethan one tax number, since there are various types of tax numbers. Incertain countries, for example, the tax number may be provided whenfiling a tax return or remitting taxes, as well as on invoices.

(vvvvvvvvv) PriceSpecificationElement

The GDT PriceSpecificationElement 33100 is the specification of a price,discount or surcharge that depends on a combination of properties, andthat is valid for a specific period of time. An example (instance) ofthe GDT PriceSpecificationElement 33100 for a special product is:

A special price of 29.99 EUR per piece (without scales) is agreed uponfor the product that is represented by the identifier 4711. The priceagreement is valid from Jan. 1, 2004 to Dec. 31, 2006.

(Note: In the example, TypeCode 1010 represents the specification of aspecial price according to GDT: PriceSpecificationElementTypeCode;unitCode C62 is one piece according to UN/ECE Recommendation 20).  <PriceSpecificationElement>   <TypeCode>1010</TypeCode>  <ValidityPeriod>     <StartDate>2004-01-01</StartDate>    <EndDate>2006-12-31</EndDate>   </ValidityPeriod>  <PropertyDefinitionClassID>SALES</PropertyDefinitionClassID>  <Property Valuation>     <PriceSpecificationElementPropertyReference>  <PriceSpecificationElementPropertyID>PRODUCT_ID</PriceSpecificationElementPropertyID>    </PriceSpecificationElementPropertyReference>    <PriceSpecificationElementPropertyValue>       <ID>4711</ID>    </PriceSpecificationElementPropertyValue>   </PropertyValuation>  <Price>     <Amount currencyCode=“EUR”>29.99</Amount>    <BaseQuantity unitCode=“C62”>1</Base Quantity>   </Price>  </PriceSpecificationElement>

An example (instance) of the GDT PriceSpecificationElement 33100 for thespecification of a discount for a product depending on the deliverylocation is as follows:

The product that is represented by the identifier 4711 is granted a 5%discount for deliveries to Paris (represented by the identifier forlocation F75). The discount agreement is valid from Jan. 1, 2004 to Dec.31, 2006.

(Note: In the example, TypeCode 2200 represents the specification of adiscount or surcharge as a result of special properties in the masterdata used according to GDT PriceSpecificationElementTypeCode.)  <PriceSpecificationElement>   <TypeCode>2200</TypeCode>  <ValidityPeriod>     <StartDate>2004-01-01</StartDate>    <EndDate>2006-12-31</EndDate>   </ValidityPeriod>  <PropertyDefinitionClassID>SALES</PropertyDefinitionGlassID>  <PropertyValuation>     <PriceSpecificationElementPropertyReference>  <PriceSpecificationElementPropertyID>PRODUCT_ID</PriceSpecificationElementPropertyID>    </PriceSpecificationElementPropertyReference>    <PriceSpecificationElementPropertyValue>       <ID>4711</ID>    </PriceSpecificationElementPropertyValue>   </PropertyValuation>  <PropertyValuation>     <PriceSpecificationElementPropertyReference>  <PriceSpecificationElementPropertyID>LOCATION_ID</PriceSpecificationElementPropertyID>    </PriceSpecificationElementPropertyReference>    <PriceSpecificationElementPropertyValue>       <ID>F75</ID>    </PriceSpecificationElementPropertyValue>   </PropertyValuation>  <Percent>−5</Percent>   </PriceSpecificationElement>.

The GDT PriceSpecificationElement 33100 is depicted in FIG. 331. The GDTPriceSpecificationElement 33100 includes elements TypeCode 33106,ValidityPeriod 33122, PropertyDefinitionClassID 33138, PropertyValuation33154, Price 33170, Percent 33186, FixedAmount 33102A, and ScaleLine33118A. For the GDT PriceSpecificationElement 33100, the Object Classterm is PriceSpecificationElement 33102 and theRepresentation/Association term is Details 33104.

For the TypeCode 33106, the Category is element 33108, the Object Classterm is PriceSpecificationElement 33110, the Property term is Type33112, the Representation/Association term is Code 33114, the Type termis GDT 33116, and the Type Name term isPriceSpecificationElementTypeCode 33118. The cardinality between theTypeCode 33106 and the GDT PriceSpecificationElement 33100 is one.

For the ValidityPeriod 33122, the Category is element 33124, the ObjectClass term is PriceSpecificationElement 33126, the Property term isValidity Period 33128, the Representation/Association term is Period33130, the Type term is GDT 33132, and the Type Name term isDateTimePeriod 33134. The cardinality between the ValidityPeriod 33122and the GDT PriceSpecificationElement 33100 is one.

For the PropertyDefinitionClassID 33138, the Category is element 33140,the Object Class term is PriceSpecificationElement 33142, the Propertyterm is PropertyDefinitionClassIdentification 33144, theRepresentation/Association term is Identifier 33146, the Type term isGDT 33148, and the Type Name term isPriceSpecificationElementPropertyDefinitionClassID 33150. Thecardinality between the PropertyDefinitionClassID 33138 and the GDTPriceSpecificationElement 33100 is either zero or one.

For the PropertyValuation 33154, the Category is element 33156, theObject Class term is PriceSpecificationElement 33158, the Property termis PropertyValuation 33160, the Representation/Association term isPriceSpecificationElementPropertyValuation 33162, the Type term is GDT33164, and the Type Name term isPriceSpecificationElementPropertyValuation 33166. The cardinalitybetween the PropertyValuation 33154 and the GDTPriceSpecificationElement 33100 is one or more.

For the Price 33170, the Category is element 33172, the Object Classterm is Value 33174, the Property term is Price 33176, theRepresentation/Association term is Price 33178, the Type term is GDT33180, and the Type Name term is Price 33182. The cardinality betweenthe Price 33170 and the GDT PriceSpecificationElement 33100 is eitherzero or one.

For the Percent 33186, the Category is element 33188, the Object Classterm is Value 33190, the Property term is Percent 33192, theRepresentation/Association term is Percent 33194, the Type term is GDT33196, the Type Name term is Percent 33198. The cardinality between thePercent 33186 and the GDT PriceSpecificationElement 33100 is either zeroor one.

For the FixedAmount 33102A, the Category is element 33104A, the ObjectClass term is Value 33106A, the Property term is Fixed amount 33108A,the Representation/Association term is Amount 33111A, the Type term isGDT 33112A, and the Type Name term is Amount 33114A. The cardinalitybetween the FixedAmount 33102A and the GDT PriceSpecificationElement33100 is either zero or one.

For the ScaleLine 33118A, the Category is element 33120A, the ObjectClass term is PriceSpecificationElement 33122A, the Property term isScaleLine 33124A, the Representation/Association term isPriceSpecificationElemetnScaleLine 33126A, the Type term is GDT 33128A,and the Type Name term is PriceSpecificationElementScaleLine 33130A. Thecardinality between the ScaleLine 33118A and the GDTPriceSpecificationElement 33100 is either zero or unbounded.

PriceSpecificationElement 33100 has the following elements:

TypeCode—Coded representation of the type of specification of the price,discount or surcharge.

ValidityPeriod—Validity period for the specification of the price,discount or surcharge.

PropertyDefinitionClassID—Identifier of the property definition classfor which several properties are defined. It identifies the businessarea according to the functional unit in an enterprise, in which thespecification of the price, discount or surcharge is used, and which isresponsible for the respective activities (regardless of the underlyingorganizational structure). In a variation, permitted properties in theGDT: PriceSpecificationElement include: PURCHASE Purchasing SALES Salesand Distribution (Sales/Service).

PropertyValuation—Property valuation on whose combination the agreementof price, discount or surcharge depends. Permitted properties may bespecified via the respective property definition class. The propertyvaluation can identify or characterize the specification of the price,discount or surcharge. The combination of identifying propertyvaluations may be unique for the specification of the price, discount orsurcharge together with the type of specification and the end of thevalidity period.

Price—Specification of a price (without scales).

Percent—Specification of percent for discount or surcharge (withoutscales).

FixedAmount—Fixed amount for discounts or surcharges (without scales).

ScaleLine—Scale line for the specification of price, discount orsurcharge.

The specification of a property definition class in thePropertyDefinitionClassID element may be optional, if the business areafor specifying the price, discount or surcharge, or the respectiveproperty definition class from the application that uses the GDT:PriceSpecificationElement is known. A property definition class in thePropertyDefinitionClassID element may have higher priority than thatwhich is known from the business area of the application.

The element PropertyValuation may contain value assignments forproperties for which a property reference is defined using the propertydefinition class that is known. In a variation, each of these propertyreferences are not be contained in more than one PropertyValuationelement. At least one PropertyValuation element may be identifying, thatis, with a value of “1” forPriceSpecificationElement/PropertyValuation/TypeIndicator.

In a variation, either at least one Price, Percent or FixedAmountelement is specified, or at least one or more ScaleLine elements exists.If one of the Price, Percent or FixedAmount elements is specified, aScaleLine element may not exist. If at least one ScaleLine element isspecified, none of the Price, Percent or FixedAmount elements may exist.The same type for the scale ratePriceSpecificationElement/ScaleLine/Price,PriceSpecificationElement/Scale-Line/Percent orPriceSpecificationElement/ScaleLine/FixedAmount may be specified in theScaleLine elements. Further, the number ofPriceSpecificationElement/ScaleLine/AxisStep elements may correspond inthe ScaleLine elements.PriceSpecificationElement/ScaleLine/AxisStep/IntervalBoundaryTypeCodemay be the same in the ScaleLine elements forPriceSpecificationElement/ScaleLine/AxisStep with the samePriceSpecificationElement/ScaleLine/AxisStep/ScaleAxisBaseCode.

(wwwwwwwww) PriceSpecificationElementPropertyDefinitionClassID

The GDT PriceSpecificationElementPropertyDefinitionClassID 33200 is aunique identifier for a property definition class for specifying aprice, discount or surcharge. The GDTPriceSpecificationElementPropertyDefinitionClass 33200 classifies aclass for defining properties for which the specification of a price,discount, or surcharge is possible. It defines the business environmentaccording to the functional unit in an organization in which thespecification of a price, discount, or surcharge is used, and which,(regardless of the underlying organizational structure), is responsiblefor the respective activities. The properties defined in GDTPriceSpecificationElementPropertyDefinitionClass 33200 represent thecharacteristics of this business environment for the specification of aprice, discount, or surcharge. An example (instance) is as follows:</PriceSpecificationElementPropertyDefinitionClassID>   SALES</PriceSpecificationElementPropertyDefinitionClassID>.

The GDT PriceSpecificationElementPropertyDefinitionClassID 33200 isdepicted in FIG. 332. For the GDTPriceSpecificationElementPropertyDefinitionClassID 33200, the ObjectClass term is PriceSpecificationElementPropertyDefinitionClass 33202,the Property term is Identification 33204, theRepresentation/Association term is Identifier 33206, the Type term isCCT 33208, the Type Name term is Identifier 33210, and the Length isfrom one to fifty 33212. The GDTPriceSpecificationElementPropertyDefinitionClassID may be a restrictedGDT 33214.

For a description of ranges, see CCT Identifier above. In a variation,permitted values for GDTPriceSpecificationElementPropertyDefinitionClassID include: PURCHASEPurchasing SALES Sales and Distribution (Sales/Service).

(xxxxxxxxx) PricingPriceSpecificationElementPropertyID

The GDT PricingPriceSpecificationElementPropertyID 33300 is a uniqueidentifier of a property for the specification of a price, discount orsurcharge. Properties are determining elements on whose combination theagreement of a price, discount or surcharge is dependent. An example(instance) of the GDT PricingPriceSpecificationElementPropertyID 33300is: <PriceSpecificationElementPropertyID>   PRODUCT_ID</PriceSpecificationElementPropertyID>.

The GDT PricingPriceSpecificationElementPropertyID 33300 is depicted inFIG. 333. For the GDT PricingPriceSpecificationElementPropertyID 33300,the Object Class term is PriceSpecificationElementProperty 33302, theProperty term is Identification 33304, the Representation/Associationterm is Identifier 33306, the Type term is CCT 33308, the Type Name termis Identifier 33310, and the Length is from one to thirty 33312. The GDTPricingPriceSpecificationElementPropertyID 33300 may be a restricted GDT33314.

For illustrative values, see CCT Identifier above. The property that isdescribed by the identifier may be unique within thePriceSpecificationElementPropertyDefinitionClass property definitionclass. The property can be assigned to several property definitionclasses.

(yyyyyyyyy) PriceSpecificationElementPropertyReference

The GDT PriceSpecificationElementPropertyReference 33400 is the uniquereference of a property for the specification of a price, discount orsurcharge within a property definition class. An example (instance) ofthe GDT PriceSpecificationElementPropertyReference 33400 is:<PriceSpecificationElementPropertyReference>  <PriceSpecificationElementPropertyID>     PRODUCT_ID  </PriceSpecificationElementPropertyID>  <PriceSpecificationElementPropertyDefinitionClassID>     SALES  </PriceSpecificationElementPropertyDefinitionClassID></PriceSpecificationElementPropertyReference>.

The GDT PriceSpecificationElementPropertyReference 33400 is depicted inFIG. 334. The GDT PriceSpecificationElementPropertyReference 33400includes elements PriceSpecificationElementPropertyID 33406 andPriceSpecificationElementPropertyDefinitionClassID 33422. For the GDTPriceSpecificationElementPropertyReference 33400, the Object Class termis PriceSpecificationElementPropertyReference 33402 and theRepresentation/Association term is Details 33404.

For the PriceSpecificationElementPropertyID 33406, the Category iselement 33408, the Object Class term isPriceSpecificationElementPropertyReference 33410, the Property term isPriceSpecificationElementPropertyIdentification 33412, theRepresentation/Association term is Identifier 33414, the Type term isGDT 33416, and the Type Name term is PriceSpecificationElementPropertyID33418. The cardinality between the PriceSpecificationElementPropertyID33406 and the GDT PriceSpecificationElementPropertyReference 33400 isone.

For the PriceSpecificationElementPropertyDefinitionClassID 33422, theCategory is element 33424, the Object Class term isPriceSpecificationElementPropertyReference 33426, the Property term isPriceSpecificationElementPropertyDefinitionClassIdentification 33428,the Representation/Association term is Identifier 33430, the Type termis GDT 33432, and the PriceSpecificationElementPropertyDefinitionClassID33434. The cardinality between thePriceSpecificationElementPropertyDefinitionClassID 33422 and the GDTPriceSpecificationElementPropertyReference 33400 is either zero or one.

PriceSpecificationElementPropertyID is an identifier of a property forthe specification of a price, discount or surcharge.PriceSpecificationElementPropertyDefinitionClassID is an identifier of aproperty definition class for the specification of a price, discount orsurcharge. The referenced property is defined for a property definitionclass. Specification of thePriceSpecificationElementPropertyDefinitionClassID element may beoptional, if the property definition class is known uniquely in therespective context.

(zzzzzzzzz) PriceSpecificationElementPropertyValuation

The GDT PriceSpecificationElementPropertyValuation 33500 is theassignment of a value to a property for the specification of a price,discount or surcharge. A property valuation may be carried out whenspecifying a price, discount or surcharge to determine thespecification. The property valuation can identify or characterize thespecification. The combination of properties with an identifyingproperty valuation is unique together with the validity period and thetype of specification. Examples of the GDTPriceSpecificationElementPropertyValuation 33500 are:<PriceSpecificationElementPropertyValuation>  <PriceSpecificationElementPropertyReference>    <PriceSpecificationElementPropertyID>       PRODUCT_ID    </PriceSpecificationElementPropertyID>    <PriceSpecificationElementPropertyDefinitionClassID>       SALES    </PriceSpecificationElementPropertyDefinitionClassID>  </PriceSpecificationElementPropertyReference>  <PriceSpecificationElementPropertyValue>     <IDschemeID=”Kuhlschranke”>4711</ID>  <PriceSpecificationElementPropertyValue></PriceSpecificationElementPropertyValuation>.

The GDT PriceSpecificationElementPropertyValuation 33500 is depicted inFIG. 335. The GDT PriceSpecificationElementPropertyValuation 33500includes elements TypeIndicator 33506,PriceSpecificationElementPropertyReference 33522, andPriceSpecificationElementPropertyValue 33538. For the GDTPriceSpecificationElementPropertyValuation 33500, the Object Class termis PriceSpecificationElementPropertyValuation 33502 and theRepresentation/Association term is Details 33504.

For the TypeIndicator 33506, the Category is element 33508, the ObjectClass term is PriceSpecificationElementPropertyValuation 33510, theProperty term is IType 33512, the Representation/Association term isIndicator 33514, the Type term is GDT 33516, and the Type Name term isIndicator 33518. The cardinality between the TypeIndicator 33506 and theGDT PriceSpecificationElementPropertyValuation 33500 is either zero orone.

For the PriceSpecificationElementPropertyReference 33522, the Categoryis element 33524, the Object Class term isPriceSpecificationElementPropertyValuation 33526, the Property term isPriceSpecificationElementProperty Reference 33528, theRepresentation/Association term isPriceSpecificationElementPropertyReference 33530, the Type term is GDT33532, and the Type Name term isPriceSpecificationElementPropertyReference 33534. The cardinalitybetween the PriceSpecificationElementPropertyReference 33522 and the GDTPriceSpecificationElementPropertyValuation 33500 is one 33536.

For the PriceSpecificationElementPropertyValue 33538, the Category iselement 33540, the Object Class term isPriceSpecificationElementPropertyValuation 33542, the Property term isPriceSpecificationElementPropertyValue 33544, theRepresentation/Association term isPriceSpecificationElementPropertyValue 33546, the Type term is GDT33548, and the Type Name term is PriceSpecificationElementPropertyValue33550. The cardinality between the PriceSpecificationElemenPropertyValue33538 and the GDT PriceSpecificationElementPropertyValuation 33500 isone 33552.

TypeIndicator is an indicator that specifies if the respective propertyvaluation identifies or characterizes the specification of the price,discount or surcharge. In a variation, the values include: 1 identifyingproperty valuation 0 characterizing property valuation

In a variation, the default value is “1”, if the element is not used.

PriceSpecificationElementPropertyReference is a reference to theunderlying property for which the property valuation should berepresented.

PriceSpecificationElementPropertyValue is the value of the referencedproperty.

(aaaaaaaaaa) PriceSpecificationElementPropertyValue

The GDT PriceSpecificationElementPropertyValue 33600 is a value that isassigned to a property for the specification of a price, discount orsurcharge. An example (instance) for the GDTPriceSpecificationElementPropertyValue 33600 is:<PriceSpecificationElementPropertyValue>   <IntegerValue>     1  </IntegerValue> </PriceSpecificationElementPropertyValue>.

The GDT PriceSpecificationElementPropertyValue 33600 is depicted in FIG.336. The GDT PriceSpecificationElementPropertyValue 33600 includeselements Code 33608, ID 33626, IntegerValue 33644, Date 33662, Time33678, and Indicator 33694. For the GDTPriceSpecificationElementPropertyValue33600, the Category is element33602, the Object Class term is PriceSpecificationElementPropertyValue33604, and the Representation/Association term is Details 33606.

For the Code 33608, the Category is element 33610, the Object Class termis PriceSpecificationElementPropertyValue 33612, the Property term isCode 33614, the Representation/Association term is Code 33616, the Typeterm is CCT 33618, the Type Name term is Code 33620, and the Length isfrom one to fifty 33622. The cardinality between the Code 33608 and theGDT PriceSpecificationElementPropertyValue 33600 is either zero or one33624.

For the ID 33626, the Category is element 33628, the Object Class termis PriceSpecificationElementPropertyValue 33630, the Property term isIdentification 33632, the Representation/Association term is Identifier33634, the Type term is CCT 33636, the Type Name term is Identifier33638, and the Length is from one to fifty 33640. The cardinalitybetween the ID 33626 and the GDT PriceSpecificationElementPropertyValue33600 is either zero or one 33642.

For the IntegerValue 33644, the Category is element 33646, the ObjectClass term is PriceSpecificationElementPropertyValue 33648, the Propertyterm is Integer Value 33650, the Representation/Association Qualifierterm is Integer 33652, the Representation/Association term is Value33654, the Type term is GDT 33656, and the Type Name term isIntegerValue 33658. The cardinality between the IntegerValue 33644 andthe GDT PriceSpecificationElementPropertyValue 33600 is either zero orone 33660.

For the Date 33662, the Category is element 33664, the Object Class termis PriceSpecificationElementPropertyValue 33666, the Property term isDate 33668, the Representation/Association term is Date 33670, the Typeterm is GDT 33672, and the TypeName term is Date 33674. The cardinalitybetween the Date 33662 and the GDTPriceSpecificationElementPropertyValue 33600 is either zero or one33676.

For the Time 33678, the Category is element 33680, the Object Class termis PriceSpecificationElementPropertyValue 33682, the Property term isTime 33684, the Representation/Association term is Time 33686, the Typeterm is GDT 33688, and the Type Name term is Time 33690. The cardinalitybetween the Time 33678 and the GDTPriceSpecificationElementPropertyValue 33600 is either zero or one33692.

For the Indicator 33694, the Category is element 33696, the Object Classterm is PriceSpecificationElementPropertyValue 33698, the Property termis Indicator 33600A, the Representation/Association term is Indicator33602A, the Type term is GDT 33604A, and the Type Name term is Indicator33606A. The cardinality between the Indicator 33694 and the GDTPriceSpecificationElementPropertyValue 33600 is either zero or one33608A.

The structure of the GDT PriceSpecificationElementPropertyValue 33600represents meta-information for property values. Hence the elements ofGDT PriceSpecificationElementPropertyValue represent types of actualvalues:

Code—Specification of the coded representation of information.

ID—Specification of the identification of an object.

IntegerValue—Specification of a discrete, integer value.

Date—Specification of a calendar day.

Time—Specification of a point in time to the nearest second (time).

Indicator—Specification of a binary logical value.

In a variation, one element from the quantity Code, ID, IntegerValue,Date, Time or Indicator may be specified. The element that isappropriate for the type of the actual value is used.

The following is an example of the use of Code:

Example: Specification of a color code, for example red metallic vehiclepaint (code 0042) (Colors can be used as properties withinspecifications for prices, discounts or surcharges: 1000 EUR surchargefor red metallic vehicle paint (code 0042).)

The following is an example of the use of ID:

Specification of an identifier for the location, for example location ofa branch office in Hamburg (ID 4711) or Paris (ID 4712) (Identifiers forthe location can be used as properties within specifications for prices,discounts or surcharges: 5% discount for deliveries to the branch officein Hamburg (ID 4711), 100 EUR surcharge for deliveries to the branchoffice in Paris (ID 4712).)

The following is an example of the use of IntegerValue:

Valuation of non-dimensional, integer properties, such as codes,indexes, consecutive numbers.

The following is an example of the use of Date:

Expiry date, sell-by date, date of manufacturing, filling or packaging,date of release, locking, order or delivery, and so on.

The following is an example of the use of Time:

Timestamp for specification to the nearest second of when a product isfilled, produced, or certified, and so on.

The following is an example of the use of Indicator:

Properties with only two statuses: yes/no, on/off, and so on.

(bbbbbbbbbb) PriceSpecificationElementScaleLine

The GDT PriceSpecificationElementScaleLine 33700 is a scale line for thespecification of a price, discount or surcharge. A single or twodimensional scale can be used when specifying a price, discount orsurcharge. The scale comprises scale lines that define a price, discountor surcharge for each scale step. An example (instance) of the GDTPriceSpecificationElementScaleLine 33700 for the scale line for thespecification of a price is as follows:

The scale is a one-dimensional ‘from’ price scale. The price is 29.99EUR per piece from 10 pieces.

(Note: ScaleAxisBaseCode 1 represents a quantity according to GDT:ScaleAxisBaseCode;

IntervalBoundaryTypeCode 1 represents a ‘from’ price scale according toGDT: ScaleAxisStepIntervalBoundaryTypeCode;

unitCode C62 is one piece according to UN/ECE Recommendation 20.)<PriceSpecificationElementScaleLine> <ScaleAxisStep>  <ScaleAxisBaseCode>1</ScaleAxisBaseCode>  <IntervalBoundaryTypeCode>1</IntervalBoundaryTypeCode>   <QuantityunitCode=“C62”>10</Quantity> </ScaleAxisStep> <Price>   <AmountcurrencyCode=“EUR”>29.99</Amount>   <BaseQuantityunitCode=“C62”>1</BaseQuantity> </Price></PriceSpecificationElementScaleLine>.

The GDT PriceSpecificationElementScaleLine 33700 is depicted in FIG.337. The GDT PriceSpecificationElementScaleLine 33700 includes elementsScaleAxisStep 33706, Price 33722, Percent 33738, and FixedAmount 33754.For the GDT PriceSpecificationElementScaleLine 33700, the Object Classterm is PriceSpecificationElementScaleLine 33702 and theRepresentation/Association term is Details 33704.

For the ScaleAxisStep 33706, the Category is element 33708, the ObjectClass term is PriceSpecificationElementScaleLine 33710, the Propertyterm is ScaleAxisStep 33712, the Representation/Association term isScaleAxisStep 33714, the Type term is GDT 33716, and the Type Name termis ScaleAxisStep 33718. The cardinality between the ScaleAxisStep 33706and the GDT PriceSpecificationElementScaleLine 33700 is either one ortwo 33720.

For the Price 33722, the Category is element 33724, the Object Classterm is PriceSpecificationElementScaleLine 33726, the Property term isPrice 33728, the Representation/Association term is Price 33730, theType term is GDT 33732, and the Type Name term is Price 33734. Thecardinality between the Price 33722 and the GDTPriceSpecificationElementScaleLine 33700 is either zero or one 33736.

For the Percent 33738, the Category is element 33740, the Object Classterm is PriceSpecificationElementScaleLine 33742, the Property term isPercent 33744, the Representation/Association term is Percent 33746, theType term is GDT 33748, and the Type Name term is Percent 33750. Thecardinality between the Percent 33738 and the GDTPriceSpecificationElementScaleLine 33700 is either zero or one 33752.

For the FixedAmount 33754, the Category is element 33756, the ObjectClass term is PriceSpecificationElementScaleLine 33758, the Propertyterm is FixedAmount 33760, the Representation/Association term is Amount33762, the Type term is GDT 33764, and the Type Name term is Amount33766. The cardinality between the FixedAmount 33754 and the GDTPriceSpecificationElementScaleLine 33700 is either zero or one 33768.

GDT PriceSpecificationElementScaleLine 33700 has the following elements:

ScaleAxisStep—Axis Step (scale dimension value) of a dimension of thescale step for which the scale line is defined for the specification ofa price, discount or surcharge.

Price—Scale rate as specification of a price.

Percent—Scale rate for specifying the percent for discounts orsurcharges.

FixedAmount—Scale rate for specifying a fixed amount for discounts orsurcharges.

In a variation, the samePriceSpecificationElementScaleLine/ScaleAxis-Step/ScaleAxisBaseCode isnot be specified for differentPriceSpecificationElementScaleLine/AxisStep elements. One of the Price,Percent or FixedAmount elements may exist. If an element that isclassified by the GDT PriceSpecificationElementScaleLine hascardinality >1, the same type may be specified in all instances for thescale rate Price, Percent or FixedAmount. If an element that isclassified by the GDT PriceSpecificationElementScaleLine hascardinality >1, the PriceSpecificationElementScaleLine/ScaleAxisStepelements may be specified in all instances with the same number of andthe same characteristics forPriceSpecificationElementScaleLine/ScaleAxis-Step/ScaleAxisBaseCode.

For additional usage information for PriceSpecificationElementScaleLine33700 see GDT PriceSpecificationElement above.

(cccccccccc) PriceSpecificationElementTypeCode

The GDT PriceSpecificationElementTypeCode 33800 is the codedrepresentation of the type of specification of a price, discount orsurcharge. An example (instance) of the GDTPriceSpecificationElementTypeCode 33800 is:

Specifies a special % or absolute discount based on the 50^(th)anniversary of a company: <PriceSpecificationElementTypeCode>   2310</PriceSpecificationElementTypeCode>.

The GDT PriceSpecificationElementTypeCode 33800 is depicted in FIG. 338.For the GDT PriceSpecificationElementTypeCode 33800, the Object Classterm is PriceSpecificationElement 33802, the Property term is Type33804, the Representation/Association term is Code 33806, the Type termis CCT 33808, the Type Name term is Code 33810, and the Length is four33812. The GDT PriceSpecificationElementTypeCode 33800 may be arestricted GDT 33814.

In a variation, illustrative possible properties of the GDTPriceSpecificationElementTypeCode are as shown in the following table:Code Name Description 1000 Price Specifies a price (not specifiedfurther) 1010 Special Price Specifies a special price (not specifiedfurther) E.g.: Price entered manually 1100 Basic Price Specifies a basicprice (not specified further) E.g.: Catalog price, price from a pricelist, price per quantity 1110 Recommended Specifies a price based on arecommended price Price E.g.: Recommended retail price 1120 PriceSpecifies a price based on a price requirement Requirement E.g.: Costprice 1200 Price Property Specifies a price based on special propertiesof the master data used (not specified further) 1210 Partner GroupSpecifies a price based on group membership of the business Pricepartner. E.g.: Price for a major customer, price for a vendor orcustomer group 1220 Product Group Specifies a price based on groupmembership of the product Price E.g.: OEM price, special price for aproduct or price group 1230 Product Specifies a price based on aspecific product configuration Configuration E.g.: Special price formetallic paint, for size “XL”, or a Price special edition 1300 PromotionPrice Specifies a price based on a promotion (not specified further)1310 Event Price Specifies a price based on a one-time sales event thatis restricted to a certain time period E.g.: Branch opening price,anniversary price 1320 Periodic Specifies a price based on a recurringpromotion that is Promotion Price restricted to a certain time periodE.g.: Christmas price, Easter sales promotion, summer sale 1400 BusinessProcess Specifies a price based on business processes that deviate fromPrice the business standard (not specified further) 1410 Value LimitSpecifies a price for a quantity of a product or the total Pricedocument as a result of exceeding or falling short of a value limitE.g.: Reserve price, minimum sales order value 1420 Quantity LimitSpecifies a price for the quantity of a product or the total Pricedocument as a result of exceeding or falling short of a quantity limitE.g.: Pallet price 1430 Agreement Price Specifies a price for thequantity of a product or the total document as a result of a bindingagreement, for example when ordering or when signing a contract E.g.:Contract price 2000 Discount/ Specifies a discount or surcharge (notspecified further) Surcharge 2010 Special Specifies a special discountor surcharge (not specified Discount/ further) Surcharge E.g.: Discountentered manually 2100 Base Value Specifies a base value discount orsurcharge (not specified Discount/ further) Surcharge E.g.: Absolutediscount, discount from a price list 2200 Property Specifies a discountor surcharge based on special properties Discount/ of the master dataused (not specified further) Surcharge 2210 Partner Group Specifies adiscount or surcharge based on the group Discount/ membership of thebusiness partner Surcharge E.g.: Major customer discount, specialdiscount for a vendor or customer group 2220 Product Group Specifies adiscount or surcharge based on the group Discount/ membership of theproduct Surcharge E.g.: OEM surcharge for a product, special discountfor a product or price group 2230 Product Specifies a discount orsurcharge based on product Configuration configuration Discount/ E.g.:Surcharge for metallic paint, surcharge for size “XL”, Surchargediscount for a special edition 2300 Promotion Specifies a discount orsurcharge based on a promotion (not Discount/ specified further)Surcharge 2310 Event Specifies a discount or surcharge based on aone-time sales Discount/ event that is restricted to a certain timeperiod. E.g.: Branch Surcharge opening discount, anniversary discount2320 Periodic Specifies a discount or surcharge based on a recurringPromotion promotion that is restricted to a certain time periodDiscount/ E.g.: Christmas discount, Easter promotion, anniversarySurcharge discount 2340 Coupon Specifies a discount or surcharge basedon a coupon or Discount/ voucher Surcharge E.g.: Coupon that is validfor manufacturer sales promotion 2400 Business Process Specifies adiscount or surcharge based on business processes Discount/ that deviatefrom the business standard (not specified further) Surcharge 2410 ValueLimit Specifies a discount or surcharge for the quantity of a productDiscount/ or the total document as a result of exceeding or fallingshort Surcharge of the value limit E.g.: Minimum sales order valuesurcharge 2420 Quantity Limit Specifies a price for a quantity of aproduct or the total Discount/ document as a result of exceeding orfalling short of the Surcharge quantity limit E.g.: Pallet discount,surcharge for incomplete pallet 2430 Agreement Specifies a discount orsurcharge for the quantity of a product Discount/ or the total documentas a result of a binding agreement, for Surcharge example when orderingor when signing a contract E.g.: Contract discount 2500 CalculativeSpecifies a discount or surcharge based on special calculativeProcessing processing (not specified further) Discount/ Surcharge 2510Free Goods Specifies a discount based on free goods E.g.: 100% discount2520 Rounding Specifies a discount or surcharge based on the clearing ofDifference rounding differences 4000 Transport Costs Specifies transportcosts (not specified further) 4100 Packaging Specifies packaging (notfurther specified) 4200 Freight Specifies freight (not furtherspecified) 5100 Customs Duty Specifies customs duty (not furtherspecified) 6000 Terms of Specifies special terms of payment (notspecified further) Payment 6100 Cash Discount Cash Discount (notspecified further)

The semantics for grouping code list entries are not fixed.

In a variation, the GDT PriceSpecificationElementTypeCode 33800 may be aproprietary code list with fixed predefined values. In that case,changes to the permitted values may involve changes to the interface.

In a variation, related standardized code list, such as Price.Type.Code(UN/CEFACT 5375), or Price.Specification.Code (UN/CEFACT 5387) are notused, as their semantics may differ. In the first case, categorizationaccording to particular specifications takes on importance for thequality of products, while in the second case, it is the businesscircumstances leading to the determination of prices that are important.

(dddddddddd) ProductAttributeGroupID

The GDT ProductAttributeGroupID 33900 is a unique identifier for aproduct attribute group. In a variation, a product attribute group mayarrange product attributes together in a group to describe thecharacteristics of a product and enables attributes that are associatedwith each other to be maintained together. See for example, SapTerm: SetType at help.sap.com/saphelp_crm40srl/helpdata/de/35/2cd77bd7705394e10000009b387c12/frameset.htm.

An example (instance) of the GDT ProductAttributeGroupID 33900 is:

<ProductAttributeGroupID>SERVICEPLAN</ProductAttributeGroupID>.

The GDT ProductAttributeGroupID 33900 is depicted in FIG. 339. For theGDT ProductAttributeGroupID 33900, the Object Class term is ProductAttributeGroup 33902, the Property term is Identification 33904, theRepresentation/Association term is Identifier 33906, the Type term isCCT 33908, the Type Name term is Identifier 33910, and the Length isfrom one to sixteen 33912. The GDT ProductAttributeGroupID may be arestricted GDT 33914.

For GDT ProductAttributeGroupID 33900, alphanumeric character stringsmay be used. The GDT ProductAttributeGroupID 33900 may be used inbusiness objects and their replication messages. Attributes stored in aproduct attribute group can be assigned to several products and cantherefore be re-used. Product attributes may be grouped according tosubjective business criteria. In an example, a product attribute groupis for administrative attributes such as Date and Created by. In anotherexample, a product attribute group is for units of measure and theirconversion factors to the base unit of measure.

In a variation, in SAP product master, the ProductAttributeGroupID isrepresented by the data element COMT_FRGTYPE_ID.

(eeeeeeeeee) PromotionInternalID

The GDT PromotionInternalID 34000 is a proprietary identifier for apromotion. In a variation, a promotion may be a marketing activitybetween the consumer goods industry and retail for a limited time periodto increase brand equity, product awareness, and market share, to boostsales volumes, or to position new products or product groups. Examplesof the GDT PromotionInternalID 34000 are:

<PromotionInternalIDschemeAgencyID=“MPL_(—)002”>1C743CEC501F6A4D</PromotionInternalID>

schemeAgencyID=“MPL_(—)002” indicates that the scheme was assigned bythe business system “MPL_(—)002”.

The GDT PromotionInternalID 34000 is depicted in FIG. 340. The GDTPromotionInternalID 34000 includes attribute schemeAgencyID 34018. Forthe GDT PromotionInternalID 34000, the Object Class term is Promotion34002, the Property Qualifier term is Internal 34004, the Property termis Identification 34006, the Representation/Association term isIdentifier 34008, the Type term is GDT 34010, the Type Name term isPromotionID 34012, and the Length is from one to thirty-five 34014. TheGDT PromotionInternalID may be a restricted GDT 34016.

For the schemeAgencyID 34018, the Category is attribute 34020, theObject Class term is IdentificationSchemeAgency 34022, the Property termis Identification 34024, the Representation/Association term isIdentifier 34026, the Type term is xsd 34028, the Type Name term isToken 34030, and the Length is from one to sixty 34032. The cardinalitybetween the schemeAgencyID 34018 and the GDT PromotionInternalID 34000is either zero or one 34034.

The schemeAgencyID 34018 attribute identifies the business system inwhich the identifier was assigned. The GDT PromotionInternalID 34000 isa projection of the GDT PromotionID that contains the schemeAgencyIDattribute for describing an internally assigned ID. If an attribute isnot specified explicitly in the use of the GDT, it may be specifiedthrough the context.

The PromotionInternalID 34000 may be used when both sender and recipienthave access to shared master data; for example, during internalcommunication in an enterprise.

(ffffffffff) PromotionPartyID

The GDT PromotionPartyID 34100 is an identifier for a promotion assignedby a party. In a variation, a promotion may be a marketing activitybetween the consumer goods industry and retail for a limited time periodto increase brand equity, product awareness, and market share, to boostsales volumes, or to position new products or product groups. An example(instance) of the GDT PromotionPartyID 34100 is:

<PromotionVendorID>B232-6HS</PromotionVendorID>.

The GDT PromotionPartyID 34100 is depicted in FIG. 341. For the GDTPromotionPartyID 34100, the Object Class term is Promotion 34102, theProperty Qualifier term is Party 34104, the Property term isIdentification 34106, the Representation/Association term is Identifier34108, the Type term is GDT 34110, the Type Name term is PromotionID34112, and the Length is from one to thirty-five 34114. The GDTPromotionPartyID 34100 may be a restricted GDT 34116.

The PromotionPartyID may be a proprietary identifier. In the context ofa message, the expression “Party” in PromotionPartyID may be replaced bythe role of the party assigning the identifier; for example,PromotionSellerID if the identifier for the promotion is assigned by theSellerParty. When there is a need to distinguish between severalschemes, schemeID and schemeVersionID may be included as attributes.

(gggggggggg) ReceivedQuantityAccumulation

The GDT ReceivedQuantityAccumulation 34200 are values for cumulatedreceived quantities. An example (instance) of the GDTReceivedQuantityAccumulation 34200 is:  <ReceivedQuantityAccumulation>  <ReferencePeriod>   <StartDateTime>2004-01-01T00:00:00Z</StartDateTime>   <EndDateTime>2004-12-31T23:59:59Z </EndDateTime>   </ReferencePeriod>  <Quantity unitCode=”CT”>10000</Quantity>  <ReconciliationDateTime>2005-01-01T00:00:00Z</ ReconciliationDateTime>  <ReconciliationQuantity unitCode=”CT”>0</ReconciliationQuantity> </ReceivedQuantityAccumulation>.

The GDT ReceivedQuantityAccumulation 34200 is depicted in FIG. 342. TheGDT ReceivedQuantityAccumulation 34200 includes elements ReferencePeriod34208, Quantity 34224, ReconciliationDateTime 34242, andReconciliationQuantity 34258. For the GDT ReceivedQuantityAccumulation34200, the Object Class term is Received Quantity Accumulation 34202,the Property term is Details 34204, and the Representation/Associationterm is Details 34206.

For the ReferencePeriod 34208, the Category is Element 34210, the ObjectClass term is Received Quantity Accumulation 34212, the Property term isReferencePeriod 34214, the Representation/Association term is Details34216, the Type term is GDT 34218, and the Type Name term isDateTimePeriod 34220. The cardinality between the ReferencePeriod 34208and the GDT ReceivedQuantityAccumulation 34200 is either zero or one34222.

For the Quantity 34224, the Category is Element 34226, the Object Classterm is Received Quantity Accumulation 34228, the Property term isQuantity 34230, the Representation/Association term is Quantity 34232,the Type term is GDT 34234, the Type Name term is Quantity 34236, andthe Length is thirteen digits with six post decimal digits 34238. Thecardinality between the Quantity 34224 and the GDTReceivedQuantityAccumulation 34200 is one 34240.

For the ReconciliationDateTime 34242, the Category is Element 34244, theObject Class term is Received Quantity Accumulation 34246, the Propertyterm is Reconciliation 34248, the Representation/Association term isDateTime 34250, the Type term is GDT 34252, and the Type Name term isDateTime 34254. The cardinality between the ReconciliationDateTime 34242and the GDT ReceivedQuantityAccumulation 34200 is either zero or one34256.

For the ReconciliationQuantity 34258, the Category is Element 34260, theObject Class term is Received Quantity Accumulation 34262, the Propertyterm is Reconciliation 34264, the Representation/Association term isQuantity 34266, the Type term is GDT 34268, and the Type Name term isQuantity 34270. The cardinality between the ReconciliationQuantity 34258and the GDT ReceivedQuantityAccumulation 34200 is either zero or one34272.

ReferencePeriod is a reference period for the accumulation.

Quantity is the received quantity that has been cumulated in thespecified reference period up until the time that comes from the usecontext of the GDT. This quantity value is also described as the“cumulative received quantity” in certain industries.

ReconciliationDateTime is the time of completion of the accumulation,which can differ from the end date of the reference period. This timevalue is also described as the “reconciliation date” in certainindustries. When the accumulation is completed for theReconciliationDateTime, the accumulation quantity may be reset or set tozero. For example, several deliveries of goods are arranged in acalendar year (=period). The last delivery for this period takes placeon December 22, however (=ReconciliationDateTime). A further delivery,which arrives on December 30 (therefore, after the reconciliation date),must then be added to the following calendar year as a new accumulationperiod.

ReconciliationQuantity is the accumulated received quantity at the endof the reference period in accordance with the time specified in theReconciliationDateTime. This quantity, which is also called “agreedcumulative quantity” in specific industries, may be used for the legallybinding fixing of the received quantities at the sold-to party.

If the ReferencePeriod is not specified explicitly, the reference periodfor the accumulation may come from the use context of the GDT. This canbe set up, for example, using a reference to a contract item (such asSchedulingAgreementReference). The ReconciliationDateTime may be usedtogether with the ReconciliationQuantity. If the ReconciliationDateTimehas not been specified, the ReconciliationQuantity refers to the endtime of the ReferencePeriod.

The ReceivedQuantityAccumulation may be used for information purposesand for the (legally binding) synchronization of the goods recipient'sreceived goods and the vendor's shipped goods. The transmission ofcumulated quantity values may be used, in particular, in release ordersor forecast delivery schedules (DeliveryScheduleNotification) in thehigh-tech and automotive industry.

Additional values for the cumulated received quantities, for instance,for the affected products and parties, may be described in the usecontext of the GDT.

(hhhhhhhhhh) ReleasedIndicator

The GDT ReleasedIndicator 34300 specifies whether something is releasedor not. The word “something” as used above may stand for an object. Anexample (instance) of the GDT ReleasedIndicator 34300 is:<ReleasedIndicator>true</ReleasedIndicator>.

The GDT ReleasedIndicator 34300 is depicted in FIG. 343. For the GDTReleasedIndicator 34300, the Property term is Released Indicator 34302,the Representation/Association term is Indicator 34304, the Type term isCCT 34306, and the Type Name term is Indicator 34308.

In a variation, the values of the ReleasedIndicator may include:

‘True’ Something is released

‘False’ Something is not released

The ReleasedIndicator may be used for identifying objects that, forexample, are explicitly released or not released through a validationfor processes. In the context of use, a description may be given as towhich object the ReleasedIndicator refers. Something that is notreleased can still be active from a business point of view.

(iiiiiiiiii) RelevanceIndicator

The GDT RelevanceIndicator 34400 indicates whether or not something isto be considered. The word “something” as used above may refer tospecific objects, procedures, actions or transactions. An Example(Instance) of the GDT RelevanceIndicator is:

<PlanningRelevanceIndicator>true</PlanningRelevanceIndicator>.

The GDT RelevanceIndicator 34400 is depicted in FIG. 344. For the GDTRelevanceIndicator 34400, the Property term is Relevance 34402, theRepresentation/Association term is Indicator 34404, and the Type term isCCT: Indicator 34406.

In a variation, the RelevanceIndicator may have the followingattributes:

True: Something is to be considered

False: Something is not to be considered.

For additional description of the value for RelevanceIndicator, see CCT:Indicator above.

For each RelevanceIndicator 34400, precise details may be given of whatis or is not to be considered. A naming prefix (qualifier) may be usedfor this purpose. For example, the following qualifiers may be used:

PlanningRelevanceIndicator: The PlanningRelevanceIndicator specifieswhether or not something is to be considered during planning.

ConfirmationRelevanceIndicator: The ConfirmationRelevanceIndicatorindicates whether or not something is confirmation-relevant.

The RelevanceIndicator can be used to indicate that an order item is tobe considered during a requirement calculation.

(jjjjjjjjjj) ReturnsIndicator

The GDT ReturnsIndicator 34500 specifies whether or not something isreturned. An example (instance) of the GDT ReturnsIndicator 34500 is:

<ReturnsIndicator>true</ReturnsIndicator>.

The GDT ReturnsIndicator 34500 is depicted in FIG. 345. For the GDTReturnsIndicator 34500, the Property term is Returns 34502, theRepresentation/Association term is Indicator 34504, and the Type term isCCT: Indicator 34506.

The ReturnsIndicator 34500 may have the following attributes:

True: This is a return.

False: This is not a return.

For additional description of the value for ReturnsIndicator, see CCT:Indicator above.

The ReturnsIndicator can be used in requirements planning to indicatewhether or not the order item in question is a return.

(kkkkkkkkkk) ReturnMaterialAuthorisationID

The GDT ReturnMaterialAuthorisationID 34600 is a unique identifier forauthorizing the return of a product (of the type material). An example(instance) of the GDT ReturnMaterialAuthorisationID is:

<ReturnMaterialAuthorisationID>XYZ1234AZ5</ReturnMaterialAuthorisationID>.

For the GDT ReturnMaterialAuthorisationID 34600, the Object Class termis Return Material Authorization 34602, the Property term isIdentification 34604, the Representation/Association term is Identifier34606, the Type term is CCT 34608, the Type Name term is Identifier34610, and the Length is from one to twenty 34612.

For additional information on the values for GDTReturnMaterialAuthorisationID 34600, see CCT: Identifier above.

The ReturnMaterialAuthorisationID may be assigned by the goodsrecipient—in the case of third-party deals, also by the original buyeror ordering party. The party performing the (return) delivery may usethe ReturnMaterialAuthorisationID to prove authorization for the returnof the material; for example, when a return delivery is announced viathe DespatchedDeliveryNotification message.

(llllllllll) RevocationIndicator

The GDT RevocationIndicator 34700 indicates whether something is revokedor not. The word “something” used above generally describes, forexample, a legally binding statement, agreement or authority. An example(instance) of the GDT RevocationIndicator 34700 is:  <CollectionAuthorisationRevocationIndicator>true</CollectionAuthorisationRevocationIndicator>.

The GDT RevocationIndicator 34700 is depicted in FIG. 347. For the GDTRevocationIndicator 34700, the Category is Element 34702, the Propertyterm is Revocation 34704, the Representation/Association term isIndicator 34706, the Type term is CCT 34708, and the Type Name term isIndicator 34710.

In a variation, the RevocationIndicator can include the followingvalues: ‘true’ Something is revoked ‘false’ Something is not revoked

The RevocationIndicator 34700 can be used, for example, in a tax returnor purchase order to display whether or not a collection authorizationis revoked.

The context of an interface may contain a description of what is revokedwith the RevocationIndicator 34700. This may be reflected in anappropriate prefix such as “CollectionAuthorisation”.

(mmmmmmmmmm) ScaleAxisStep

The GDT ScaleAxisStep 34800 is a step (scale dimension value) of a scaleaxis. A dimension of the definition area of a scale is known as a scaleaxis. It may be defined as a scale dimension. That is, it may be definedvia the completeness of the specified (discrete) scale dimension valuesas steps. The combination of one step of each scale axis makes up thescale step. An example (instance) of the GDT ScaleAxisStep 34800 is:

Axis step of a (one-dimensional) ‘from’ quantity scale:

The scale axis has the scale base type “quantity”. The axis step amountsto 10 pieces.

(Note:

-   -   ScaleAxisBaseCode 1 represents a quantity according to GDT:        ScaleAxisBaseCode;    -   IntervalBoundaryTypeCode 1 represents the lower limit of an        interval (from the scale dimension value under consideration to        the next highest scale dimension value, but excluding the next        highest scale dimension value) according to the GDT:        ScaleAxisStepIntervalBoundaryTypeCode;

unitCode C62 is one piece according to UN/ECE Recommendation 20.)<ScaleAxisStep>   <ScaleAxisBaseCode>1</ScaleAxisBaseCode>  <IntervalBoundaryTypeCode>1</IntervalBoundaryTypeCode >   <QuantityunitCode=“C62”>10</Quantity> </ScaleAxisStep>.

The GDT ScaleAxisStep 34800 is depicted in FIG. 348. The GDTScaleAxisStep 34800 includes elements ScaleAxisBaseCode 34806,IntervalBoundaryTypeCode 34822, Amount 34838, Quantity 34854,DecimalValue 34870, and IntegerValue 34886. For the GDT ScaleAxisStep34800, the Object Class term is ScaleAxisStep 34802, and theRepresentation/Association term is Details 34804.

For the ScaleAxisBaseCode 34806, the Category is Element 34808, theObject Class term is ScaleAxisStep 34810, the Property term isScaleAxisBase 34812, the Representation/Association term is Code 34814,the Type term is GDT 34816, and the Type Name term is ScaleAxisBaseCode34818. The cardinality between the ScaleAxisBaseCode 34806 and the GDTScaleAxisStep 34800 is one 34820.

For the IntervalBoundaryTypeCode 34822, the Category is Element 34824,the Object Class term is ScaleAxisStep 34826, the Property term isInterval Boundary Type 34828, the Representation/Association term isCode 34830, the Type term is GDT 34832, and the Type Name term isScaleAxisStepIntervalBoundaryTypeCode 34834. The cardinality between theIntervalBoundaryTypeCode 32822 and the GDT ScaleAxisStep 34800 is one34836.

For the Amount 34838, the Category is Element 34840, the Object Classterm is ScaleAxisStep 34842, the Property term is Amount 34844, theRepresentation/Association term is Amount 34846, the Type term is GDT34848, and the Type Name term is Amount 34850. The cardinality betweenthe Amount 34838 and the GDT ScaleAxisStep 34800 is either zero or one34852.

For the Quantity 34854, the Category is Element 34856, the Object Classterm is ScaleAxisStep 34858, the Property term is Quantity 34860, theRepresentation/Association term is Quantity 34862, the Type term is GDT34864, and the Type Name term is Quantity 34866. The cardinality betweenthe Quantity 34854 and the GDT ScaleAxisStep 34800 is either zero or one34868.

For the DecimalValue 34870, the Category is Element 34872, the ObjectClass term is ScaleAxisStep 34874, the Property term is DecimalValue34876, the Representation/Association term is DecimalValue 34878, theType term is GDT 34880, and the Type Name term is DecimalValue 34882.The cardinality between the DecimalValue 34870 and the GDT ScaleAxisStep34800 is either zero or one 34884.

For the IntegerValue 34886, the Category is Element 34888, the ObjectClass term is ScaleAxisStep 34890, the Property term is IntegerValue34892, the Representation/Association term is IntegerValue 34894, theType term is GDT 34896, and the Type Name term is IntegerValue 34898.The cardinality between the IntegerValue 34886 and the GDT ScaleAxisStep34800 is either zero or one 34800A.

ScaleAxisStep 34800 has the following elements: ScaleAxisBaseCode is thecoded representation of the scale base type of the scale axis;IntervalBoundaryTypeCode is the coded representation for theclassification of the step (that is the discrete scale dimension value)as an interval boundary; Amount is the scale dimension value of the axisstep as an amount; Quantity is the scale dimension value of the axisstep as a quantity; DecimalValue is the scale dimension value of theaxis step as the numeric value in decimal representation; IntegerValueis the scale dimension value of the axis step as the numeric value indecimal representation without decimal places.

ScaleAxisStep may contain one of the Amount, Quantity, DecimalValue orIntegerValue elements. The element appropriate for the scale dimensionvalue may be used. ScaleAxisBaseCode may correspond to the same scaleaxis for all axis steps. For additional description on the use ofScaleAxisStep, see GDT: PriceSpecificationElementScaleLine.

(nnnnnnnnnn) SearchText

The GDT SearchText 34900 is a text that is searched for within aparticular data content. The word “text” here refers to, for example, acharacter string. It can also contain special characters (*, ′, ″, etc.)to control the search. An Example of the GDT SearchText is:

<SearchText>Peter Müller</SearchText>.

The GDT SearchText 34900 is depicted in FIG. 349. For the GDT SearchText34900, the Representation/Association Qualifier term is Search 34902,the Representation/Association term is Text 34904, the Type term is xsd34906, and the Type Name term is string 34908. In a variation, there isno restriction on the length of the SearchText.

The SearchText can be used to look for instances of a given businessobject. For example, the SearchText “Peter Müller” can be used to findthe invoices made from a company to the customer “Peter Müller”. Thedata content in this case consists of attributes of the invoice objectand attributes of the associated customer object.

In a variation, SearchText is a generic selection field of a query coreservice within SAP Enterprise Service Infrastructure (ESI).

(oooooooooo) SerialID

The GDT SerialID 35000 (serial number) is a unique identifier for anindividual item that is assigned in the context of production. The“individual item” may be the instance of a product. The identifier of aproduct instance may be unique in the context of a product or a productcategory. For that reason, the SerialID may be the same for instances ofdifferent products. An example (instance) of the GDT SerialID is:

Identification of a vehicle number (vehicle identification number)

<SerialID>WVWZZZ1JZYP1749179</SerialID>.

The GDT SerialID 35000 is depicted in FIG. 350. For the GDT SerialID35000, the Property term is Serial Identification 35002, theRepresentation/Association term Identifier 35004, the Type term is CCT35006, the Type Name term is Identifier 35008, and the Length is fromone to thirty 35010. The GDT SerialID may be a restricted GDT 35012.

A SerialID is an alphanumeric identifier (with may have no distinctionbetween uppercase and lowercase) that is assigned to a product instancefor its lifetime. For that reason, in a variation, it is not be assignedagain to another instance of the same product during the (anticipated)lifetime of the product instance. The SerialID may be specified inconnection with the related product identification (“product number” or“product category”) because the combination of product identificationand SerialID may be unique.

A SerialID may be used in addition to the product identification ifindividual items of the product are to be identified or must beidentified. Serial numbers can be used for industry and consumerproducts and also, for example, for banknotes. In contrast to theequipment or asset number, the serial number is assigned and transmittedin the context of production.

(pppppppppp) ShippedQuantityAccumulation

The GDT ShippedQuantityAccumulation 35100 are values for cumulatedshipped quantities. An example (instance) of the GDTShippedQuantityAccumulation 35100 is: <ShippedQuantityAccumulation>  <ReferencePeriod>    <StartDateTime>2004-01-01T00:00:00Z</StartDateTime>    <EndDateTime>2004-12-31T23:59:59Z </EndDateTime>  </ReferencePeriod>   <Quantity unitCode=”CT”>10000</Quantity></ShippedQuantityAccumulation>.

The GDT ShippedQuantityAccumulation 35100 is depicted in FIG. 351. TheGDT ShippedQuantityAccumulation 35100 includes elements ReferencePeriod35108 and Quantity 35124. For the GDT ShippedQuantityAccumulation 35100,the Object Class term is Shipped Quantity Accumulation 35102, theProperty term is Details 35104, and the Representation/Association termis Details 35106.

For the ReferencePeriod 35108, the Category is Element 35110, the ObjectClass term is Shipped Quantity Accumulation 35112, the Property term isReferencePeriod 35114, the Representation/Association term is Details35116, the Type term is GDT 35118, and the Type Name term isDateTimePeriod 35120. The cardinality between the ReferencePeriod 35108and the GDT ShippedQuantityAccumulation 35100 is either zero or one35122.

For the Quantity 35124, the Category is Element 35126, the Object Classterm is Shipped Quantity Accumulation 35128, the Property term isQuantity 35130, the Representation/Association term is Quantity 35132,the Type term is GDT 35134, the Type Name term is Quantity 35136, andthe Length is thirteen digits with six post-decimal digits 35138. Thecardinality between the Quantity 35124 and the GDTShippedQuantityAccumulation 35100 is one 35140.

ReferencePeriod is the reference period for the accumulation. Quantityis the shipped quantity that has been cumulated in the specifiedreference period up until the time that comes from the use context ofthe GDT. This quantity value may be also described as the “cumulativedelivered quantity” in certain industries.

If the ReferencePeriod is not specified explicitly, the reference periodfor the accumulation may come from the use context of the GDT. This canbe set up, for example, using a reference to a contract item (such asSchedulingAgreementReference).

The ShippedQuantityAccumulation may be used for information purposes andfor the (legally binding) synchronization of the goods recipient'sreceived goods and the vendor's shipped goods. The transmission ofcumulated quantity values may be used, for example, in advanced shippingnotifications (DespatchedDeliveryNotification) in the high-tech andautomotive industry.

Additional values for the cumulated shipped goods, for instance, for theaffected products and parties, may be described in the use context ofthe GDT.

(qqqqqqqqqq) SupplyChainExceptionStatusCode

The GDT SupplyChainExceptionStatusCode 35200 is a coded representationfor the status of an exception that occurs in the supply chain duringlogistics planning or logistics execution. An example (instance) of theGDT SupplyChainExceptionStatusCode 35200 is: <SupplyChainException>  <StatusCode>RESOLVED</StatusCode> </SupplyChainException>.

The GDT SupplyChainExceptionStatusCode 35200 is depicted in FIG. 352.For the GDT SupplyChainExceptionStatusCode 35200, the Object Class termis SupplyChainException 35202, the Property term is Status 35204, theRepresentation/Association term is Code 35206, the Type term is CCT35208, the Type Name term is Code 35210, and the Length is from one tofifteen 35212. The GDT SupplyChainExceptionStatusCode may be arestricted GDT 35214.

In a variation, the values of the SupplyChainExceptionStatusCode mayinclude values in the “Exception Status Code List” of the “EAN.UCC XMLBusiness Message Standards, Version 1.3 (July 2003)”. These are asfollows: Code Name Description ACKNOWLEDGED Acknowledged The exceptionhas been acknowledged. NEW New The exception is new. RESOLVED ResolvedThe problem indicated by the exception has been resolved. SUPERSEDEDSuperseded The original exception has been replaced by a modifiedexception. UNRESOLVABLE Unresolvable The problem indicated by theexception cannot be resolved.

In an example, schemeAgencyID may be included as an attribute. In avariation, if different code lists are supported, the schemeAgencyID=“9”(EAN, International Article Numbering Association) or “113” (UCC,Uniform Code Council) International Numbering Association) from the DE3055 may be specified to identify the code list given above.

The SupplyChainExceptionStatusCode may be set to “NEW” in the initialtransmission of an exception. The other possible code values may betransmitted for the status of an exception when subsequent changes aremade. For example, if an exception with the status code “NEW” occurs for“production standstill”, and this problem is then resolved, the statuscode of the exception is “RESOLVED” in a subsequent message.

(rrrrrrrrrr) SupplyChainExceptionTypeID

The GDT SupplyChainExceptionTypeID 35300 is a unique identifier for thetype of exception that can occur in a supply chain during logisticsplanning or logistics execution. A type of a supply chain exceptiondescribes the (business) nature and basic features of the exception. Thetype definition can be based upon generally-accepted logistic keyfigures as well as industry-specific or proprietary business-specificcriteria. Examples are “forecast deviation”, “product shortage”,“production standstill”, or “delivery delay”.

An Example (Instance) of the GDT SupplyChainExceptionTypeID is:<SupplyChainException>   ... <TypeIDschemeAgencyID=”SCM_001“>4711</TypeID>   ... </SupplyChainException>.

The GDT SupplyChainExceptionTypeID 35300 is depicted in FIG. 353. TheGDT SupplyChainExceptionTypeID 35300 includes attribute schemeAgencyID35316. For the GDT SupplyChainExceptionTypeID 35300, the Object Classterm is SupplyChainException 35302, the Property term is Type 35304, theRepresentation/Association term is Identifier 35306, the Type term isCCT 35308, the Type Name term is Identifier 35310, and the Length isfrom one to four 35312. The GDT SupplyChainExceptionTypeID 35300 may bea restricted GDT 35314.

For the schemeAgencyID 35316, the Category is Attribute 35318, theObject Class term is IdentificationSchemeAgency 35320, the Property termis Identification 35322, the Representation/Association term isIdentifier 35324, the Type term is XSD 35326, the Type Name term isToken 35328, and the Length is from one to sixty 35330. The cardinalitybetween the schemeAgencyID 35316 and the GDT SupplyChainExceptionTypeID35300 is either zero or one 35332.

The schemeAgencyID indicates the business system in which the ID wasassigned. If the schemeAgencyID has not been specified, it may bedetermined from the context.

The SupplyChainExceptionTypeID may be used to describe the variousexception types that can occur in the supply chain during logisticsplanning and logistics execution.

In a variation, in RosettaNet PIP 4A6 “NotifyOfForecastingException” thefollowing code lists exists for different categories ofSupplyChainExceptions: “ComparisonExceptionTypeCode”,“IncidentExceptionTypeCode”, “InformationExceptionTypeCode”, and“ThresholdExceptionTypeCode”. Through mapping, the GDTSupplyChainExceptionTypeID can also cover these codes. However, sincethere are a great number of industry-specific or business-specificrequirements for the occurring SupplyChainExceptions, the GDTSupplyChainExceptionTypeID may use the identification concept instead ofthe code list concept.

The EAN.UCC “Exception Notification” may be restricted to a roughcategorization of SupplyChainExceptions and may not use standardizedcode lists.

(ssssssssss) SystemAdministrativeData

The GDT SystemAdministrativeData 35400 is administrative data that isstored in a system. This data includes system users and changedates/times. An example (instance) of the GDT SystemAdministrativeDatais: <SystemAdministrativeData>  <CreationDateTime>2004-04-19T11:11Z+01:00</CreationDateTime>  <CreationUserAccountID>Bach</CreationUserAccountID>  <LastChangeDateTime>2004-04-19T12:21Z+01:00   </LastChangeDateTime>  <LastChangeUserAccountID>Bach</LastChangeUserAccountID></SystemAdministrativeData>.

The GDT SystemAdministrativeData 35400 is depicted in FIG. 354. The GDTSystemAdministrativeData 35400 includes elements CreationDateTime 35406,CreationUserAccountID 35422, LastChangeDateTime 35438, andLastChangeUserAccountID 35454. For the GDT SystemAdministrativeData35400, the Object Class term is System Administrative Data 35402 and theRepresentation/Association term is Details 35404.

For the CreationDateTime 35406, the Category is Element 35408, theObject Class term is System Administrative Data 35410, the Property termis Creation Date Time 35412, the Representation/Association term isDateTime 35414, the Type term is GDT 35416, and the Type Name term isDateTime 35418. The cardinality between the CreationDateTime 35406 andthe GDT SystemAdministrativeData 35400 is one 35420.

For the CreationUserAccountID 35422, the Category is Element 35424, theObject Class term is System Administrative Data 35426, the Property termis Creation User Account ID 35428, the Representation/Association termis Identifier 35430, the Type term is GDT 35432, and the Type Name termis UserAccountID 35434. The cardinality between theCreationUserAccountID 35422 and the GDT SystemAdministrativeData 35400is one 35436.

For the LastChangeDateTime 35438, the Category is Element 35440, theObject Class term is System Administrative Data 35442, the Property termis Last Change Date Time 35444, the Representation/Association term isDateTime 35446, the Type term is GDT 35448, and the Type Name term isDateTime 35450. The cardinality between the LastChangeDateTime 35438 andthe GDT SystemAdministrativeData 35400 is either zero or one 35452.

For the LastChangeUserAccountID 35454, the Category is Element 35456,the Object Class term is System Administrative Data 35458, the Propertyterm is Last Change User Account ID 35460, theRepresentation/Association term is Identifier 35462, the Type term isGDT 35464, and the Type Name term UserAccountID 35466. The cardinalitybetween the LastChangeUserAccountID 35454 and the GDTSystemAdministrativeData 35400 is either zero or one 35468.

SystemAdministrativeData contains the following elements:CreationDateTime is the creation date/time (date and time stamp);CreationUserAccountID is the creator; LastChangeDateTime is the time(date and time stamp) of last change; and LastChangeUserAccountID is thelast changed by.

SystemAdministrativeData may be used in Business Objects, BusinessDocument Objects, or in any of their parts. When using the GDTSystemAdministrativeData, a description may be used regarding to whichadministrative information reference is made. This may be expressed byusing an appropriate prefix, for example, PurchaseOrder.

(tttttttttt) TaxAuthorityParty

The CDT TaxAuthorityParty 35500 is a party that collects and managestaxes. Examples (instances) for the CDT TaxAuthorityParty 35500 are:  <VATDeclaration>   ...   <TaxAuthorityParty>     <ID>2832</ID>    <CountryCode>DE</CountryCode>     <Address>      <OrganisationFormattedName>Finanzamt Heidelberg</OrganisationFormattedName >       ...     </Address>  </TaxAuthorityParty>   ...   </VATDeclaration>.

The CDT TaxAuthorityParty 35500 is depicted in FIG. 355. The CDTTaxAuthorityParty 35500 includes elements ID 35506, CountryCode 35526,RegionCode 35542, and Address 35558. For the CDT TaxAuthorityParty35500, the Object Class term is Tax Authority Party 35502 and theRepresentation/Association term is Details 35504.

For the ID 35506, the Category is Element 35508, the Object Class termis Tax Authority Party 35510, the Property term is Identification 35512,the Representation/Association term is Identifier 35514, the Type termis CCT 35516, the Type Name term is Identifier 35518, and the Length istwenty 35520. The cardinality between the ID 35506 and the CDTTaxAuthorityParty 35500 is either zero or one 35522. The ID may berestricted 35524.

For the CountryCode 35526, the Category is Element 35528, the ObjectClass term is Tax Authority Party 35530, the Property term is Country35532, the Representation/Association term is Code 35534, the Type termis GDT 35536, and the Type Name term is CountryCode 35538. Thecardinality between the CountryCode 35526 and the CDT TaxAuthorityParty35500 is one 35540.

For the RegionCode 35542, the Category is Element 35544, the ObjectClass term is Tax Authority Party 35546, the Property term is Region35548, the Representation/Association term is Code 35550, the Type termis GDT 35552, and the Type Name term is RegionCode 35554. Thecardinality between the RegionCode 35542 and the CDT TaxAuthorityParty35500 is either zero or one 35556.

For the Address 35558, the Category is Element 35560, the Object Classterm is Tax Authority Party 35562, the Property term is Address 35564,the Representation/Association term is Address 35566, the Type term isGDT 35568, and the Type Name term is Address 35570. The cardinalitybetween the Address 35558 and the CDT TaxAuthorityParty 35500 is eitherzero or one 35572. The Address may be restricted 35574.

ID is an identifier of the tax authority (tax authority number). Countrycode is the country of the tax authority. RegionCode is the region ofthe tax authority. Address is the company address of the tax authority.The unique identification of a tax authority may vary from country tocountry. In many countries, a tax authority number is used foridentification, that is, the “ID” element (in Germany it is called the“Finanzamtsnummer”). “ID” may be unique in the context of the country ofthe tax authority (in the “CountryCode” element). In some countries, theregion and/or company address is used for identification, that is, the“RegionCode” and “Address” elements. In the United States, for example,the IRS (Internal Revenue Service) in Washington D.C. is identified asthe federal tax authority by “Address”, whereas for the tax authoritiesof some states, “RegionCode” and “Address” are required. One example ofthis is CA BOE (California State Board of Equalization). Therefore,depending on the country, either the “ID” or a combination of“RegionCode” and “Address” may be specified.

The GDT TaxAuthorityParty contains information about a tax authoritywhich may be used in A2A or B2B messages, for example, in the electronictax return for tax on sales/purchases (VATDeclaration) to a taxauthority.

(uuuuuuuuuu) TaxIdentificationNumberTypeCode

The GDT TaxIdentificationNumberTypeCode 35600 is a coded representationof the type of a tax number. An Example of the GDTTaxIdentificationNumberTypeCode 35600 is:<TaxIdentificationNumberTypeCode>DE0</TaxIdentificationNumberTypeCode>.

The GDT TaxIdentificationNumberTypeCode 35600 is depicted in FIG. 356.For the GDT TaxIdentificationNumberTypeCode 35600, the Object Class termis Tax Identification Number 35602, the Property term is Type 35604, theRepresentation/Association term is Code 35606, the Type term is CCT35608, the Type Name term is Code 35610, and the Length is from three tofour 35612.

Each country may have its own TaxIdentificationNumberTypeCodes. Theremay be different codes for different regions, different taxes or groupsof taxes, or different types of taxpayers.

In a variation, SAP supplies the values in the form of the illustrativelist presented in the table below. The first two characters in the codeare the two-letter ISO code for the country (ISO 3166-1). The name ofthe TaxIdentificationNumberTypeCode is the official name used in thecountry in question (or its transcription). Code Name Description AR0Código Único de Identificación Argentina: CUIT Number Tributaria (CUIT)AR1 Clave Única de Identificación Argentina: CUIL Number Laboral (CUIL)AR2 Número impuesto sobre renta Argentina: Income Tax Number AR3 Númeroimpuesto regional Argentina: NIP Number or CM Number AT0 Umsatzsteuer-Austria: VAT Registration Number Identifikationsnummer (UID) AU0Australian Business Number (ABN) Australia: ABN BE0 In French: Le numéroBelgium: VAT Registration Number d'identification à la taxe sur lavaleur ajoutée (N^(o) TVA) In Dutch: BTW-Nummer (BTW-nr) BE1 In French:Numéro d'identification Belgium: Ministry Of Finance Ministère desFinances Registration Number In Dutch: MiniFin-Nummer BE2 In French: Lenuméro Belgium: VAT Registration Number d'identification à la taxe surla valeur ajoutée (N^(o) TVA) In Dutch: BTW-Nummer (BTW-nr) BG1 EdinenIdentifikacionen kod Bulgaria: Unified ID Code BG2 Edinen GrazhdanskiNomer Bulgaria: Personal ID BG3 Osiguritelen nomer Bulgaria: SocialSecurity Number BR1 Cadastro Nacional de Pessoa Brazil: CNPJ NumberJurídica (CNPJ) BR2 Cadastro de Pessoa Física (CPF) Brazil: CPF NumberBR3 Inscrição Estadual Brazil: State Tax Number BR4 Inscrição MunicipalBrazil: Municipal Tax Number CH1 Mehrwerststeuer-Nummer (MwSt)Switzerland: VAT Number CL1 Número de rol unico tributario Chile: RUTNumber (RUT) CN1 customer's (

)-(ke China: Tax Number hu de zeng zhi shui shui hao), vendor's (

)- (gong ying shang de zeng zhi shui shui hao) CO1 Número deidentificación tributaria Colombia: NIT Number (NIT) CZ0 danovéidentifikacní císlo (DIC) Czech Republic: VAT Registration Number CZ1danové identifikacní císlo (DIC) Czech Republic: DIC Number CZ2identifikacní císlo organizace (ICO) Czech Republic: ICO Number DE0Umsatzsteuer-ID-Nr. (USt-IdNr) Germany: VAT Registration Number DE1Ertragssteuernummer (§48) Germany: Income Tax Number (§48) DE2Umsatzsteuernr. (Gutschriftsverf. Germany: VAT Number (Credit §14)Procedure §14) DE3 Elster Steuernummer Germany: Elster Tax Number DE4Steuernummer Germany: Tax Number DK0 Det Centrale VirksomhedsregisterDenmark: VAT Registration Number Nummer (CRV-nummer) EE0käibemaksukohustuslase Estonia: VAT Registration Numberregistreerimisnumber (KMKR number) ES0 El número de identificación aefectos Spain: VAT Registration Number del Impuesto sobre el ValorAnadido ES1 Número de Identificación Fiscal Spain: NIF Number (NIF) ES2Número de documento nacional de Spain: DNI Number identidad (DNI) FI0Arvonlisäveronumero (ALV-nro) Finland: VAT Registration Number Le numérod'identification à la taxe FR0 sur la valeur ajoutée (ID. TVA) France:VAT Registration Number Numéro: identifier 1'établissement de FR11'entreprise (SIRET) France: SIRET Number FR2 Numéro: Système NationalFrance: SIREN Number Informatique pour le Répertoire des Entreprises etdes Etablissements (SIREN) GB0 VAT Registration Number (VAT UnitedKingdom: VAT Registration Reg. No) Number GB2 National Insurance NumberUnited Kingdom: National Insurance GR0 Arithmos Forologikou Mitroou FPANumber GR0 (A.φ.M) Greece: VAT Registration Number GR1 arithmostaytotetas Greece: Personal ID GR2 arithmos phoroaogikoy metrooy.Greece: AFM Number HR1 Jedinstveni Mati{hacek over (c)}ni Broj Gra

ana Croatia: JMBG Number (JMBG) HU0 közösségi adószám Hungary: VATRegistration Number HU1 adóazonositó szám Hungary: Tax Number ID1 NomorPokok Wajib Pajak (NPWP) Indonesia: NPWP Number ID3 Nomor PengukuhanPengusaha Kena Indonesia: NPPKP Number Pajak (NPPKP) IE0 VATRegistration Number (VAT Ireland: VAT Registration Number Reg. No) IT0Codice IVA (Numero di Partita IVA, Italy: VAT. Registration Number P.IVAT) IT1 Codice Fiscale Italy: Codice Fiscale IT2 Partita IVA Italy:IVA Code KR1 Corporation Number South Korea: Corporation ID KR2Personal/Business Identification South Korea: VAT Registration NumberNumber KZ1 Registratzionnyj Nomer Kazakhstan: RNN NumberNalogoplatelschika (PHH) LT0 Pridetines vertes mokescio mok{dot over(e)}tojo Lithuania: VAT Registration Number kodas (PVM moketojo kodas)LU0 Le numéro d'identification à la taxe Luxembourg: VAT RegistrationNumber sur la valeur ajoutée (ID. TVA) LV0 PVN maksataja re{grave over(g)}istr acijas numurs Latvia: VAT Registration Number (PVN re{graveover (g)}istr acijas numurs) MC0 Le numéro d'identification à la taxeMonaco: VAT Registration Number sur la valeur ajoutée (ID. TVA) MT0numru ta'l-identifikazzjoni tat-taxxa Malta: VAT Registration Number fuqil-valur miújud MX1 Registro Federal de Contribuyentes Mexico: RFCNumber (RFC) MX2 Clave Unica de Registro de Mexico: VAT Liability MX3Poblacion (CURP) Mexico: CURP Number NL0 BTW-identificatienummer (BTW-Netherlands: VAT Registration Number Nr.) NO2 Foretaksnummer Norway: TaxNumber PE1 Número de registro unico de Peru: RUC Number contribuyentes(RUC) PH1 Taxpayer Identification Number Philippines: Taxpayer ID Number(TIN) PL0 Numer identyfikacji podatkowej Poland: VAT Registration Number(NIP) PL1 Numer identyfikacji podatkowej Poland: NIP Number (NIP) PT0Número de identificação fiscal Portugal: VAT Registration Number (NIPC)RO1 cod de identificare fiscala Romania: Tax Number RU1 IndividualnijNalogovyj Numer Russia: INN (INN) RU2 Obscherossijsky KlassifikatorRussia: OKPO Code Predprijatij u Organizatchij (OKPO) RU3 Kod PrichinyPostanovki na Uchjot Russia: KPP Number (KPP) RU4 Kod Organizatchii vOrgane Russia: OFK Number SE0 Federal'nogo Kaznatchejstva (OFK) Sweden:VAT Registration Number Momsregistreringsnummer (Moms Reg. Nr.) SE2Organisationsnummer Sweden: Organization Registration Number SG1 GSTRegistration Number Singapore: GST Registration Number SI0identifikacijska {hacek over (s)}tevilka za DDV Slovenia: VATRegistration Number SI1 dav{hacek over (c)}na {hacek over (s)}tevilkaSlovenia: Tax Number SK0 Identifika{hacek over (c)}ne {hacek over(c)}íslo pre da{hacek over (n)} (I{hacek over (C)} DPH) Slovakia: VATRegistration Number SK1 Da{hacek over (n)}ové identifika{hacek over(c)}né {hacek over (c)}íslo (DIC) Slovakia: DIC Number SK2Identifika{hacek over (c)}né {hacek over (c)}íslo organizácie (ICO)Slovakia: ICO Number TH1 Personal Identification Number Thailand:Personal ID (

) TH2 Registered Tax Identification Thailand: Tax ID Number (

) TR1 Turkey: Tax Office TR2 vergi numarasi Turkey: Tax Number TW1 TongYi Bian Hao Taiwan: GUI Registration Number TW2 Shuei Ji Bian HaoTaiwan: Tax Registration Number UA1 Individualnij Nalogovyj NumerUkraine: INN (INN)

(

HH) UA2 Identifikatsionnyj kod platelschika Ukraine: EDRPOU Number poEdinomu Gosudarstvennomu Reestru Predprijatij i Organizhatsij Ukrainy(EGRPOU) UA3 Identifikatsionnyj kod platelschika Ukraine: DRFO Number poGosudarstvennomu Reestru Fizhicheskih Lits (GRFL)

(

) UA4 Identifikatsionnyj kod platelschika Ukraine: Joint VentureRegistration dlja Sovmestnyh Predprijatij (SP) Number US1 SocialSecurity Number United States: Social Security Number US2 EmployerIdentification Number United States: Employer ID Number VE1 Registroidentificación fiscal (RIF) Venezuela: RIF Number VE2 Númeroidentificación tributaria Venezuela: NIT Number (NIT)

The data type may be used in conjunction with the tax number.

(vvvvvvvvvv) TestDataIndicator

The GDT TestDataIndicator 35700 indicates whether the specified data istest data or not. An example (instance) for the GDT TestDataIndicator35700 is:

<TestDataIndicator>true</TestDataIndicator>.

The GDT TestDataIndicator 35700 is depicted in FIG. 357. For the GDTTestDataIndicator 35700, the Category is Element 35702, the Propertyterm is Test Data 35704, the Representation/Association term isIndicator 35706, the Type term is CCT 35708, and the Type Name term isIndicator 35710.

In a variation, the TestDataIndicator may include the following values:‘true’ The specified data is test data ‘false’ The specified data is nottest data

The TestDataIndicator may be used as part of theBusinessDocumentMessageHeader to display whether the data contained inthe message is test data or not. The context of an interface maydescribe the business meaning of the ‘true’ and ‘false’ values of theTestDataIndicator.

(wwwwwwwwww) UserAccountID

The GDT UserAccountID 35800 is a unique identifier for a system's useraccount. An example (instance) for the GDT UserAccountID 35800 is:

<UserAccountID>smith</UserAccountID>.

The GDT UserAccountID 35800 is depicted in FIG. 358. The GDTUserAccountID 35800 includes attributes schemeAgencyID 35814 andschemeAgencySchemeAgencyID 35832. For the GDT UserAccountID 35800, theObject Class term is User Account 35802, the Property term isIdentification 35804, the Representation/Association term is Identifier35806, the Type term is CCT 35808, the Type Name term is Identifier35810, and the Length is from one to two hundred fifty-five 35812.

For the schemeAgencyID 35814, the Category is Attribute 35816, theObject Class term is IdentificationSchemeAgency 35818, the Property termis Identification 35820, the Representation/Association term isIdentifier 35822, the Type term is xsd 35824, the Type Name term istoken 35826, and the Length is from one to sixty 35828. The cardinalitybetween the schemeAgencyID 35814 and the GDT UserAccountID 35800 iseither zero or one 35830.

For the schemeAgencySchemeAgencyID 35832, the Category is Attribute35834, the Object Class term is IdentificationSchemeAgency 35836, theProperty term is SchemeAgency 35838, the Representation/Association termis Identifier 35840, the Type term is xsd 35842, the Type Name term istoken 35844, and the Length is three 35846. The cardinality between theschemeAgencySchemeAgencyID 35832 and the GDT UserAccountID 35800 iseither zero or one 35848.

SchemeAgencyID identifies the system that defined the identifier.SchemeAgencySchemeAgencyID may be mutually defined.

(xxxxxxxxxx) AccountDeterminationHouseBankGroupCode

A GDT AccountDeterminationHouseBankGroupCode 35800AA is a codedrepresentation of a group of house banks based on the viewpoint of asimilar determination of accounts in accounting. An example of GDTAccountDeterminationHouseBankGroupCode 35800AA is:

<AccountDeterminationHouseBankGroupCode>1</AccountDeterminationHouseBankGroupCode>

The structure of GDT AccountDeterminationHouseBankGroupCode 35800AA isdepicted in FIG. 358AA. For the GDTAccountDeterminationHouseBankGroupCode 35800AA, the Object Class TermQualifier is Account Determination 35802AA, the Object Class Term isHouse Bank Group 35804AA, the Representation/Association is Code35806AA, the Type is CCT 35808AA, the Type Name is Code 35810AA and theLength is from one to four 35812AA. The remark 35814AA shows that theGDT AccountDeterminationHouseBankGroupCode 35800AA may be restricted.

A customer-specific code list is assigned to a code. A customer candetermine the codes in a code list. The attributes of the code areassigned the following values: listAgencyID—ID of the Customer (ID fromDE 3055, if listed there), listVersionID—version of the particular codelist. Assigned and managed by the Customer, listAgencySchemeID—ID of thescheme if the listAgencyID does not come from DE 3055, orlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme

The data type GDT AccountDeterminationHouseBankGroupCode 35800AA may usethe following codes: domestic house banks, i.e., house banks withheadquarters in home country or foreign house banks, i.e., house bankswith headquarters abroad.

For the purposes of proper financial reporting, in some variations, thevalue-based representation of business transactions in accounting mustuse different accounts. The AccountDeterminationHouseBankGroupCode maybe used in the business object models and in A2A messages.

(yyyyyyyyyy) AccountDeterminationBusinessPartnerGroupCode

A GDT AccountDeterminationBusinessPartnerGroupCode 35800AB is a codedrepresentation of a group of business partners based on the viewpoint ofa similar derivation of accounts in accounting. An example of GDTAccountDeterminationBusinessPartnerGroupCode 35800AB is:

<AccountDeterminationBusinessPartnerGroupCode>1</AccountDeterminationBusinessPartnerGroupCode>

The structure of GDT AccountDeterminationBusinessPartnerGroupCode35800AB is depicted in FIG. 358AB. For the GDTAccountDeterminationBusinessPartnerGroupCode 35800AB, the Object Classis Account Determination Business Partner Group 35802AB, theRepresentation/Association is Code 35804AB, the Type is CCT 35806AB, theType Name is Code 35808AB, and the Length is from one to ten 35810AB.The remark 35812AB shows that the GDTAccountDeterminationBusinessPartnerGroupCode 35800AB may be restrictedThe data type GDT AccountDeterminationBusinessPartnerGroupCode 35800ABmay use the following codes: domestic business partners, i.e., businesspartners with headquarters in home country or foreign business partners,i.e., business partners with headquarters abroad. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10317,” listAgencyID—ID of theCustomer (ID from DE 3055, if listed there), listVersionID—version ofthe particular code list, listAgencySchemeID—ID of the scheme if thelistAgencyID does not come from DE 3055, and listAgencySchemeAgencyID—IDof the organization from DE 3055 that manages the listAgencySchemeIDscheme. For the purposes of proper financial reporting, in somevariations, the value-based representation of business transactions inaccounting must use different accounts.

(zzzzzzzzzz) AccountDeterminationExpenseGroupCode

A GDT AccountDeterminationExpenseGroupCode 35800AC is the codedrepresentation of a group of expenses from the perspective of anidentical or similar determination of an account in accounting. Anexample of GDT AccountDeterminationExpenseGroupCode 35800AC is:

<AccountDeterminationExpenseGroupCode>110</AccountDeterminationExpenseGroupCode>

The structure of GDT AccountDeterminationExpenseGroupCode 35800AC isdepicted in FIG. 358AC. For GDT Account Determination Expense Group Code35800AC, the Object Class Term Qualifier is Account Determination35802AC, the Object Class Term is Expense Group 35804AC, theRepresentation/Association is Code 35806AC, the Type is CCT 35808AC, theType Name is Code 35810AC, and the Length is from one to four 35812AC.The remark 35814AC shows that the GDTAccountDeterminationExpenseGroupCode 35800AC may be restricted.

The data type AccountDeterminationExpenseGroupCode 35800AC may use codesfor costs for meals, costs for accommodations, travel costs forattending a seminar or costs for domestic trips to name a few examples.A customer-specific code list is assigned to the code. TheAccountDeterminationExpenseGroupCode 35800AC may be used in the businessobject models and in A2A messages. The attributes of the code areassigned the following values: listID=“10319,” listAgencyID—ID of theCustomer (ID from DE 3055, if listed there), listVersionID—version ofthe particular code list. Assigned and managed by the Customer,listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055, and listAgencySchemeAgencyID—ID of the organization fromDE 3055 that manages the listAgencySchemeID scheme.

(aaaaaaaaaaa) AccountDeterminationFixedAssetClassGroupCode

A GDT AccountDeterminationFixedAssetClassGroupCode 35800AD is the codedrepresentation of a group of fixed asset classes based on the viewpointof a similar derivation of accounts in accounting. An example of a GDTAccountDeterminationFixedAssetClassGroupCode 35800AD is:

<AccountDeterminationFixedAssetClassGroupCode>1</AccountDeterminationFixedAssetClassGroupCode>

The structure of GDT AccountDeterminationFixedAssetClassGroupCode35800AD is depicted in FIG. 358AD. For GDT Account Determination FixedAsset Class Group Code 35800AD, the Object Class is AccountDetermination Fixed Asset Class Group 35802AD, theRepresentation/Association is Code 35804AD, the Type is CCT 35806AD, theType Name is Code 35808AD, and the Length is from one to ten 35810AD.The remark 35810AD shows that the GDTAccountDeterminationFixedAssetClassGroupCode 35800AD may be restricted.

The data type GDT AccountDeterminationFixedAssetClassGroupCode 35800ADmay use codes for codes for vehicle fleets, such as cars and vans orreal estate, to name a few examples. TheAccountDeterminationFixedAssetClassGroupCode may be used in the businessobject models and in A2A messages.

A customer can determine the codes in the code list. The attributes ofthe code are assigned the following values: listID=“10320,”listAgencyID—ID of the Customer (ID from DE 3055, if listed there),listVersionID—version of the particular code list, listAgencySchemeID—IDof the scheme if the listAgencyID does not come from DE 3055, andlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme

(bbbbbbbbbbb) AccountDeterminationMaterialLedgerAccountGroupCode

A GDT AccountDeterminationMaterialLedgerAccountGroupCode 35800AE is thecoded representation of a group of material ledger accounts based on theviewpoint of a similar derivation of accounts in accounting. An exampleof a GDT AccountDeterminationMaterialLedgerAccountGroupCode 35800AE is:

<AccountDeterminationMaterialLedgerAccountGroupCode>1</AccountDeterminationMaterialLedgerAccountGroupCode>

The structure of GDT AccountDeterminationMaterialLedgerAccountGroupCode35800AE is depicted in FIG. 358AE. For GDTAccountDeterminationMaterialLedgerAccountGroupCode 35800AE, the ObjectClass Term Qualifier is Account Determination 35802AE, the Object Classis Material Ledger Account Group 35804AE, the Representation/Associationis Code 35806AE, the Type is CCT 35808AE, the Type Name is Code 35810AE,and the Length is from one to ten 35812AE. The remark 35814AE shows thatthe GDT AccountDeterminationMaterialLedgerAccountGroupCode 35800AE maybe restricted.

The data type GDT AccountDeterminationMaterialLedgerAccountGroupCode35800AE may use codes for raw materials, such as materials that have notundergone processing or finished products that are ready for sale. TheAccountDeterminationMaterialLedgerAccountGroupCode 35800AE may be usedin the business object models and in A2A messages.

A customer can determine the codes in the code list. The attributes ofthe code are assigned the following values: listID=“10321,”listAgencyID—ID of the Customer (ID from DE 3055, if listed there),listVersionID—version of the particular code list. Assigned and managedby the Customer, listAgencySchemeID—ID of the scheme if the listAgencyIDdoes not come from DE 3055, and listAgencySchemeAgencyID—ID of theorganization from DE 3055 that manages the listAgencySchemeID scheme.

(ccccccccccc) AccountDeterminationServiceProductGroupCode

A GDT AccountDeterminationServiceProductGroupCode 35800AF is the codedrepresentation of a group of service products from the viewpoint ofidentical determination of accounts in accounting. An example of the GDTAccountDeterminationServiceProductGroupCode 35800AF is:

<AccountDeterminationServiceProductGroupCode>1</AccountDeterminationServiceProductGroupCode>

The structure of the GDT AccountDeterminationServiceProductGroupCode35800AF is depicted in FIG. 358AF. For GDTAccountDeterminationServiceProductGroupCode 35800AF, the Object ClassTerm Qualifier is Account Determination 35802AF, the Object Class Termis Service Product Group 35804AF, the Representation/Association is Code35806AF, the Type is CCT 35808AF, the Type Name is Code 35810AF, and theLength is from one to four 35812AF. The remark 35814AF shows that theGDT AccountDeterminationServiceProductGroupCode 35800AF may berestricted.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10323,” listAgencyID—ID of theCustomer (ID from DE 3055, if listed there), listVersionID—version ofthe particular code list. Assigned and managed by the Customer,listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055, and listAgencySchemeAgencyID—ID of the organization fromDE 3055 that manages the listAgencySchemeID scheme.

The AccountDeterminationServiceProductGroupCode 35800AF may be used inthe business object models and in A2A messages.

(ddddddddddd) AccountingObjectSetAssignment

A GDT AccountingObjectSetAssignment 35800AG is the assignment ofsomething to a set of accounting objects. For example, the entitiesassigned may be an amount known from the context, a quantity, or acompany resource, such as office space or working time. An example ofGDT AccountingObjectSetAssignment 35800AG is: <InvoiceItem>   ...  <NetAmount @currencyCode=“EUR”>100</NetAmount>   ...  <AccountingObjectSetAssignment>     <Percent>40</Percent>    <AccountingObjectSet>       <CostCentreID>CC1000</CostCentreID>    </AccountingObjectSet>   </AccountingObjectSetAssignment>  <AccountingObjectSetAssignment>     <Percent>60</Percent>    <AccountingObjectSet>       <CostCentreID>CC2000</CostCentreID>    </AccountingObjectSet>   </AccountingObjectSetAssignment></InvoiceItem>

The structure of the GDT AccountingObjectSetAssignment 35800AG isdepicted in FIG. 358AG. For the GDT AccountingObjectSetAssignment35800AG, the Object Class is Accounting Object Set Assignment 35802AG,and the Property is Details 358AG.

FIG. 358AG uses the terms percent, amount and quantity to representspecific features of a GDT. The term percent represents a percentageshare of an entity known from the context that is assigned to anAccountingObjectSet. The term amount represents an amount that isassigned to an AccountingObjectSet. The term quantity represents aquantity that is assigned to an AccountingObjectSet. In some variations,either percent, amount, or quantity may be specified. A combination ofthese is not permitted. If more than one AccountingObjectSetAssignmentcan be used to assign percentage shares of a total amount known from thecontext or percentage shares of a total quantity, for example, todifferent AccountingObjectSets, the following conditions apply: allpercentage values must add up to a total of 100, all amount values mustadd up to the total amount, and all quantity values must add up to thetotal quantity.

For the Percent 35806AG, the Category is Element (E) 35808AG, the ObjectClass is Accounting Object Set Assignment 35810AG, the Property isPercent 35812AG, the Representation/Association is Percent 35814AG, theType is GDT 35816AG, the Type Name is Percent 35818AG, and theCardinality is from zero to one 35820AG.

For the Amount 35822AG, the Category is Element (E) 35824AG, the ObjectClass is Accounting Object Set Assignment 35826AG, the Property isAmount 35828AG, the Representation/Association is Amount 35830AG, theType is GDT 35832AG, the Type Name is Amount 35834AG, and theCardinality is from zero to one 35836AG.

For the Quantity 35838AG, the Category is Element (E) 35840AG, theObject Class is Accounting Object Set Assignment 35842AG, the Propertyis Quantity 35844AG, the Representation/Association is Quantity 35846AG,the Type is GDT 35848AG, the Type Name is Quantity 35850AG, and theCardinality is from zero to one 35852AG.

For the Accounting Object Set 35854AG, the Category is Element (E)35856AG, the Object Class is Accounting Object Set Assignment 35858AG,the Property Accounting Object Set 35860AG, theRepresentation/Association is Accounting Object Set 35862AG, the Type isGDT 35864AG, the Type Name is Accounting Object Set 35866AG, and theCardinality is one 35868AG.

The data type AccountingObjectSetAssignment 35800AG can be used formultiple account assignments, that is, to assign something to multipleAccounting Object Sets. The entity to be assigned can be distributedacross the Accounting Object Sets using shares relating to percentages,amounts, or quantities. For example, expenses from the purchase ofoffice supplies can be transferred to Accounting once an incominginvoice for the materials has been checked.

(eeeeeeeeeee) AccountingPeriodID

A GDT AccountingPeriodID 35800AH is a unique identifier for anaccounting period in a fiscal year. An example of GDT Accounting PeriodID 35800AH is:

<AccountingPeriodID>12</AccountingPeriodID>

The structure of GDT AccountingPeriodID 35800AH is depicted in FIG.358AH. An accounting period is a subdivision of a fiscal year for whichthe operating results are determined and financial statements areprepared. For GDT AccountingPeriodID 35800AH, the Object Class isAccountingPeriod 35802AH, the Property is Identification 35804AH, theRepresentation/Association is Identifier 35806AH, the Type is CCT35808AH, the Type Name is Identifier 35810AH, and the Length is from oneto three 35812AH.

The data type GDT AccountingPeriodID 35800AH provides a 3 digit positivenumber (by a restriction of CCT Identifier). The remark 35814AH showsthat the GDT AccountingPeriodID 35800AH may be restricted.

(fffffffffff) AuthorityTypeCode

A GDT AuthorityTypeCode 35800AI is the code indicating the type ofauthority. The code defines the employment agency for an appropriatecountry (i.e., DE for Germany). The code can be used in PersonnelAdministration to fulfill the legal obligations with regard to thecontributions for severely disabled persons. An example of GDTAuthorityTypeCode 35800AI is:

<AuthorityTypeCode listID=20501 listAgencyID=310>1</AuthorityTypeCode>

AuthorityTypeCode may represent multiple authority sources, such as, forexample: Code 1 is when the authority is an employment agency, Code 2 iswhen the authority is the department of family and social services, Code3 is when the authority is a trade association Code 4 is when theauthority is the welfare office, a division within the social servicesdepartment, Code 5 is when the authority is the department forintegration, which is responsible for the integration of severelydisabled persons into the general labor market, Code 6 is when theauthority is the regional employment office and Code 7 is when theauthority is the regional board.

The structure of GDT AuthorityTypeCode 35800AI is depicted in FIG.358AI. For GDT AuthorityTypeCode 35800AI, the Object Class is AuthorityType 35802AI, the Representation/Association is Code 35804AI, the Typeis CCT 35806AI and the Length is from one to two. The remark 35812AIshows that .GDT AuthorityTypeCode 35800AI can be restricted. Forexample, some code values of GDT AuthorityTypeCode 35800AI may berestricted according to an environment during use.

The GDT AuthorityTypeCode 35800AI includes an element ListID 35814AI,For ListID 35814AI, the Category is Attribute (A) 35816AI, the ObjectClass is CodeList 35818AI, the Property is Identification 35820AI, theRepresentation/Association is Identifier 35822AI, the Type is XSD35824AI, the Type Name is token 35826AI, and the Cardinality between GDTAuthorityTypeCode 35800AI and ListID 35814AI is from zero to one35828AI.

The GDT AuthorityTypeCode 35800AI includes an element ListAgencyID35830AI, For ListAgencyID 35830AI, the Category is Attribute (A)35832AI, the Object Class is CodeListAgency 35834AI, the Property isIdentification 35836AI, the Representation/Association is Identifier35838AI, the Type is XSD 35840AI, the Type Name is token 35842AI, andthe Cardinality between GDT AuthorityTypeCode 35800AI and ListAgencyID35844AI is from zero to one 35844AI.

The GDT AuthorityTypeCode 35800AI includes an element ListVersionID35846AI, For ListVersionID 35846AI, the Category is Attribute (A)35848AI, the Object Class is CodeList 35850AI, the Property is Version35852AI, the Representation/Association is Identifier 35854AI, the Typeis XSD 35856AI, the Type Name is token 35858AI, and the Cardinalitybetween GDT AuthorityTypeCode 35800AI and ListVersionID 35846AI is fromzero to one 35860AI.

The GDT AuthorityTypeCode 35800AI includes an element ListAgencySchemeID35862AI, For ListAgencySchemeID 35862AI, the Category is Attribute (A)35864AI, the Object Class is CodeListAgency 35866AI, the Property isScheme 35868AI, the Representation/Association is Identifier 35870AI,the Type is XSD 35872AI, the Type Name is token 35874AI, and theCardinality between GDT AuthorityTypeCode 35800AI and ListAgencySchemeID35862AI is from zero to one 35876AI.

The GDT AuthorityTypeCode 35800AI includes an elementListAgencySchemeAgencyID 35878AI, For ListAgencySchemeAgencyID 35878AI,the Category is Attribute (A) 35880AI, the Object Class isCodeListAgency 35882AI, the Property is Scheme Agency 35884AI, theRepresentation/Association is Identifier 35886AI, the Type is XSD35888AI, the Type Name is token 35890AI, and the Cardinality between GDTAuthorityTypeCode 35800AI and ListAgencySchemeAgencyID 35878AI is fromzero to one 35892AI.

Several fixed, country-specific code lists, which can be different atruntime, can be assigned to the code. The individual code lists and thevalues and attributes can be: listID=20501, and listAgencyID=310.

The AuthorityTypeCodeContextElements defines a dependency or anenvironment in which the AuthorityTypeCode appears. The environment isdescribed by context categories. With the context categories inAuthorityTypeCodeContextElements, the valid portion of code values ofAuthorityTypeCode is restricted according to an envi-ronment during use.

(ggggggggggg) Bank

A GDT Bank 35800AJ is a business entity that performs financialinvestment services and payment transactions. The GDT Bank representsthe attributes of a bank that identify a bank within the requirements ofthe payment transaction. It may not be suitable for representing theorganizational structure of a credit institution. A GDT Bank 35800AJ maybe a branch of a bank with a registered office in Germany withinformation about the SWIFT code and the bank number. An example of aGDT Bank 35800AJ is: <Bank>   <InternalID>Comdirect BankQuickborn</InternalID>   <StandardID>COBADEHDXXX</StandardID>  <RoutingID>20041111</RoutingID>  <RoutingIDTypeCode>BL</RoutingIDTypeCode>  <CountryCode>DE<CountryCode> </Bank>

The structure of GDT Bank 35800AJ is depicted in FIG. 358AJ. For GDTBank 35800AJ, the Object Class is Bank 35802AJ and theRepresentation/Association is Details 35804AJ.

Several terms are used in FIG. 358AJ to describe the architecture. Theseinclude:

InternalID—proprietary identifier for the bank that can be used whenboth sender and recipient can access shared master data (extendedenterprise).

StandardID—Bank Identification Code (BIC) of the Society for WorldwideInterbank Financial Telecommunications (S.W.I.F.T.), see GDTBankStandardID.

RoutingID—Number of the bank in a clearing system (see GDTBankRoutingID).

RoutingIDTypeCode—Type of RoutingID (see GDT BankRoutingIDTypeCode).

CountryCode—bank country, the country in which the bank identifiedearlier goes about its business. If the bank is a member in a nationalclearing system, the country to which this clearing system belongs isentered here.

Address—Address of the bank

BranchAddress—Address of the branch of the bank

GDT Bank 35800AJ includes an element InternalID 35806AJ. For Internal ID35806AJ, the Category is E 35808AJ, the Object Class is Bank 35810AJ,the Property is Internal Identification 35812AJ, theRepresentation/Association is Identifier 35814AJ, the Type is GDT35816AJ, the Type Name is BankInternalID 35818AJ and the Cardinalitybetween GDT Bank 35800AJ and InternalID 35806AJ is from zero to one35820AJ.

GDT Bank 35800AJ includes an element StandardID 35822AJ. For StandardID35822AJ, the Category is E 35824AJ, the Object Class is Bank 35826AJ,the Property is Standard Identification 35828AJ, theRepresentation/Association is Identifier 35830AJ, the Type is GDT35832AJ, the Type Name is BankStandardID 35834AJ and the Cardinalitybetween GDT Bank 35800AJ and StandardID 35822AJ is from zero to one35836AJ.

GDT Bank 35800AJ includes an element RoutingID 35838AJ. For RoutingID35838AJ, the Category is E 35840AJ, the Object Class is Bank 35842AJ,the Property is Routing Identification 35844AJ, theRepresentation/Association is Identifier 35846AJ, the Type is GDT35848AJ, the Type Name is BankRoutingID 35850AJ and the Cardinalitybetween GDT Bank 35800AJ and RoutingID 35838AJ is from zero to one35852AJ.

GDT Bank 35800AJ includes an element RoutingIDTypeCode 35854AJ. ForRoutingIDTypeCode 35854AJ, the Category is E 35856AJ, the Object Classis Bank 35858AJ, the Property is Routing Identification Type 35860AJ,the Representation/Association is Code 35862AJ, the Type is GDT 35864AJ,the Type Name is BankRoutingIDTypeCode 35866AJ and the Cardinalitybetween GDT Bank 35800AJ and RoutingIDTypeCode 35854AJ is from zero toone 35868AJ.

GDT Bank 35800AJ includes an element CountryCode 35870AJ. ForCountryCode 35870AJ, the Category is E 35872AJ, the Object Class is Bank35874AJ, the Property is Country 35876AJ, the Representation/Associationis Code 35878AJ, the Type is GDT 35880AJ, the Type Name is CountryCode35881AJ and the Cardinality between GDT Bank 35800AJ and CountryCode35870AJ is from zero to one 35882AJ.

GDT Bank 35800AJ includes an element Address 35883AJ. For Address35883AJ, the Category is E 35884AJ, the Object Class is Bank 35885AJ,the Property is Address 35886AJ, the Representation/Association isDetails 35887AJ, the Type is GDT 35888AJ, the Type Name is Address35889AJ and the Cardinality between GDT Bank 35800AJ and Address 35883AJis from zero to one 35890AJ.

GDT Bank 35800AJ includes an element BranchAddress 35891AJ. ForBranchAddress 35891AJ, the Category is E 35892AJ, the Object Class isBank 35893AJ, the Property is Branch Address 35894AJ, theRepresentation/Association is Details 35895AJ, the Type is GDT 35896AJ,the Type Name is Address 35897AJ and the Cardinality between GDT Bank35800AJ and BranchAddress 35891AJ is from zero to n 35898AJ.

The GDT Bank 35800AJ represents the attributes of a bank that identify abank within the requirements of the payment transaction. It is notsuitable for representing the organizational structure of a creditinstitution.

To identify a bank, at least the StandardID, the RoutingID, or theInternalID may be entered, or at least the OrgansiationFormattedName andPhysicalAddress.CityName may be entered in the address.

If the bank is only identified by the InternalID, the RoutingID, or byentering the name and location in the address, the CountryCode may beentered. The CountryCode can be omitted if the StandardID is entered.The RoutingIDTypeCode may be entered if the RoutingID is filled and ifthere are multiple clearing systems in the country of the bank.

(hhhhhhhhhhh) BankAccountBalance

A GDT BankAccountBalance 35800AK is the difference between the relevantdebit and credit turnover for a bank account at a certain point in time.An example of GDT BankAccountBalance 35800AK is: <BankAccountBalance>  <TypeCode>100</TypeCode>  <CreationDateTime>2005-01-01</CreationDateTime>   <AmountcurrencyCode=”EUR”>100.55</Amount> </BankAccountBalance>

The structure of GDT BankAccountBalance 35800AK is depicted in FIG.358AK. For GDT BankAccountBalance 35800AK, the Object Class is BankAccount Balance 35802AK and the Representation/Association is Details35804AK.

GDT BankAccountBalance 35800AK includes an element TypeCode 35806AK. ForTypeCode 35806AK, the Category is Element (E) 35807AK, the Object Classis Bank Account Balance 35808AK, the Property is Type 35810AK, theRepresentation/Association is Code 35812AK, the Type is GDT 35814AK, theType Name is Bank Account Balance type Code 35816AK, and the Cardinalitybetween GDT BankAccountBalance 35800AK and TypeCode 35806AK is from zeroto one 35818AK.

GDT BankAccountBalance 35800AK includes an element CreationDateTime35820AK. For CreationDateTime 35820AK, the Category is Element (E)35821AK, the Object Class is Bank Account Balance 35822AK, the Propertyis DateTime 35824AK, the Representation/Association is DateTime 35826AK,the Type is GDT 35828AK, the Type Name is DateTime 35830AK and theCardinality between GDT BankAccountBalance 35800AK and CreationDateTime35820AK is one 35832AK.

GDT BankAccountBalance 35800AK includes an element Amount 35834AK. ForAmount 35834AK, the Category is Element (E) 35835AK, the Object Class isBank Account Balance 35836AK, the Property is Amount 35838AK, theRepresentation/Association is Amount 35840AK, the Type is GDT 35842AK,the Type Name is Amount 35844AK and the Cardinality between GDTBankAccountBalance 35800AK and Amount 35834AK is one 35846AK.

The GDT BankAccountBalance 35800AK may contain a TypeCode element tospecify the type of bank account balance, a CreationDateTime element tospecify the balance at a certain point in time, and an Amount element tospecify the balance of a bank account.

(iiiiiiiiiii) BankAccountBalanceTypeCode

A GDT BankAccountBalanceTypeCode 35800AL is the coded representation ofa type of bank account balance. Turnover on an account may becategorized according to various criteria. An example of GDTBankAccountBalanceTypeCode 35800AL is:

<BankAccountBalanceTypeCode>100</BankAccountBalanceTypeCode>

The structure of GDT BankAccountBalanceTypeCode 35800AL is depicted inFIG. 358AL. For GDT BankAccountBalanceTypeCode 35800AL, the Object Classis Bank Account Balance 35802AL, the Property is Type 35804AL, theRepresentation/Association is Code 35806AL, the Type is CCT 35808AL, theType Name is Code 35810AL, and the Length is from one to thirty 35812AL.The remark 35814AL shows that GDT BankAccountBalanceTypeCode 35800AL canbe restricted.

GDT BankAccountBalanceTypeCode 35800AL includes an element ListID35816AL. For element ListID 35816AL, the Category is Attribute (A)35818AL, the Object Class is CodeList 35820AL, the Property isIdentification 35822AL, the Representation/Association is Identifier35824AL, the Type is XSD 35826AL, the Type Name is token 35828AL, theLength is from one to sixty 35830AL, and the Cardinality between GDTBankAccountBalanceTypeCode 35800AL and the element ListID 35816BG isfrom zero to one 35832AL.

GDT BankAccountBalanceTypeCode 35800AL includes an element ListVersionID35834AL. For ListVersionID 35834AL, the Category is Attribute (A)35836AL, the Object Class is CodeList 35838AL, the Property is Version35840AL, the Representation/Association is Identifier 35842AL, the Typeis XSD 35844AL, the Type Name is token 35846AL, the Length is from oneto fifteen 35848AL, and the Cardinality between GDTBankAccountBalanceTypeCode 35800AL and the element ListVersionID 35834ALis from zero to one 35850AL.

GDT BankAccountBalanceTypeCode 35800AL includes an element ListAgencyID35852AL. For ListAgencyID 35852AL, the Category is Attribute (A)35854AL, the Object Class is CodeListAgency 35856AL, the Property isIdentification 35858AL, the Representation/Association is Identifier35860AL, the Type is XSD 35862AL, the Type Name is token 35864AL, theLength is from one to sixty 35868AL, and the Cardinality between GDTBankAccountBalanceTypeCode 35800AL and the element ListAgencyID 35852ALis from zero to one 35868AL.

GDT BankAccountBalanceTypeCode 35800AL includes an elementListAgencySchemeID 35870AL. For ListAgencySchemeID 35870AL, the ObjectClass is CodeListAgency 35874AL, the Property is Scheme 35876AL, theRepresentation/Association is Identifier 35878AL, the Type is XSD35880AL, the Type Name is token 35882AL, the Length is from one to sixty35884AL, and the Cardinality between GDT BankAccountBalanceTypeCode35800AL and the element ListAgencySchemeID 35870AL is from zero to one35886AL.

GDT BankAccountBalanceTypeCode 35800AL includes an elementListAgencySchemeAgencyID 35888AL. For ListAgencySchemeAgencyID 35888AL,the Object Class is CodeListAgency 35892AL, the Property is SchemeAgency 35894AL, the Representation/Association is Identifier 35895AL,the Type is XSD 35896AL, the Type Name is token 35897AL, the Length isfrom one to three 35898AL and the Cardinality between GDTBankAccountBalanceTypeCode 35800AL and the elementListAgencySchemeAgencyID 35888AL is from zero to one 35899AL.

A customer can determine the codes in the code list. The attributes ofthe codes can be assigned the following values: listID=“10326,”listAgencyID—ID of the Customer (ID from DE 3055, if listed there),listVersionID—version of the particular code list. Assigned and managedby the Customer, listAgencySchemeID—ID of the scheme if the listAgencyIDdoes not come from DE 3055, and listAgencySchemeAgencyID—ID of theorganization from DE 3055 that manages the listAgencySchemeID scheme Thedata type GDT BankAccountBalanceTypeCode 35800AL may have differenttypes of bank account balance values. For example, a value of 100, 200,3000, or PL02 may indicate a request for the balance of salary deposits,a balance of cash deposits, a notice lock period balance or a balance ofdebit memo deposits, respectively.

(jjjjjjjjjjj) BankAccountDifferentiatorID

A GDT BankAccountDifferentiatorID 35800AM is a unique identifier todifferentiate between bank accounts. An example of GDTBankAccountDifferentiatorID 35800AM is:

<BankAccountDifferentiatorID>USD</BankAccountDifferentiatorID>

The structure of the GDT BankAccountDifferentiatorID 35800AM is depictedin FIG. 358AM. For GDT BankAccountDifferentiatorID 35800AM, the ObjectClass is Bank Account 35802AM, the Property is DifferentiatorIdentification 35804AM, the Representation/Association is Identifier35806AM, the Type is CCT 35808AM, the Type Name is Identifier 35810AM,and the Length is from one to twenty 35812AM. The remark shows that theGDT BankAccountDifferentiatorID 35800AM can be restricted.

The GDT BankAccountDifferentiatorID 35800AM can be used to differentiatebetween bank accounts that are managed under one bank account number.More particularly, the BankAccountDifferentiatorID can be used todifferentiate between bank accounts that are managed under one accountnumber. For example: various terms for time deposits (monthly,quarterly, and annual fixed interest periods) managed under one accountnumber, accounts in different currencies managed under one accountnumber, or various products (checking, deposit, savings, time depositaccount) managed under one account number. The differentiation may beaccomplished by using a different two-digit end number for eachindividual account.

(kkkkkkkkkkk) BankAccountHolderName

A GDT BankAccountHolderName 35800AN is the name of the account holder ofa bank account. The GDT BankAccountHolderName 35800AN contains the nameof the account holder in the form as defined at the bank. TheBankAccountHolderName corresponds to the data elements KOINH_FI andBU_KOINH in SAP ERP. An example of the GDT BankAccountHolderName 35800ANis:

<BankAccountHolderName>Max Mustermann</BankAccountHolderName>

The structure of GDT BankAccountHolderName 35800AN is depicted in FIG.358AN. For GDT BankAccountHolderName 35800AN, the Object Class is BankAccount 35802AN, the Property is Holder 35804AN, theRepresentation/Association is Name 35806AN, the Type is GDT 35808AN, andthe Length is from one to eighty 35812AN. The remark 35814AN shows thatthe GDT BankAccountHolderName 35800AN can be restricted.

The GDT BankAccountHolderName 35800AN contains the name of the accountholder in the form as defined at the bank and may correspond to the dataelements KOINH_F₁, BU_KOINH in SAP ERP.

(lllllllllll) BankAccountID

A GDT BankAccountID 35800AO is the unique identifier assigned to a bankaccount by the account managing bank (i.e., Basic Bank Account Number,BBAN). The BankAccountID corresponds to the data type BNKN35 in SAP ERP.An example of GDT BankAccountID 35800AO is: <BankAccountID>   0078400542</BankAccountID>

The structure of the GDT BankAccountID 35800AO is depicted in FIG.358AO. For GDT BankAccountID 35800AO, the Object Class is BankAccount35802AO, the Property is Identification 35804AO, theRepresentation/Association is Identifier 35806AO, the Type is CCT35808AO, and the Length is from one to thirty-five 35812AO. The remark35814AO shows that the GDT BankAccountID 35800AO can be restricted.

(mmmmmmmmmmm) BankAccountIDCheckDigitValue

A GDT BankAccountIDCheckDigitValue 35800AP is a check digit for a bankaccount number. Check digits are normally numerical. There are someexceptions, for example, Italian bank account numbers may include acheck digit that is alphanumeric. An example of GDTBankAccountIDCheckDigitValue 35800AP is:

<BankAccountIDCheckDigitValue>42</BankAccountIDCheckDigitValue>

The structure of GDT BankAccountIDCheckDigitValue 35800AP is depicted inFIG. 358AP. For GDT BankAccountIDCheckDigitValue 35800AP, the ObjectClass is Bank Account 35802AP, the Property is Identifier Check Digit35804AP, the Representation/Association is Value 35804AP, the Type isXSD 35808AP, the Type Name is String 35810AP, and the Length is from oneto two.

The data type GDT BankAccountIDCheckDigitValue 35800AP can be used todisplay the check digit separate from the bank account number. In someaccount numbers, the check digit is a fixed part of the account number.In this case, GDT BankAccountIDCheckDigitValue 35800AP is not used.

Separate check digits may be stored in the control key (data elementBKONT). In countries which do not use any separate check digits, thecontrol key may be filled with other data.

(nnnnnnnnnnn) BankAccountInternalID

A GDT BankAccountInternalID 35800AQ is a proprietary identifier for abank account. The GDT BankAccountInternalID 35800AQ attributes mayinclude schemeID, such as Bank ID and schemeAgencyID, such as a businesssystem in which the identifier was assigned. An example of GDTBankAccountInternalID 35800AQ is:

<BankAccountInternalIDschemeAgencyID=“VV4_(—)000”>DE_COBA_GIRO_EUR</BankAccountInternalID>

The structure of GDT BankAccountInternalID 35800AQ is depicted in FIG.358AQ. For GDT BankAccountInternalID 35800AQ, the Object Class is BankAccount 35802AQ, the Property Qualifier is Internal 35804AQ, theProperty is Identification 35806AQ, the Representation/Association isIdentifier 35808AQ, the Type is CCT 35810AQ, the Type Name is Identifier35812AQ, and the Length is from one to thirty-two 35814AQ. The remark35816AQ shows that the GDT BankAccountInternalID 35800AQ can berestricted.

The GDT BankAccountInternalID 35800AQ includes an element SchemeAgencyID35818AQ. For SchemeAgencyID 35818AQ, the Category is Attribute (A)35820AQ, the Object Class is Identification Scheme Agency 35822AQ, theProperty Qualifier is Identification 35824AQ, the Property isIdentification 35826AQ, the Representation/Association is Identifier35828AQ, the Type is XSD 35830AQ, the Type Name is token 35832AQ, theLength is from one to sixty 35834AQ, and the Cardinality between GDTBankAccountInternalID 35800AQ and SchemeAgencyID 35818AQ is from zero toone 35836AQ.

The GDT BankAccountInternalID 35800AQ may be used when both sender andrecipient have access to shared master data, for example, duringinternal communication within an enterprise. In an ERP system,BankAccountInternalID contains the key fields BUKRS, HBKID, and HKTID oftable T012K.

(ooooooooooo) BankAccountStandardID

A GDT BankAccountStandardID 35800AR is the International Bank AccountNumber (IBAN), that is, a standardized identifier for a bank account.For example, GDT the BankAccountStandardID 35800AR corresponds to thedata type IBAN in SAP ERP. An example of the GDT BankAccountStandardID35800AR is: <BankAccountStandardID>   DE24200411110078400542</BankAccountStandardID>

The structure of GDT BankAccountStandardID 35800AR is depicted in FIG.358AR. For GDT BankAccountStandardID 35800AR, the object class is BankAccount 35802AR, the Property Qualifier is Standard 35804AR, theProperty is Identification 35806AR, the Representation/Association isIdentifier 35808AR, the Type is CCT 35810AR, the Type Name is Identifier35812AR and the Length is from one to thirty-four 35814AR. The remark35816AR shows that the GDT BankAccountStandardID 35800AR can berestricted.

The attributes of the CCT Identifier may be filled with the followingvalues, which identify the standard ISO 13616: the schemeID is “13616”and the schemeAgencyID is “5.” The BankAccountStandardID corresponds tothe data type IBAN in SAP ERP.

(ppppppppppp) BankAccountTypeCode

A GDT BankAccountTypeCode 35800AS is the coded representation of thetype of a bank account. An example of GDT BankAccountTypeCode 35800ASis:

<BankAccountTypeCode>3</BankAccountTypeCode>

The structure of GDT BankAccountTypeCode 35800AS is depicted in FIG.358AS. For GDT BankAccountTypeCode 35800AS, the Object Class is BankAccount 35801AS, the Property is Type 35804AS, theRepresentation/Association is Code 35806AS, the Type is CCT 35808AS, theType Name is Code 35810AS, and the Length is from one to three. Theremark 35814AS shows that the GDT BankAccountTypeCode 35800AS can berestricted.

The GDT BankAccountTypeCode 35800AS may be used to specify the type of abank account, such as current account, loan account, and savingsaccount. It can also be used for specific business transactions.Typically, one standard code list (ANSI X12 569) is assigned to thecode. The attributes can be assigned values as follows: the listID is“569” and the listAgencyID is “116.”

(qqqqqqqqqqq) BankChargeBearerCode

A GDT BankChargeBearerCode 35800AT is the coded representation of thebearer of the charges of a bank transaction. An example of GDTBankChargeBearerCode 35800AT is:

<BankChargeBearerCode>OUR</BankChargeBearerCode>

The structure of GDT BankChargeBearerCode 35800AT GDT is depicted inFIG. 358AT. For GDT BankChargeBearerCode 35800AT, the Object Class isBank Charge Bearer 35802AT, the Representation/Association is Code35804AT, the Type is CCT 35806AT, the Type Name is Code 35808AT, and theLength is from one to four. The remark 35812AT shows that GDTBankChargeBearerCode 35800AT can be restricted.

The data type GDT BankChargeBearerCode 35800AT may be used to describethe distribution of costs between the initiator and the recipient of apayment transaction. Typically, one fixed standard code list is assignedto the code. The attributes can be assigned values as follows: thelistID is “ChargeBearerCode,” the listAgencyID is “117,” and thelistVersionID is the version of the particular code list. The code listand its values include OUR, BEN and SHA. OUR indicates an Initiatorbears the cost of a payment transaction. BEN indicates a Beneficiarybears the cost of a payment transaction. SHA indicates a sharing ofcosts.

(rrrrrrrrrrr) BankInternalID

A GDT BankInternalID 35800AU is a proprietary identifier for a bank. Forexample, the GDT BankInternalID 35800AU may correspond to the field bankkey (e.g. data element BANKK). An example of GDT BankInternalID 35800AUis:

<BankInternalID schemeAgencyID=“Vv4_(—)000”>COBA</BankInternalID>

The structure of GDT BankInternalID 35800AU is depicted in FIG. 358AU.For GDT BankInternalID 35800AU, the Object Class is Bank 35804AU, theProperty is Internal Identification 35806AU, theRepresentation/Association is Identifier 35808AU, the Type is CCT35810AU, the Type Name is Identifier 35812AU, and the Length is from oneto eighteen 35814AU. The remark 35816AU shows that GDT BankInternalID35800AU can be restricted.

GDT BankInternalID 35800AU includes an element SchemeAgencyID 35818AU.For SchemeAgencyID 35818AU, the Category is Attribute (A) 35820AU, theObject Class is Identification Scheme Agency 35822AU, the Property isIdentification 35824AU, the Representation/Association is Identifier35826AU, the Type is XSD 35828AU, the Type Name is Token 35830AU, theLength is from one to sixty 35832AU, and the Cardinality between GDTBankInternalID 35800AU and SchemeAgencyID 35818AU is from zero to one35834AU.

The data type GDT BankInternalID 35800AU can be used when both senderand recipient have access to shared master data, for example duringinternal communication within an enterprise. In an SAP ERP system,BankInternalID corresponds to the field bank key (e.g. data elementBANKK).

(sssssssssss) BankRoutingID

A GDT BankRoutingID 35800AV identifies a bank by its number in aclearing system. A clearing system is an electronic system with whichthe participating banks eliminate (balance) their non-cash payment flowswith each other and clear receivables and payables. An example of a GDTBankRoutingID 35800AV is:

<BankRoutingID>20041111</BankRoutingID>

The structure of GDT BankRoutingID 35800AV is depicted in FIG. 358AV.For GDT BankRoutingID 35800AV, the Object Class is Bank 35802AV, theProperty is Routing Identification 35804AV, theRepresentation/Association is Identifier 35806AV, the Type is CCT35808AV, The Type Name is Identifier 35810AV, and the Length is from oneto thirty-five 35812AV. The remark 35814AV shows that GDT BankRoutingID35800AV can be restricted.

The data type GDT BankRoutingID 35800AV is the routing number of a bankin a clearing system. For example, a bank number, a sort code, an ABARouting Number or a CHIPS Participant Number. The maximum length and theform of the ID may be dependent on the clearing system. The GDTBankRoutingID 35800AV is unique within one clearing system. In somecountries there is only one (national) clearing system. If this is thecase and the bank country is known from the context, theBankRoutingIDTypeCode may not be entered.

(ttttttttttt) BankRoutingIDTypeCode

A GDT BankRoutingIDTypeCode 35800AW is a coded representation of thetype of a bank number. An example of GDT BankRoutingIDTypeCode 35800AWis:

<BankRoutingIDTypeCode>BL</BankRoutingIDTypeCode>

The structure of GDT BankRoutingIDTypeCode 35800AW is depicted in FIG.358AW. For GDT BankRoutingIDTypeCode 35800AW, the Object Class is BankRouting Identifier 35802AW, the Property is Type 35804AW, theRepresentation/Association is Code 35806AW, the Type is CCT 35808AW, TheType Name is Code 35810AW, and the Length is from one to three 35812AW.The remark 35814AW shows that GDT BankRoutingIDTypeCode 35800AW can berestricted.

The data type GDT BankRoutingIDTypeCode 35800AW may be used to enter thetype of a bank number and thus identify the clearing system implicitly.Each type of a bank number belongs to a different clearing system. Therecan be multiple clearing systems in some countries (for example in theUnited States). To uniquely identify a bank using a bank number, thecountry of the bank may not be sufficient in these cases.

(uuuuuuuuuuu) BankStandardID

A GDT BankStandardID 35800AX is a standardized identifier for a bankaccording to the worldwide identification scheme of the Society ForWorldwide Interbank Financial Telecommunications (S.W.I.F.T.)organization. The GDT BankStandardID 35800AX may correspond to the dataelement SWIFT in SAP ERP. An example of GDT BankStandardID 35800AX is:

<BankStandardID>COBADEHDXXX</BankStandardID>

The structure of GDT BankStandardID 35800AX is depicted in FIG. 358AX.For GDT BankStandardID 35800AX, the Object Class is Bank 35802AX, theProperty Qualifier is Standard 35804AX, the Property is Identification35806AX, the Representation/Association is Identifier 35808AX, the Typeis CCT 35810AX, The Type Name is Identifier 35812AX, and the Length isfrom eight to eleven 35814AX. The remark 35816AX shows that GDTBankStandardID 35800AX can be restricted.

The attributes of the CCT Identifier are implicitly filled with thefollowing values to identify the S.W.I.F.T organization:schemeAgencyID=“17.” The BankStandardID corresponds to the data elementSWIFT in SAP ERP. Permitted values for BankStandardID 35800AX are codesaccording to ISO 9362.

(vvvvvvvvvvv) BlockingReasonCode

A GDT BlockingReasonCode 35800AY is a coded representation for thereason why a processing of a document is blocked. For example, inmessages, GDT BlockingReasonCode 35800AY can be used when both senderand recipient have access to shared or harmonized BusinessConfiguration, such as, during internal communication in an enterprise.An example of GDT BlockingReasonCode 35800AY is:

<BlockingReasonCode>1</BlockingReasonCode>

The structure of GDT BlockingReasonCode 35800AY is depicted in FIG.358AY. For GDT BlockingReasonCode 35800AY, the Object Class is BlockingReason 35802AY, the Representation/Association is Code 35806AY, the Typeis CCT 35808AY, The Type Name is Code 35810AY, and the Length is fromone to two 35812AY. The remark 35814AY shows that GDT BlockingReasonCode35800AY can be restricted.

The data type BlockingReasonCode 35800AY is customer specific. Multiplecode lists are allowed and differentiated by their attributes. The ID ofthe code list may include a billing or delivery listID. The otherattributes listAgencyID, listVersionID, listAgencySchemeID,listAgencySchemeAgencyID are omitted because they would containconstant, customer specific values during runtime.

The GDT BlockingReasonCode 35800AY may be used to state why the documentprocessing is blocked for a particular business partner. It states thatthe processing of document is blocked for the partner for the entirecompany or only for selected sales areas. Examples for the semantics ofthe code list are: In billing scenarios (ListID=‘BILLING’); forCalculation Missing, further processing is blocked due to missingcalculation; for Completion Confirmation Missing, further processing isblocked due to missing completion confirmation; for Prices Incomplete,further processing is blocked due to incomplete prices; for PoliticalReasons, further processing is blocked due to political reasons;, forBottleneck Material, further processing is blocked due to a bottleneckin supply of material.

In messages, GDT BlockingReasonCode 35800AY can be used when both senderand recipient have access to shared or harmonized BusinessConfiguration, for example, during internal communication in anenterprise.

(wwwwwwwwwww) BusinessPartnerBankDetailsID

In the context of the business partner, a GDTBusinessPartnerBankDetailsID 35800AZ unambiguously identifies bankdetails. In addition to specifying an account, the bank details of abusiness partner may also contain administrative information. Thefollowing are examples of administrative information for bank details:the validity of the bank details, additional information for the bankdetails, identification of the bank details in an external system, anindicator showing whether collection authorization has been granted, adescription of the bank details themselves, or information about whethera change to different bank details took place, and if so, when thisoccurred. An example of GDT BusinessPartnerBankDetailsID 35800AZ is:

<BusinessPartnerBankDetailsID>A1W3</BusinessPartnerBankDetailsID>

The structure of GDT BusinessPartnerBankDetailsID 35800AZ is depicted inFIG. 358AZ. For GDT BusinessPartnerBankDetailsID 35800AZ, the ObjectClass is Business Partner Bank Details 35802AZ, the Property isIdentification 35804AZ, the Representation/Association is Identifier35806AZ, the Type is CCT 35808AZ, the Type Name is Identifier 35810AZ,and the Length is from one to four 35812AZ. The remark 35814AZ showsthat GDT BusinessPartnerBankDetailsID 35800AZ can be restricted.

The data type GDT BusinessPartnerBankDetailsID 35800AZ may be used inorder to identify the bank details of a business partner. The dictionaryobject BU_BKVID is assigned to BusinessPartnerBankDetailsID 358000AZ.

(xxxxxxxxxxx) BusinessPartnerCategoryCode

A GDT BusinessPartnerCategoryCode 35800BA is the description, in theform of a code, of a business partner category. A business partnercategory may describe the nature of a business partner and establishesthe category of the business partner. The following categories exist:Natural person, Organization and Business partner group. The categoriesrepresent a classification of business partners that is both completeand disjoint. An example of GDT BusinessPartnerCategoryCode 35800BA is:

<BusinessPartnerCategoryCode>2</BusinessPartnerCategoryCode>

The structure of GDT BusinessPartnerCategoryCode 35800BA is depicted inFIG. 358BA. For GDT BusinessPartnerCategoryCode 35800BA, the ObjectClass is Business Partner 35802BA, the Property is Category 35804BA, theRepresentation/Association is Code 35806BA, the Type is CCT 35808BA, theType Name is Code 35810BA, and the Length is one 35812BA. The remark35814BA shows that GDT BusinessPartnerCategoryCode 35800BA can berestricted.

The data type GDT BusinessPartnerCategoryCode 35800BA may be used todistinguish a business partner as a natural person, an organization or agroup. Depending on the category of the business partner, differentinformation can be stored, or different data can be entered when abusiness partner is created.

The BusinessPartnerCategoryCode is a fixed SAP code list. The followinginstances are possible: 1 (Person)—the business partner is a naturalperson, 2 (Organization)—the business partner is an organization or 3(Group) the business partner is a group of natural persons ororganizations. The attributes have the following values: ListID=“10046,”listAgencyID=“310,” and ListVersionID—version of the relevant code list.

(yyyyyyyyyyy) BusinessPartnerRelationshipCategoryCode

A GDT BusinessPartnerRelationshipCategoryCode 35800BB is thedescription, in the form of a code, of a business partner relationship.A category of a business partner relationship describes the nature ofrelationships between business partners, and establishes the basiccharacteristics for relationships of this category. An example of GDTBusinessPartnerRelationshipCategoryCode 35800BB is:

<BusinessPartnerRelationshipCategoryCode>12WE45</BusinessPartnerRelationshipCategoryCode>

The structure of GDT BusinessPartnerRelationshipCategoryCode 35800BB isdepicted in FIG. 358BB. For GDT BusinessPartnerRelationshipCategoryCode35800BB, the Object Class is Business Partner Relationship 35802BB, theProperty is Category 35804BB, the Representation/Association is Code35806BB, the Type is CCT 35808BB, the Type Name is Code 35810BB, and theLength is from one to six 35812BB. The remark 35814BB shows that GDTBusinessPartnerRelationshipCategoryCode 35800BB can be restricted.

GDT BusinessPartnerRelationshipCategoryCode 35800BB includes an elementListID 35816BB. For element ListID 35816BB, the Category is Attribute(A) 35818BB, the Object Class is CodeList 35820BB, the Property isIdentification 35822BB, the Representation/Association is Identifier35824BB, the Type is XSD 35826BB, the Type Name is token 35828BB, andthe Cardinality between GDT BusinessPartnerRelationshipCategoryCode35800BB and the element ListID 35816BB is from zero to one 35830BB.

GDT BusinessPartnerRelationshipCategoryCode 35800BB includes an elementListAgencyID 35832BB. For ListAgencyID 35832BB, the Category isAttribute (A) 35834BB, the Object Class is CodeListAgency 35836BB, theProperty is Identification 35838BB, the Representation/Association isIdentifier 35840BB, the Type is XSD 35842BB, the Type Name is token35844BB, and the Cardinality between GDTBusinessPartnerRelationshipCategoryCode 35800BB and the elementListAgencyID 35832BB is from zero to one 35846BB.

GDT BusinessPartnerRelationshipCategoryCode 35800BB includes an elementListVersionID 35848BB. For ListVersionID 35848BB, the Category isAttribute (A) 35850BB, the Object Class is CodeList 35852BB, theProperty is Version 35854BB, the Representation/Association isIdentifier 35856BB, the Type is XSD 35858BB, the Type Name is token35860BB, and the Cardinality between GDTBusinessPartnerRelationshipCategoryCode 35800BB and the elementListVersionID 35848BB is from zero to one 35862BB.

GDT BusinessPartnerRelationshipCategoryCode 35800BB includes an elementListAgencySchemeID 35864BB. For ListAgencySchemeID 35864BB, the Categoryis Attribute (A) 35866BB, the Object Class is CodeListAgency 35868BB,the Property is Scheme 35870BB, the Representation/Association isIdentifier 35872BB, the Type is XSD 35874BB, the Type Name is token35876BB, and the Cardinality between GDTBusinessPartnerRelationshipCategoryCode 35800BB and the elementListAgencySchemeID 35864BB is from zero to one 35878BB.

GDT BusinessPartnerRelationshipCategoryCode 35800BB includes an elementListAgencySchemeAgencyID 35880BB. For ListAgencySchemeAgencyID 35880BB,the Category is Attribute (A) 35882BB, the Object Class isCodeListAgency 35884BB, the Property is Scheme Agency 35886BB, theRepresentation/Association is Identifier 35888BB, the Type is XSD35890BB, the Type Name is token 35892BB, and the Cardinality between GDTBusinessPartnerRelationshipCategoryCode 35800BB and the elementListAgencySchemeAgencyID 35880BB is from zero to one 35894BB.

The data type GDT BusinessPartnerRelationshipCategoryCode 35800BB may beused in scenarios where a business partner A is a contact person of abusiness partner B, or in scenarios where a business partner A is ashareholder of a business partner B.

There are alternative code lists that differ at configuration and/orruntime. SAP delivers the following code list for the GDT: Code NameDescription BUR001 Contact Person Relationship Business partner A hasbusiness partner B as contact person BUR002 Activity partnerrelationship Business partner A has business partner B as activitypartner BUR003 Shared living arrangement relationship A shared livingarrangement (business partner A) has business partner B as a member.BUR004 Marriage relationship Business partner A is married to businesspartner B BUR006 Alias (identity) relationship Business partner A isidentical to business partner B BUR010 Employee relationship Anorganization (business partner A) has business partner B as an employee.BUR011 Employee responsible relationship An organization (businesspartner A) has business partner B as the employee responsible. BUR013Replacement relationship Business partner A is replaced by businesspartner B BUR020 Department relationship Business partner A has businesspartner B as a department BUR021 Parent-child relationship Businesspartner A has business partner B as a child BUR022 Guardian relationshipBusiness partner A is the guardian of business partner B BUR023 Relativerelationship Business partner A is related to business partner B BUR024Marriage partnership relationship Business partner B is a member of themarriage partnership (business partner A) BURC01 ShareholderRelationship Business partner A is a shareholder of business partner B

(zzzzzzzzzzz) BusinessTransactionDocumentBankAccount

A GDT BusinessTransactionDocumentBankAccount 35800BC contains theinformation exchanged in business documents about a bank accountinvolved in business transactions. A bank account may record acustomer's bank transactions. An example of GDTBusinessTransactionDocumentBankAccount 35800BC is:<BusinessTransactionDocumentBankAccount>   <ID>0078400542</ID>  <CurrencyCode>EUR</CurrencyCode>   <HolderName>MaxMustermann</HolderName>   <Bank>    <StandardID>COBADEHDXXX</StandardID>    <RoutingID>20041111</RoutingID>     <RoutingIDTypeCode>BL</RoutingIDTypeCode>     <CountryCode>DE<CountryCode>   </Bank></BusinessTransactionDocumentBankAccount>

The structure of GDT BusinessTransactionDocumentBankAccount 35800BC isdepicted in FIG. 358BC. For GDT BusinessTransactionDocumentBankAccount35800BC the Object Class is Business Transaction Document Bank Account35802BC and the Representation/Association is Details 35804BC.

GDT BusinessTransactionDocumentBankAccount 35800BC includes an elementID 35806BC. For ID 35806BC, the Category is Element (E) 35808BC, theObject Class is Business Transaction Document Bank Account 35810BC, theProperty is Identification 35812BC, the Representation/Association isIdentifier 35814BC, the Type is GDT 35816BC, the Type Name isBankAccountID 35818BC, and the Cardinality between GDT BusinessTransaction Document Bank Account 35802BC and ID 35806BC is from zero toone 35820BC.

GDT BusinessTransactionDocumentBankAccount 35800BC includes an elementID Check Digit Value 35822BC. For ID Check Digit Value 35822BC, theCategory is Element (E) 35824BC, the Object Class is BusinessTransaction Document Bank Account 35826BC, the Property is IDCheckDigit35828BC, the Representation/Association is Value 35830BC, the Type isGDT 35832BC, the Type Name is BankAccountIDCheckDigitValue 35834BC, andthe Cardinality between GDT Business Transaction Document Bank Account35802BC and ID Check Digit Value 35822BC is from zero to one 35836BC.

GDT BusinessTransactionDocumentBankAccount 35800BC includes an elementInternal ID 35838BC. For Internal ID 35838BC, the Category is Element(E) 35840BC, the Object Class is Business Transaction Document BankAccount 35842BC, the Property is Internal Identification 35844BC, theRepresentation/Association is Identifier 35846BC, the Type is GDT35848BC, the Type Name is BankAccountInternalID 35850BC, and theCardinality between GDT Business Transaction Document Bank Account35802BC and Internal ID 35838BC is from zero to one 35852BC.

GDT BusinessTransactionDocumentBankAccount 35800BC includes an elementStandard ID 35854BC. For Standard ID 35854BC, the Category is Element(E) 35856BC, the Object Class is Business Transaction Document BankAccount 35858BC, the Property is Standard Identification 35860BC, theRepresentation/Association is Identifier 35862BC, the Type is GDT35864BC, the Type Name is BankAccountStandardID 35866BC, and theCardinality between GDT Business Transaction Document Bank Account35802BC and Standard ID 35854BC is from zero to one 35868BC.

GDT BusinessTransactionDocumentBankAccount 35800BC includes an elementType Code 35870BC. For Type Code 35870BC, the Category is Element (E)35872BC, the Object Class is Business Transaction Document Bank Account35874BC, the Property is Type 35876BC, the Representation/Association isCode 35878BC, the Type is GDT 35880BC, the Type Name isBankAccountTypeCode 35881BC, and the Cardinality between GDT BusinessTransaction Document Bank Account 35802BC and Type Code 35870BC is fromzero to one 35882BC.

(aaaaaaaaaaaa) CentralBankReportItem

A GDT CentralBankReportItem 35800BD is a single report to the centralbank during a foreign payment. An example of GDT CentralBankReportItem35800BD is: <CentralBankReportItem>  <ReportingCountryCode>DE</CountryCode>  <SupplyingCountryCode >US</VendorCountryCode>   <AmountcurrencyCode=“USD”>2500.00</ Amount>  <ReasonClassificationCode>2</ClassificationCode>  <ReasonCode>520</Code>   <ReasonDescription> Repay for independentwork </Description> </CentralBankReportItem>

The structure of GDT CentralBankReportItem 35800BD is depicted in FIG.358BD. For GDT CentralBankReportItem 35800BD the Object Class is CentralBank Report Item 35802BD and the Representation/Association is Details35804BD.

GDT CentralBankReportItem 35800BD includes an elementReportingCountryCode 35806BD. For ReportingCountryCode 35806BD, theObject Class is Central Bank Report Item 35810BD, the Property isReporting Country 35812BD, the Representation/Association is Code35814BD, the Type is GDT 35816BD, the Type Name is CountryCode 35818BD,and the Cardinality between GDT CentralBankReportItem 35800BD andReportingCountryCode 35806BD is one 35820BD.

GDT CentralBankReportItem 35800BD includes an elementSupplyingCountryCode 35822BD. For SupplyingCountryCode 35822BD, theObject Class is Central Bank Report Item 35826BD, the Property isSupplying Country 35828BD, the Representation/Association is Code35830BD, the Type is GDT 35832BD, the Type Name is CountryCode 35834BD,and the Cardinality between GDT CentralBankReportItem 35800BD andSupplyingCountryCode 35822BD is from zero to one 35836BD.

GDT CentralBankReportItem 35800BD includes an element Amount 35838BD.For Amount 35838BD, the Object Class is Central Bank Report Item35842BD, the Property is Amount 35844BD, the Representation/Associationis Amount 35846BD, the Type is GDT 35848BD, the Type Name is Amount35850BD, and the Cardinality between GDT CentralBankReportItem 35800BDand Amount 35838BD is one 35852BD.

GDT CentralBankReportItem 35800BD includes an element ReasonClassification Code 35854BD. For Reason Classification Code 35854BD, theObject Class is Central Bank Report Item 35858BD, the Property is ReasonClassification 35860BD, the Representation/Association is Code 35862BD,the Type is GDT 35864BD, the Type Name is Central Bank Report ReasonClassification Code 35866BD, and the Cardinality between GDTCentralBankReportItem 35800BD and Reason Classification Code 35854BD isfrom zero to one 35868BD.

GDT CentralBankReportItem 35800BD includes an element ReasonCode35870BD. For ReasonCode 35870BD, the Object Class is Central Bank ReportItem 35874BD, the Property is Reason 35876BD, theRepresentation/Association is Code 35878BD, the Type is GDT 35880BD, theType Name is Central Bank Report Reason Code 35881BD, and theCardinality between GDT CentralBankReportItem 35800BD and ReasonCode35870BD is from zero to one 35882BD.

GDT CentralBankReportItem 35800BD includes an element Reason Description35889BD. For Reason Description 35889BD, the Object Class is CentralBank Report Item 35890BD, the Property is Reason 35891BD, theRepresentation/Association is Description 35892BD, the Type is GDT35893BD, the Type Name is Description 35894BD, and the Cardinalitybetween GDT CentralBankReportItem 35800BD and Reason Description 35889BDis from zero to one 35895BD.

These integrity conditions are valid in the following countries:Germany: ReasonClassificationCode and ReasonCode may be specified,Japan: Only ReasonCode is specified, and Netherlands: OnlyReasonClassificationCode is specified

(bbbbbbbbbbbb) CentralBankReportReasonClassificationCode

A GDT CentralBankReportReasonClassificationCode 35800BE is the codedrepresentation of the classification of reasons for a report to thestate central bank (i.e., reasons for notification). An example of GDTCentralBankReportReasonClassificationCode 35800BE is:

<CentralBankReportReasonClassificationCode>2</CentralBankReportReasonClassificationCode>

The structure of GDT CentralBankReportReasonClassificationCode 35800BEis depicted in FIG. 358BE. For GDTCentralBankReportReasonClassificationCode 35800BE, the Object Class isCentral Bank Report Reason 35802BE, the Property is Classification35804BE, the Representation/Association is Code 35806BE, the Type is CCT35808BE, the Type Name is Code 35810BE, and the Length is one 35812BE.The remark 35814BE shows that GDTCentralBankReportReasonClassificationCode 35800BE can be restricted.

The GDT CentralBankReportReasonClassificationCode 35800BE may be used inCentralBankReportItem. The country of the code list is the reportingcountry (CentralBankReportItem.CountryCode).

In foreign payment transactions in Germany, theCentralBankReportReasonClassificationCode is specified using thedocument type. In the data medium exchange (format DTAZV), the documenttype is transferred in field W3, the values 2 and 4 are possible. Thedocument type is also used during the crea-tion of the Z4 form. The codelist includes the following values: Code Description 1 Services,transfers for incoming payment 2 Services, transfers for outgoingpayment 3 Capital transactions, income on investment for incomingpayment 4 Capital transactions, income on investment for outgoingpayment 5 Transit trade for incoming payment 6 Transit trade foroutgoing payment

CentralBankReportReasonCode

A GDT CentralBankReportReasonCode 35800BF is the coded representation ofthe reason for a report to the state central bank (i.e., reasons fornotification). Several fixed, country-specific code lists, which aredifferent at runtime, may be assigned to the code. An example of GDTCentralBankReportReasonCode 35800BF is:

<CentralBankReportReasonCodeschemeAgencyID=“DE”>520</CentralBankReportReasonCode>

The structure of GDT CentralBankReportReasonCode 35800BF is depicted inFIG. 358BF. For GDT CentralBankReportReasonCode 35800BF, the ObjectClass is Central Bank Report 35802BF, the Property is Reason 35804BF,the Representation/Association is Code 35806BF, the Type is CCT 35808BF,the Type Name is Code 35810BF, and the Length is from one to three35812BF. The remark 35814BF shows that GDT CentralBankReportReasonCode35800BF can be restricted.

The data type GDT CentralBankReportReasonCode 35800BF may be used inCentralBankReportItem. The country of the code list is the reportingcountry (CentralBankReportItem.CountryCode).

The attributes in the code list for CentralBankReportReasonCode 35800BFare: listID=“22001,” listAgencyID=nn, listVersionID=[version of the codelist. Assigned by the standardization organization (if available)],listAgencySchemeID=[Scheme used to assign the listAgencyID (for exampleEAN, DUNS)], listAgencySchemeAgencyID=[Organization according to DE 3055that manages the scheme].

(cccccccccccc) CommissionProductGroupCode

A GDT CommissionProductGroupCode 35800BG is the coded representation ofa group of products for which a certain commission is granted. Anexample of GDT CommissionProductGroupCode 35800BG is:

<CommissionProductGroupCode>1</CommissionProductGroupCode>

The structure of GDT CommissionProductGroupCode 35800BG is depicted inFIG. 358BG. For GDT CommissionProductGroupCode 35800BG, the Object ClassQualifier is Commission 35802BG, the Object Class is Product Group35804BG, the Representation/Association is Code 35806BG, the Type is CCT35808BG, the Type Name is Code 35810BG, and the Length is from one totwo 35812BG.

GDT CommissionProductGroupCode 35800BG includes an element ListID35816BG. For element ListID 35816BG, the Category is Attribute (A)35818BG, the Object Class is CodeList 35820BG, the Property isIdentification 35822BG, the Representation/Association is Identifier35824BG, the Type is XSD 35826BG, the Type Name is token 35828BG, andthe Cardinality between GDT CommissionProductGroupCode 35800BG and theelement ListID 35816BG is from zero to one 35830BG.

GDT CommissionProductGroupCode 35800BG includes an element ListAgencyID35832BG. For ListAgencyID 35832BG, the Category is Attribute (A)35834BG, the Object Class is CodeListAgency 35836BG, the Property isIdentification 35838BG, the Representation/Association is Identifier35840BG, the Type is XSD 35842BG, the Type Name is token 35844BG, andthe Cardinality between GDT CommissionProductGroupCode 35800BG and theelement ListAgencyID 35832BG is from zero to one 35846BG.

GDT CommissionProductGroupCode 35800BG includes an element ListVersionID35848BG. For ListVersionID 35848BG, the Category is Attribute (A)35850BG, the Object Class is CodeList 35852BG, the Property is Version35854BG, the Representation/Association is Identifier 35856BG, the Typeis XSD 35858BG, the Type Name is token 35860BG, and the Cardinalitybetween GDT CommissionProductGroupCode 35800BG and the elementListVersionID 35848BG is from zero to one 35862BG.

GDT CommissionProductGroupCode 35800BG includes an elementListAgencySchemeID 35864BG. For ListAgencySchemeID 35864BG, the Categoryis Attribute (A) 35866BG, the Object Class is CodeListAgency 35868BG,the Property is Scheme 35870BG, the Representation/Association isIdentifier 35872BG, the Type is XSD 35874BG, the Type Name is token35876BG, and the Cardinality between GDT CommissionProductGroupCode35800BG and the element ListAgencySchemeID 35864BG is from zero to one35878BG.

GDT CommissionProductGroupCode 35800BG includes an elementListAgencySchemeAgencyID 35880BG. For ListAgencySchemeAgencyID 35880BG,the Category is Attribute (A) 35882BG, the Object Class isCodeListAgency 35884BG, the Property is Scheme Agency 35886BG, theRepresentation/Association is Identifier 35888BG, the Type is XSD35890BG, the Type Name is token 35892BG, and the Cardinality between GDTCommissionProductGroupCode 35800BG and the elementListAgencySchemeAgencyID 35880BG is from zero to one 35894BG.

A customer can determine the codes in the code list. The attributes ofthe code are assigned the following values: listID=“10331,”listAgencyID—ID of the Customer (ID from DE 3055, if listed there),listVersionID—version of the particular code list. Assigned and managedby the Customer, listAgencySchemeID—ID of the scheme if the listAgencyIDdoes not come from DE 3055, and listAgencySchemeAgencyID—ID of theorganization from DE 3055 that manages the listAgencySchemeID scheme.

The data type GDT CommissionProductGroupCode 35800BG may be used forprice determination and analysis in sales and billing documents.Examples of the possible semantics of the codes are products for whichthe maximum commission applies or products for which the minimumcommission applies. The CommissionProductGroupCode may currently be usedin business objects and A2A messages. The following dictionary objectscan be assigned to CommissionProductGroupCode 35800BG: Data element:CRMT_PROD_PR_GROUP, Domain: CRM_COMM_GROUP.

(dddddddddddd) CommunicationMediumTypeCode

A GDT CommunicationMediumTypeCode 35800BH is the coded representation ofthe type of a medium used for communication. An example of GDTCommunicationMediumTypeCode 35800BH is:

<CommunicationMediumTypeCode>MA</CommunicationMediumTypeCode>

The structure of GDT CommunicationMediumTypeCode 35800BH is depicted inFIG. 358BH. For GDT CommunicationMediumTypeCode 35800BH, the Property isCommunication Medium Type 35802BH, the Representation/Association isCode 35804BH, the Type is CCT 35806BH, the Type Name is Code 35808BH,and the Length is from one to two 35810BH. The remark 35812BH shows thatGDT CommunicationMediumTypeCode 35800BH can be restricted.

GDT CommunicationMediumTypeCode 35800BH includes an element ListID35814BH. For element ListID 35814BH, the Category is Attribute (A)35816BH, the Object Class is CodeList 35818BH, the Property isIdentification 35820BH, the Representation/Association is Identifier35822BH, the Type is XSD 35824BH, the Type Name is token 35826BH, andthe Cardinality between GDT CommunicationMediumTypeCode 35800BH and theelement ListID 35814BH is from zero to one 35828BH.

GDT CommunicationMediumTypeCode 35800BH includes an element ListAgencyID35830BH. For ListAgencyID 35830BH, the Category is Attribute (A)35832BH, the Object Class is CodeListAgency 35834BH, the Property isIdentification 35836BH, the Representation/Association is Identifier35838BH, the Type is XSD 35840BH, the Type Name is token 35842BH, andthe Cardinality between GDT CommunicationMediumTypeCode 35800BH and theelement ListAgencyID 35830BH is from zero to one 35844BH.

GDT CommunicationMediumTypeCode 35800BH includes an elementListVersionID 35846BH. For ListVersionID 35846BH, the Category isAttribute (A) 35848BH, the Object Class is CodeList 35850BH, theProperty is Version 35852BH, the Representation/Association isIdentifier 35854BH, the Type is XSD 35856BH, the Type Name is token35858BH, and the Cardinality between GDT CommunicationMediumTypeCode35800BH and the element ListVersionID 35846BH is from zero to one35860BH.

In the system configuration, GDT CommunicationMediumTypeCode 35800BH maybe used to control which medium will be used for which purpose. Forinstance, a dunning schema might lay down that a letter may be used forlegally effective dunning while email is appropriate for a merereminder. In an overview of a dispute history GDTCommunicationMediumTypeCode 35800BH may show which media were used inall the communication steps. In the address maintenancePreferredCommunicationMediumTypeCode can be used to describe with whichmedia an addressee or business partner wants to be contacted. In theprocurement processSupplierProcurementDocumentExchangeCommunicationMediumTypeCode can beused to describe which medium can be used to exchange business documentsbetween the supplier and the purchasing company or its purchasing units.

(eeeeeeeeeeee) ContactAllowedCode

A GDT ContactAllowedCode 35800BI is the coded description of contactpermission. The GDT ContactAllowedCode 35800BI is a code list implicitlygiven attributes listID=“10050”, listAgencyID=“310” and a listVersionID.The following instances may be possible: 1 (contact is allowed), 2(contact is not allowed), or 3 (check whether contact is allowed). Anexample of GDT ContactAllowedCode 35800BI is:

<ContactAllowedCode>1</ContactAllowedCode>

The structure of GDT ContactAllowedCode 35800BI is depicted in FIG.358BI. For GDT ContactAllowedCode 35800BI, the Property is contactallowed 35802BI, the Representation/Association is Code 35804BI, theType is CCT 35806BI, the Type Name is Code 35808BI, and the Length isone 35810BI. The remark 35812BI shows that GDT ContactAllowedCode35800BI can be restricted.

The GDT ContactAllowedCode 35800BI may be used to confirm whethercontact with a particular person or company is allowed or not.

(ffffffffffff) ContactPersonFunctionTypeCode

A GDT ContactPersonFunctionTypeCode 35800BJ represents, in the form of acode, the type of function that a contact person has. This may refer tothe functions within the organization where the contact person isemployed. An example of GDT ContactPersonFunctionTypeCode 35800BJ is:

<ContactPersonFunctionTypeCode>1</ContactPersonFunctionTypeCode>

The structure of GDT ContactPersonFunctionTypeCode 35800BJ is depictedin FIG. 358BJ. For GDT ContactPersonFunctionTypeCode 35800BJ, the ObjectClass is Contact Person 35802BJ, the Property is Function Type 35804BJ,the Representation/Association is Code 35806BJ, the Type is CCT 35808BJ,the Type Name is Code 35810BJ, and the Length is from one to four35812BJ. The remark 35814BJ shows that GDT ContactPersonFunctionTypeCode35800BJ can be restricted.

GDT ContactPersonFunctionTypeCode 35800BJ includes an element ListID35816BJ. For element ListID 35816BJ, the Category is Attribute (A)35818BJ, the Object Class is CodeList 35820BJ, the Property isIdentification 35822BJ, the Representation/Association is Identifier35824BF, the Type is XSD 35826BJ, the Type Name is token 35828BJ, andthe Cardinality between GDT CentralBankReportReasonCode 35800BF and theelement ListID 35816BJ is from zero to one 35830BJ.

GDT ContactPersonFunctionTypeCode 35800BJ includes an elementListAgencyID 35832BJ. For ListAgencyID 35832BJ, the Category isAttribute (A) 35834BJ, the Object Class is CodeListAgency 35836BJ, theProperty is Identification 35838BJ, the Representation/Association isIdentifier 35840BF, the Type is XSD 35842BJ, the Type Name is token35844BJ, and the Cardinality between GDT CentralBankReportReasonCode35800BF and the element ListAgencyID 35832BJ is from zero to one35846BJ.

GDT ContactPersonFunctionTypeCode 35800BJ includes an elementListVersionID 35848BJ. For ListVersionID 35848BJ, the Category isAttribute (A) 35850BJ, the Object Class is CodeList 35852BJ, theProperty is Version 35854BJ, the Representation/Association isIdentifier 35856BF, the Type is XSD 35858BJ, the Type Name is token35860BJ, and the Cardinality between GDT CentralBankReportReasonCode35800BF and the element ListVersionID 35848BJ is from zero to one35862BJ.

GDT ContactPersonFunctionTypeCode 35800BJ includes an elementListAgencySchemeID 35864BJ. For ListAgencySchemeID 35864BJ, the Categoryis Attribute (A) 35866BJ, the Object Class is CodeListAgency 35868BJ,the Property is Scheme 35870BJ, the Representation/Association isIdentifier 35872BF, the Type is XSD 35874BJ, the Type Name is token35876BJ, and the Cardinality between GDT CentralBankReportReasonCode35800BF and the element ListAgencySchemeID 35864BJ is from zero to one35878BJ.

GDT ContactPersonFunctionTypeCode 35800BJ includes an elementListAgencySchemeAgencyID 35880BJ. For ListAgencySchemeAgencyID 35880BJ,the Category is Attribute (A) 35882BJ, the Object Class isCodeListAgency 35884BJ, the Property is Scheme Agency 35886BJ, theRepresentation/Association is Identifier 35888BF, the Type is XSD35890BJ, the Type Name is token 35892BJ, and the Cardinality between GDTCentralBankReportReasonCode 35800BF and the elementListAgencySchemeAgencyID 35880BJ is from zero to one 35894BJ.

A customer-specific code list may be assigned to the code. Theattributes of the code are assigned the following values: the listID is“10333,” the listAgencyID is the ID of the Customer (ID from DE 3055, iflisted there), the listVersionID is the version of the particular codelist, the listAgencySchemeID is the ID of the scheme if the listAgencyIDdoes not come from DE 3055, the listAgencySchemeAgencyID is the ID ofthe organization from DE 3055 that manages the listAgencySchemeIDscheme. For example, the contact person may be a member of executiveboard or the purchasing manager.

(gggggggggggg) CorrespondenceBankTypeCode

A GDT CorrespondenceBankTypeCode 35800BK is the coded representation ofthe type of a correspondence bank. A correspondence bank is a bank(typically abroad) to which a bank has a business relationship.Correspondence banks are involved in particular in foreign trade, forexample, when processing payment transactions, cashing foreignsecurities, and trading with foreign notes and coins. An example of GDTCorrespondenceBankTypeCode 35800BK is

CorrespondenceBankTypeCode>1</CorrespondenceBankTypeCode>

The structure of GDT CorrespondenceBankTypeCode 35800BK is depicted inFIG. 358BK. For GDT CorrespondenceBankTypeCode 35800BK, the Object Classis Correspondence Bank 35802BK, the Property is Type 35804BK, theRepresentation/Association is Code 35806BK, the Type is CCT 35808BK, theType Name is Code 35810BK, and the Length is one 35812BK. The remark35814BK shows that GDT CorrespondenceBankTypeCode 35800BK can berestricted.

The GDT CorrespondenceBankTypeCode 35800BK is a code list that may havethe following values: 1 (correspondence bank of the payer bank), 2(intermediary bank or a correspondence bank between 1 Sender and 3Recipient), or 3 (correspondence bank of the recipient bank).

The data type GDT CorrespondenceBankTypeCode 35800BK may be used, forexample, to specify the type of a correspondence bank during a paymentorder with a foreign payee.

(hhhhhhhhhhhh) CostCentreTypeCode

A GDT CostCentreTypeCode 35800BL is the coded representation of thenature of a cost center. An example of GDT CostCentreTypeCode 35800BLis:

<CostCentreTypeCode>1</CostCentreTypeCode>

The structure of GDT CostCentreTypeCode 35800BL is depicted in FIG.358BL. For GDT CostCentreTypeCode 35800BL, the Object Class is CostCenter 35802BL, the Property is Type 35804BL, theRepresentation/Association is Code 35806BL, the Type is CCT 35808BL, theType Name is Code 35810BL, and the Length is from one to four 35812BL.The remark 35814BL shows that GDT CostCentreTypeCode 35800BL can berestricted.

The data type GDT CostCentreTypeCode 35800BL may make it possible todefine sets of cost centers on the basis of the value of theCostCentreTypeCode. Reference can then be made to these sets in theassessment, overhead costing, or settlement. Examples of possible codesemantics include: the cost center having type “Production,” the costcenter having type “Personnel,” and the cost center having type“Administration.” A customer can determine the codes in the code list.The attributes of the code are assigned the following values:listID=“10334,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list.Assigned and managed by the Customer, listAgencySchemeID—ID of thescheme if the listAgencyID does not come from DE 3055, andlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme.

(iiiiiiiiiiii) CreditAgencyReportTypeCode

A GDT CreditAgencyReportTypeCode 35800BM is the coded display of thetype of credit information by source and scope. Credit information isinformation about the creditworthiness of a party provided by a creditagency. An example of GDT CreditAgencyReportTypeCode 35800BM is:

<CreditAgencyReportTypeCode>2</CreditAgencyReportTypeCode>

The structure of GDT CreditAgencyReportTypeCode 35800BM is depicted inFIG. 358BM. For GDT CreditAgencyReportTypeCode 35800BM, the Object Classis Credit Agency Report 35802BM, the Property is Type 35804BM, theRepresentation/Association is Code 35806BM, the Type is CCT 35808BM, theType Name is Code 35810BM, and the Length is two 35812BM. The remark35814BM shows that GDT CreditAgencyReportTypeCode 35800BM can berestricted.

GDT CreditAgencyReportTypeCode 35800BM includes an element ListAgencyID35816BM. For element ListAgencyID 35816BM, the Category is Attribute (A)35818BM, the Object Class is CodeListAgency 35820BM, the Property isIdentification 35822BM, the Representation/Association is Identifier35824BM, the Type is XSD 35826BM, the Type Name is token 35828BM, andthe Cardinality between GDT CreditAgencyReportTypeCode 35800BM and theelement ListAgencyID 35816BM is from zero to one 35830BM.

GDT CreditAgencyReportTypeCode 35800BM includes an element ListVersionID35832BM. For ListVersionID 35832BM, the Category is Attribute (A)35834BM, the Object Class is CodeList 35836BM, the Property is Version35838BM, the Representation/Association is Identifier 35840BM, the Typeis XSD 35842BM, the Type Name is token 35844BM, and the Cardinalitybetween GDT CreditAgencyReportTypeCode 35800BM and the elementListVersionID 35832BM is from zero to one 35846BM.

GDT CreditAgencyReportTypeCode 35800BM includes an elementListAgencySchemeID 35848BM. For ListAgencySchemeID 35848BM, the Categoryis Attribute (A) 35850BM, the Object Class is CodeListAgency 35852BM,the Property is Scheme 35854BM, the Representation/Association isIdentifier 35856BM, the Type is XSD 35858BM, the Type Name is token35860BM, and the Cardinality between GDT CreditAgencyReportTypeCode35800BM and the element ListAgencySchemeID 35848BM is from zero to one35862BM.

GDT CreditAgencyReportTypeCode 35800BM includes an elementListAgencySchemeAgencyID 35864BM. For ListAgencySchemeAgencyID 35864BM,the Category is Attribute (A) 35866BM, the Object Class isCodeListAgency 35868BM, the Property is Scheme Agency 35870BM, theRepresentation/Association is Identifier 35872BM, the Type is XSD35874BM, the Type Name is token 35876BM, and the Cardinality between GDTCreditAgencyReportTypeCode 35800BM and the elementListAgencySchemeAgencyID 35864BM is from zero to one 35878BM.

The data type GDT CreditAgencyReportTypeCode 35800BM may be used in thebusiness object CreditAgencyReport where it may sort credit informationby source and scope.

(jjjjjjjjjjjj) AddressUsageTypeCode

A GDT AddressUsageTypeCode 35800BN is the coded representation of theusage of an address. An example of GDT AddressUsageTypeCode 35800BN is:

<AddressUsageTypeCode>XXDEFAULT</AddressUsageTypeCode>

The structure of GDT AddressUsageTypeCode 35800BN is depicted in FIG.358BN. For GDT AddressUsageTypeCode 35800BN, the Object Class is Address35802BN, the Property Qualifier is Usage 35804BN, the Property is Type35806BN, the Representation/Association is Code 35808BN, the Type is CCT35810BN, the Type Name is Code 35812BN, and the Length is from one toten 35814BN. The remark 35815BN shows that GDT AddressUsageTypeCode35800BN can be restricted.

GDT AddressUsageTypeCode 35800BN includes an element ListAgencyID35816BN. For element ListAgencyID 35816BN, the Category is Attribute (A)35818BN, the Object Class is CodeListAgency 35820BN, the Property isIdentification 35822BN, the Representation/Association is Identifier35824BN, the Type is XSD 35826BN, the Type Name is token 35828BN, andthe Cardinality between GDT AddressUsageTypeCode 35800BN and the elementListAgencyID 35816BN is from zero to one 35830BN.

GDT AddressUsageTypeCode 35800BN includes an element ListVersionID35832BN. For ListVersionID 35832BN, the Category is Attribute (A)35834BN, the Object Class is CodeList 35836BN, the Property is Version35838BN, the Representation/Association is Identifier 35840BN, the Typeis XSD 35842BN, the Type Name is token 35844BN, and the Cardinalitybetween GDT AddressUsageTypeCode 35800BN and the element ListVersionID35832BN is from zero to one 35846BN.

GDT AddressUsageTypeCode 35800BN includes an element ListAgencySchemeID35848BN. For ListAgencySchemeID 35848BN, the Category is Attribute (A)35850BN, the Object Class is CodeListAgency 35852BN, the Property isScheme 35854BN, the Representation/Association is Identifier 35856BN,the Type is XSD 35858BN, the Type Name is token 35860BN, and theCardinality between GDT AddressUsageTypeCode 35800BN and the elementListAgencySchemeID 35848BN is from zero to one 35862BN.

GDT AddressUsageTypeCode 35800BN includes an elementListAgencySchemeAgencyID 35864BN. For ListAgencySchemeAgencyID 35864BN,the Category is Attribute (A) 35866BN, the Object Class isCodeListAgency 35868BN, the Property is Scheme Agency 35870BN, theRepresentation/Association is Identifier 35872BN, the Type is XSD35874BN, the Type Name is token 35876BN, and the Cardinality between GDTAddressUsageTypeCode 35800BN and the element ListAgencySchemeAgencyID35864BN is from zero to one 35878BN.

The data type GDT AddressUsageTypeCode 35800BN can, for example, be usedto record that an address of a business partner is suitable as adelivery address, such as an invoice address or a correspondenceaddress.

(kkkkkkkkkkkk) ActivityInitiatorCode

A GDT ActivityInitiatorCode 35800BO is the coded representation of theinitiator of the activity. It specifies, if the activity was triggeredinternally or externally. For example the activity could be accepting aphone call, or sending an e-mail. An example of GDTActivityInitiatorCode 35800BO is:

<ActivityInitiatorCode listAgencyId=“310”>1</ActivityInitiatorCode>

The structure of GDT ActivityInitiatorCode 35800BO is depicted in FIG.358BO. For GDT ActivityInitiatorCode 35800BO, the Object Class isActivity 35802BO, the Property is Initiator 35804BO, theRepresentation/Association is Code 35806BO, the Type is CCT 35808BO, theType Name is Code 35810BO, and the Length is one 35812BO. The remark35814BO shows that GDT ActivityInitiatorCode 35800BO can be restricted.

The GDT ActivityInitiatorCode 35800BO is a code list that may have thefollowing values: 1 (not specified), 2 (activity was initiated bycustomer, prospect, and so on), or 3 (activity was initiated from withinenterprise).

The GDT ActivityInitiatorCode 35800BO may be used for defining businessobjects and electronic messages, (for example, Groupwaresynchronization). If an external party cannot transfer anActivityInitiatorCode, the default code (1) can be used. This code isparticularly used in reporting in order to group business objects interms of whether an activity was initiated from within an enterprise, orinitiated by a customer or prospect.

(llllllllllll) BatchID

A GDT BatchID 35800BP is a unique identifier for a batch in the contextof a material number. A batch is a homogenous subset of a material thatis managed separately from other subsets of the same material.Individual batches may differ in their characteristics. The individualbatches are either created together in one production process orpurchased together in one order. An example of GDT BatchID 35800BP is:

<BatchID>CH20021015</BatchID>

The structure of GDT BatchID 35800BP is depicted in FIG. 358BP. For GDTBatchID 35800BP, the Category is Complex Type 35802BP, the Object Classis Batch 35804BP, the Property is Identification 35806BP, theRepresentation/Association is Identifier 35808BP, the Type is CCT35810BP, the Type Name is Identifier 35812BP, and the Length is from oneto ten 35814BP.

GDT BatchID 35800BP includes an element SchemeID 35816BP. For elementSchemeID 35816BP, the Category is Attribute (A) 35818BP, the ObjectClass is Identification Scheme 35820BP, the Property is Identification35822BP, the Representation/Association is Identifier 35824BF, the Typeis XSD 35826BP, the Type Name is token 35828BP, and the Cardinalitybetween GDT BatchID 35800BP and the element SchemeID 35816BP is fromzero to one 35830BP.

GDT BatchID 35800BP includes an element SchemeVersionID 35832BP. ForSchemeVersionID 35832BP, the Category is Attribute (A) 35834BP, theObject Class is Identification Scheme 35836BP, the Property is Version35838BP, the Representation/Association is Identifier 35840BF, the Typeis XSD 35842BP, the Type Name is token 35844BP, and the Cardinalitybetween GDT BatchID 35800BP and the element SchemeVersionID 35832BP isfrom zero to one 35846BP.

GDT BatchID 35800BP includes an element SchemeAgencyID 35848BP. ForSchemeAgencyID 35848BP, the Category is Attribute (A) 35850BP, theObject Class is Identification Scheme Agency 35852BP, the Property isIdentification 35854BP, the Representation/Association is Identifier35856BF, the Type is XSD 35858BP, the Type Name is token 35860BP, andthe Cardinality between GDT BatchID 35800BP and the elementSchemeAgencyID 35848BP is from zero to one 35862BP.

GDT BatchID 35800BP includes an element SchemeAgencySchemeID 35864BP.For SchemeAgencySchemeID 35864BP, the Category is Attribute (A) 35866BP,the Object Class is Identification Scheme Agency 35868BP, the Propertyis Scheme 35870BP, the Representation/Association is Identifier 35872BF,the Type is XSD 35874BP, the Type Name is token 35876BP, and theCardinality between GDT BatchID 35800BP and the elementSchemeAgencySchemeID 35864BP is from zero to one 35878BP.

GDT BatchID 35800BP includes an element SchemeAgencySchemeAgencyID35880BP. For SchemeAgencySchemeAgencyID 35880BP, the Category isAttribute (A) 35882BP, the Object Class is Identification Scheme Agency35884BP, the Property is Scheme Agency 35886BP, theRepresentation/Association is Identifier 35888BF, the Type is XSD35890BP, the Type Name is token 35892BP, and the Cardinality between GDTBatchID 35800BP and the element SchemeAgencySchemeAgencyID 35880BP isfrom zero to one 35894BP.

The data type GDT BatchID 35800BP may be used to identify batches. Bydefault, the system may assume that the batch identified by the BatchIDis a manufacturer batch and therefore no attributes are required.

(mmmmmmmmmmmm) BillOfOperationsConnectionTypeCode

A GDT BillOfOperationsConnectionTypeCode 35800BQ is the coded display ofthe type of a connection in a bill of operations. A connection elementis an element used to structure the “feeder” or “junction” processingpaths. A processing path may be linked to another processing path usinga connection element.   <BillOfOperationsConnectionTypeCode>1</BillOfOperationsConnectionTypeCode>

The structure of GDT BillOfOperationsConnectionTypeCode 35800BQ isdepicted in FIG. 358BQ. For GDT BillOfOperationsConnectionTypeCode35800BQ, the Object Class is Bill of Operations Connection 35802BQ, theProperty is Type 35804BQ, the Representation/Association is Code35806BQ, the Type is CCT 35808BQ, the Type Name is Code 35810BQ, and theLength is from one to two 35812BQ. The remark 35814BQ shows that GDTBillOfOperationsConnectionTypeCode 35800BQ can be restricted.

The data type GDT BillOfOperationsConnectionTypeCode 35800BQ mayindicate that the feeder describes the joining of one or severalparallel processing paths to another processing path. Additionally, theGDT BillOfOperationsConnectionTypeCode 35800BQ may indicate the junctiondescribes the separation of one or several processing paths from anotherprocessing path.

BillofOperationsElementID

The GDT BillofOperationsElementID 35800BR is a unique identifier of anelement of a bill of operations. An element is a part of a processdescription with which the basic structure of a process is defined alongwith its hierarchical and processing-specific dependencies. An exampleof GDT BillofOperationsElementID 35800BR

<BillOfOperationsElementID>ASSEMBLY</BillOfOperationsElementID>

The structure of GDT BillofOperationsElementID 35800BR is depicted inFIG. 358BR. For GDT BillofOperationsElementID 35800BR, the Object Classis Bill of Operations Element 35802BR, the Property is Identification35804BR, the Representation/Association is Identifier 35806BR, the Typeis CCT 35808BR, the Type Name is Identifier 35810BR, and the Length isfrom one to forty 35812BR. The remark 35814BR shows that GDTBillofOperationsElementID 35800BR can be restricted.

The data type GDT BillofOperationsElementID 35800BR may be explicit inthe context of a bill of operations.

(nnnnnnnnnnnn) BillOfOperationsElementTypeCode

A GDT BillOfOperationsElementTypeCode 35800BS is the coded display ofthe type of an element in the bill of operations. The type mayspecialize the element that can occur in the following specializations:Operation, Sequence, Branching, Connection and Mark. An example of a GDTBillOfOperationsElementTypeCode 35800BS is:

<BillOfOperationsElementTypeCode>1</BillOfOperationsElementTypeCode>

The structure of GDT BillOfOperationsElementTypeCode 35800BS is depictedin FIG. 358BS. For GDT BillOfOperationsElementTypeCode 35800BS, theObject Class is Bill of Operations Element 35802BS, the Property is Type35804BS, the Representation/Association is Code 35806BS, the Type is CCT35808BS, the Type Name is Code 35810BS, and the Length is from one totwo 35812BS. The remark 35814BS shows that GDTBillOfOperationsElementTypeCode 35800BS can be restricted.

The GDT BillOfOperationsElementTypeCode 35800BS is a code list that mayhave the following values: 1 (a sequence), 2 (a branching), 3 (aconnection), 4 (an operation), or 5 (a mark). The sequence is a groupingof linear elements of the bill of operations. The branching is anelement used to structure the bill of operations that defines thesplitting of a process into several process paths. The connection is anelement used to structure the bill of operations that defines “feeder”or “junction” processing paths. The operation is the description of aself-contained process section at a main resource. The mark is anelement used to structure the bill of operations that marks the start orthe end of a section in the bill of operations and thus assigns thissection a certain function.

(oooooooooooo) BillofOperationsID

A GDT BillofOperationsID 35800BT is a unique identifier of a bill ofoperations. A bill of operations is the definition of a processdescription in logistics. The following types of bills of operationsexist: a production bill of operations, a production bill of operationstemplate, and a site logistics bill of operations. An example of GDTBillofOperationsID 35800BT is:

<BillOfOperationsID>ENGINEPRODUCTION</BillOfOperationsID>

The structure of GDT BillofOperationsID 35800BT is depicted in FIG.358BT. For GDT BillofOperationsID 35800BT, the Object Class is Bill ofOperations 35802BT, the Property is Identification 35804BT, theRepresentation/Association is Identifier 35806BT, the Type is CCT35808BT, the Type Name is Identifier 35810BT, and the Length is from oneto forty 35812BT. The remark 35814BT shows that GDT BillofOperationsID35800BT can be restricted.

(pppppppppppp) BillofOperationsTemplateTypeCode

A GDT BillofOperationsTemplateTypeCode 35800BU is the coded display ofthe type of a bill of operations template. A bill of operations templateis a pattern used to create process descriptions in logistics. The typeof the bill of operations template can be used to differentiate whethera complex process description or an individual operation is described.An example of GDT BillofOperationsTemplateTypeCode 35800BU is:

<BillOfOperationsTemplateTypeCode>1</BillOfOperationsTemplateTypeCode>

The structure of GDT BillofOperationsTemplateTypeCode 35800BU isdepicted in FIG. 358BU. For GDT BillofOperationsTemplateTypeCode35800BU, the Object Class is Bill of Operations Template 35802BU, theProperty is Type 35804BU, the Representation/Association is Code35806BU, the Type is CCT 35808BU, the Type Name is Code 35810BU, and theLength is from one to two 35812BU. The remark 35814BU shows that GDTBillofOperationsTemplateTypeCode 35800BU can be restricted.

The GDT BillofOperationsTemplateTypeCode 35800BU is a code list that mayhave the following values: 1 (bill of operations template for a complexprocess description) or 2 (bill of operations template for a singleoperation).

(qqqqqqqqqqqq) BusinessTransactionDocumentItemScheduleLineTypeCode

A GDT BusinessTransactionDocumentItemScheduleLineTypeCode 35800BV is thecoded representation of a type of schedule line of an item in adocument. The schedule line type of a schedule line in a document itemspecifies which quantity and which date/time is involved in the scheduleline. An example of GDTBusinessTransactionDocumentItemScheduleLineTypeCode 35800BV is:  <SalesOrderItemScheduleLineTypeCode>1</SalesOrderItemScheduleLineTypeCode>

The structure of GDT BusinessTransactionDocumentItemScheduleLineTypeCode35800BV is depicted in FIG. 358BV. For GDTBusinessTransactionDocumentItemScheduleLineTypeCode 35800BV, the ObjectClass is Business Transaction Document Item Schedule Line, 35802BV, theProperty is Type 35804BV, the Representation/Association is Code35806BV, the Type is CCT 35808BV, the Type Name is Code 35810BV, and theLength is from one to two 35812BV. The remark 35814BV shows that GDTBusinessTransactionDocumentItemScheduleLineTypeCode 35800BV can berestricted.

The data type GDT BusinessTransactionDocumentItemScheduleLineTypeCode35800BV is a code list that may have the following values: 1(requested), 2 (confirmed) or 3 (promised). A requested value mayindicate the quantity and date or time, requested by the customer, fordelivery of goods or provision of services. A confirmed value mayindicate the quantity and date or time, confirmed by planning, fordelivery of goods or provision of services. A promised value mayindicate the minimum quantity or latest promised date or time fordelivery of goods or provision of services.

The data type GDT BusinessTransactionDocumentItemScheduleLineTypeCode35800BV can be used, for example, in the sales order item, to representthe date or time and quantity requested by the customer, and the planneddelivery date or time and quantity.

ChartOfAccountsID

A GDT ChartOfAccountsID 35800BW is an identifier for a chart ofaccounts. A chart of accounts is an ordered repository of accountnumbers for which a general ledger account can be created in the GeneralLedger for each company. The items of the chart of accounts determinethe account number as well as the type of value-based changes made inthe general ledger accounts. An example of GDT ChartOfAccountsID 35800BWis:

<ChartOfAccountsID schemeAgencyID=“FIN_(—)001”>0001</ChartOfAccountsID>

The structure of GDT ChartOfAccountsID 35800BW is depicted in FIG.358BW. For GDT ChartOfAccountsID 35800BW, the Object Class is Chart ofAccounts 35802BW, the Property is Identification 35804BW, theRepresentation/Association is Identifier 35806BW, the Type is CCT35808BW, the Type Name is Identifier 35810BW, and the Length is from oneto four 35812BW. The remark 35814Bw shows that GDT ChartOfAccountsID35800BW can be restricted.

GDT ChartOfAccountsID 35800BW includes an element SchemeAgencyID35816BW. For element SchemeAgencyID 35816BW, the Category is Attribute(A) 35818BW, the Object Class is Identification Scheme Agency 35820BW,the Property is Identification 35822BW, the Representation/Associationis Identifier 35824BW, the Type is XSD 35826BW, the Type Name is token35828BW, and the Cardinality between GDT ChartOfAccountsID 35800BW andthe element SchemeAgencyID 35816BW is from zero to one 35830BJ.

The data type GDT ChartOfAccountsID 35800BW may be used in the GDTGeneralLedgerAccount, for example, to identify the chart of accounts forthe general ledger account.

(rrrrrrrrrrrr) LogisticsPackageTypeCode

A GDT LogisticsPackageTypeCode 35800BX is the coded representation ofthe type of a package as it can be used in logistics for storing andshipping goods. An example of a GDT LogisticsPackageTypeCode 35800BX is:

<LogisticsPackageTypeCode>1</LogisticsPackageTypeCode>

The structure of GDT LogisticsPackageTypeCode 35800BX is depicted inFIG. 358BX. For the GDT LogisticsPackageTypeCode 35800BX, the ObjectClass is Logistics Package 35802BX, the Property is Type 35804BX, theRepresentation/Association is Code 35806BX, the Type is CCT 35808BX, theType Name is Code 35810BX, and the Length is one 35812BX. TheCardinality is one 35814BX. The remark 35816BX shows that GDTLogisticsPackageTypeCode 35800BX may be restricted.

The attributes are used as follows: listID=10071, listAgencyID=310, andlistVersionID is the version of the relevant code list assigned andmanaged by SAP AG. The LogisticsPackageTypeCode is a fixed SAP codelist. The attributes, listID, listAgencyID, listVersionID are missingfrom the structure as they have constant values during runtime.

Possible code values for the GDT LogisticsPackageTypeCode 35800BX areone and two. One describes a Handling Unit. The Handling Unit is aLogistics Package that can be identified individually, for example auniquely labeled container. Two describes a Logistics Unit. TheLogistics Unit is a Logistics Package that cannot be identifiedindividually, for example boxes in a certain storage bin.

In Logistics, the GDT LogisticsPackageTypeCode 35800BX defines the typeof a packed unit in more detail.

(ssssssssssss) LogisticsBranchingID

A GDT LogisticsBranchingID 35800BY is a unique identifier of a branchingin a process description in logistics. A branching is a way ofstructuring a process description in logistics that splits a processinto several process paths. A processing path describes a directedmaterial flow in logistics. In addition to a common starting point, thebranched processing paths also have a common end point where thedifferent paths join again. An example of a GDT LogisticsBranchingID35800BY is:

<LogisticsBranchingID>R2D2</LogisticsBranchingID>

The structure of GDT LogisticsBranchingID 35800BY is depicted in FIG.358BY. For the GDT LogisticsBranchingID 35800BY, the Object Class isLogistics Branching 35802BY, the Property is Identification 35804BY, theRepresentation/Association is Identifier 35806BY, the-Type is CCT35808BY, the Type Name is Identifier 35810BY, and the Length is from oneto forty 35812BY. The remark 35814BY shows that GDT LogisticsBranchingID35800BY may be restricted.

The GDT LogisticsBranchingID 35800BY may be unique in the usage context.

(tttttttttttt) LogisticsConfirmationMethodCode

A GDT LogisticsConfirmationMethodCode 35800BZ is the codedrepresentation of the method used for confirmations in logistics. Alogistic confirmation records the progress of a logistic process, forexample, goods movement or component consumption. An example of a GDTLogisticsConfirmationMethodCode 35800BZ is:

<LogisticsConfirmationMethodCode>1</LogisticsConfirmationMethodCode>

The structure of GDT LogisticsConfirmationMethodCode 35800BZ is depictedin FIG. 358BZ. For the GDT LogisticsConfirmationMethodCode 35800BZ, theObject Class is Logistics Confirmation 35802BZ, the Property is Method35804BZ, the Representation/Association is Code 35806BZ, the Type is CCT35808BZ, the Type Name is Code 35810BZ, and the Length is from one totwo 35812BZ. The remark 35814BZ shows that GDTLogisticsConfirmationMethodCode 35800BZ may be restricted.

Exactly one fixed SAP code list has been assigned to the code. Theattributes are as follows: listID=“10139”, listAgencyID=“310”, andlistVersionID which is the version of the relevant code list assignedand managed by SAP AG and to be determined.

Possible code values for the GDT LogisticsConfirmationMethodCode 35800BZare one and two. One is a Backflush. Backflush is where the quantitiesor durations are determined some time later, that is, they arecalculated and reported depending on another value reported. Which valuecan be used as the basis for calculating the quantities and durationsdepends on the context. Two is an Explicit. Explicit is where quantitiesor durations may be confirmed explicitly.

The code can be used to determine which procedure is to be used forlogistic confirmations, such as material consumptions and receipts. Theconsumption of expensive materials or materials that cannot be procuredeasily will usually be confirmed explicitly, whereas cheaper materialswill be reported later when the completion of an intermediate productquantity is reported, using the backflush code.

(uuuuuuuuuuuu) LogisticUnitGroupID

A GDT LogisticUnitGroupID 35800CA is a unique identifier for a logisticunit group.

A logistic unit group specifies for a Logistic Unit Usage aclassification to which logistic units can be assigned. The logisticunits that can be assigned to a group have similar attributes relevantfor the purposes of the Logistic Unit Usage. A Logistic Unit Usage is alogistics purpose for which Logistic Units are grouped. The LogisticUnit Usage can represent a process or an activity, such as conveying,packing, or storing. An example of a GDT LogisticUnitGroupID 35800CA is:

<LogisticUnitGroupID>12345678901234567890</LogisticUnitGroupID>

<LogisticUnitGroupID>HIGH_PALLETS</LogisticUnitGroupID>

The structure of GDT LogisticUnitGroupID 35800CA is depicted in FIG.358CA. For the GDT LogisticUnitGroupID 35800CA, the Category is Element(E) 35801CA, the Object Class is Logistic Unit Group 35802CA, theProperty is Identification 35803CA, the Representation/Association isIdentifier 35804CA, the Type is CCT 35805CA, the Type Name is Identifier35806CA and the Length is from one to forty 35807CA.

For the scheme ID 35808CA, the Category is Attribute (A) 34509CA, theObject Class is Identification Scheme 35810CA, the Property isIdentification 35811CA, the Representation/Association is Identifier35812CA, the Type is XSD 35813CA, the Type Name is token 35814CA, andthe Length is from one to sixty 35815CA. The Cardinality is zero or one35816CA.

For the scheme Version ID 35817CA, the Category is Attribute (A)34518CA, the Object Class is Identification Scheme 35819CA, the Propertyis Version 35820CA, the Representation/Association is Identifier35821CA, the Type is XSD 35822CA, the Type Name is token 35823CA, andthe Length is from one to fifteen 35824CA. The Cardinality is zero orone 35825CA.

For the scheme Agency ID 35826CA, the Category is Attribute (A) 34527CA,the Object Class is Identification Scheme-Agency 35828CA, the Propertyis Identification 35829CA, the Representation/Association is Identifier35830CA, the Type is XSD 35831CA, the Type Name is token 35832CA, andthe Length is from one to sixty 35833CA. The Cardinality is zero or one35834CA.

For the scheme Agency-Scheme ID 35835CA, the Category is Attribute (A)34536CA, the Object Class is Identification Scheme-Agency 35837CA, theProperty is Scheme 35838CA, the Representation/Association is Identifier35839CA, the Type is XSD 35840CA, the Type Name is token 35841CA, andthe Length is from one to sixty 35842CA. The Cardinality is zero or one35843CA.

For the scheme Agency-Scheme Agency ID 35844CA, the Category isAttribute (A) 34545CA, the Object Class is Identification Scheme-Agency35846CA, the Property is Scheme Agency 35847CA, theRepresentation/Association is Identifier 35848CA, the Type is XSD35849CA, the Type Name is token 358450CA, and the Length is from one tothree 35851CA. The Cardinality is zero or one 35852CA.

The GDT LogisticUnitGroupID 35800CA includes many attributes. A schemeID 35808CA is an ID of the ID scheme. It is released and maintained bythe responsible organization of the ID scheme. The GDT owner mustretrieve the correct ID from the responsible organization. If there isno unique ID available, the name of the identifier or identifier typemay be entered, which can be used in the corresponding standard,specification, or scheme of the responsible organization.

A scheme Agency ID 35826CA is the ID of the organization maintaining theID scheme. This identification is released by an organization, forexample DUNS, EAN or SWIFT. The GDT owner must retrieve the correct IDfrom the responsible organization.

A scheme Version ID 35817CA is a version of the ID scheme. It isreleased and maintained by the organization, which is named in schemeAgency ID 35826CA. The GDT owner must retrieve the relevant version IDfrom the responsible organization. If there is no version for the IDscheme, the version of the standard, the specification, or the schemecan be used.

A scheme Agency-Scheme ID 35835CA is the identification of the schema,which identifies the organization named in scheme Agency ID 35826CA.It's a certain scheme ID of partners, companies or members, for exampleDUNS+4, of an organization named in scheme Agency-Scheme Agency ID35844CA, for example DUNS, EAN or SWIFT.

A scheme Agency-Scheme Agency ID 35844CA is an identification of themaintaining organization, for example DUNS, EAN or SWIFT which isresponsible for the identification of the organization named in schemeAgency ID 35826CA.

(vvvvvvvvvvvv) LogisticUnitID

A GDT LogisticUnitID 35800CB is a unique identifier for a LogisticUnit.

A Logistic Unit is an item established for logistics operations, such asstorage, movement, and packing. A Logistic Unit represents all physicalunits handled in the same manner during logistic operations, whetherthey be packed or unpacked goods. Examples of a Logistic Unit mayinclude a high pallet or a liter milk carton. An example of a GDTLogisticUnitID 35800CB is:

<LogisticUnitID>12345678901234567890</LogisticUnitID>

<LogisticUnitID>2_METER_PALLET</LogisticUnitID>

The structure of GDT LogisticUnitID 35800CB is depicted in FIG. 358CB.For the GDT LogisticUnitID 35800CB, the Category is Element (E) 35801CB,the Object Class is Logistic Unit 35802CB, the Property isIdentification 35803CB, the Representation/Association is Identifier35804CB, the Type is CCT 35805CB, the Type Name is Identifier 35806CBand the Length is from one to forty 35807CB.

For the scheme ID 35808CB, the Category is Attribute (A) 34509CB, theObject Class is Identification Scheme 35810CB, the Property isIdentification 35811CB, the Representation/Association is Identifier35812CB, the Type is XSD 35813CB, the Type Name is token 35814CB, andthe Length is from one to sixty 35815CB. The Cardinality is zero or one35816CB.

For the scheme Version ID 35817CB, the Category is Attribute (A)34518CB, the Object Class is Identification Scheme 35819CB, the Propertyis Version 35820CB, the Representation/Association is Identifier35821CB, the Type is XSD 35822CB, the Type Name is token 35823CB, andthe Length is from one to fifteen 35824CB. The Cardinality is zero orone 35825CB.

For the scheme Agency ID 35826CB, the Category is Attribute (A) 34527CB,the Object Class is Identification Scheme-Agency 35828CB, the Propertyis Identification 35829CB, the Representation/Association is Identifier35830CB, the Type is XSD 35831CB, the Type Name is token 35832CB, andthe Length is from one to sixty 35833CB. The Cardinality is zero or one35834CB.

For the scheme Agency-Scheme ID 35835CB, the Category is Attribute (A)34536CB, the Object Class is Identification Scheme-Agency 35837CB, theProperty is Scheme 35838CB, the Representation/Association is Identifier35839CB, the Type is XSD 35840CB, the Type Name is token 35841CB, andthe Length is from one to sixty 35842CB. The Cardinality is zero or one35843CB.

For the scheme Agency-Scheme Agency ID 35844CB, the Category isAttribute (A) 34545CB, the Object Class is Identification Scheme-Agency35846CB, the Property is Scheme Agency 35847CB, theRepresentation/Association is Identifier 35848CB, the Type is XSD35849CB, the Type Name is token 358450CB, and the Length is from one tothree 35851CB. The Cardinality is zero or one 35852CB.

The GDT LogisticUnitID 35800CB includes many attributes. A scheme ID35808CB is an ID of the ID scheme. It is released and maintained by theresponsible organization of the ID scheme. The GDT owner must retrievethe correct ID from the responsible organization. If there is no uniqueID available, the name of the identifier or identifier type may beentered, which can be used in the corresponding standard, specification,or scheme of the responsible organization.

A scheme Agency ID 35826CB is the ID of the organization maintaining theID scheme. This identification is released by an organization, forexample DUNS, EAN or SWIFT. The GDT owner must retrieve the correct IDfrom the responsible organization.

A scheme Version ID 35817CB is a version of the ID scheme. It isreleased and maintained by the organization, which is named in schemeAgency ID 35826CB. The GDT owner must retrieve the relevant version IDfrom the responsible organization. If there is no version for the IDscheme, the version of the standard, the specification, or the schemecan be used.

A scheme Agency-Scheme ID 35835CB is the identification of the schema,which identifies the organization named in scheme Agency ID 35826CB.It's a certain scheme ID of partners, companies or members, for exampleDUNS+4, of an organization named in scheme Agency-Scheme Agency ID35844CB, for example DUNS, EAN or SWIFT.

A scheme Agency-Scheme Agency ID 35844CB is an identification of themaintaining organization, for example DUNS, EAN or SWIFT which isresponsible for the identification of the organization named in schemeAgency ID 35826CB.

(wwwwwwwwwwww) LogisticUnitShapeCode

A GDT LogisticUnitShapeCode 35800CC is a coded representation of thelogistic unit's physical exterior shape, which may be used for handlingpurposes. A Logistic Unit is an item established for logisticsoperations, such as storage, movement, and packing. A Logistic Unitrepresents all physical units handled in the same manner during logisticoperations, whether they be packed or unpacked goods. Examples of aLogistic Unit may include a high pallet or a liter milk carton. Anexample of a GDT LogisticUnitShapeCode 35800CC is:

<LogisticUnitShapeCode>1</LogisticUnitShapeCode>

The structure of GDT LogisticUnitShapeCode 35800CC is depicted in FIG.358CC. For the GDT LogisticUnitShapeCode 35800CC, the Category isElement (E) 35802CC, the Object Class is Logistic Unit Shape 35804CC,the Property is Shape 35806CC, the Representation/Association is Code35808CC, the Type is CCT 35810CC, the Type Name is Code 35812CC and theLength is from one to two 35814CC.

For the list Agency ID 35816CC, the Category is Attribute (A) 34518CC,the Object Class is Code List Agency 35820CC, the Property isIdentification 35822CC, the Representation/Association is Identifier35824CC, the Type is XSD 35826CC, and the Type Name is token 35828CC.The Cardinality is zero or one 35830CC.

For the list Version ID 35832CC, the Category is Attribute (A) 34534CC,the Object Class is Code List 35836CC, the Property is Version 35838CC,the Representation/Association is Identifier 35840CC, the Type is XSD35842CC, and the Type Name is token 35844CC. The Cardinality is zero orone 35846CC.

For the list Agency-Scheme ID 35848CC, the Category is Attribute (A)34550CC, the Object Class is Code List Agency 35852CC, the Property isScheme 35854CC, the Representation/Association is Identifier 35856CC,the Type is XSD 35858CC, and the Type Name is token 35860CC. TheCardinality is zero or one 35862CC.

For the list Agency-Scheme Agency ID 35864CC, the Category is Attribute(A) 34566CC, the Object Class is Code List Agency 35868CC, the Propertyis Scheme Agency 35870CC, the Representation/Association is Identifier35872CC, the Type is XSD 35874CC, and the Type Name is token 35876CC.The Cardinality is zero or one 35878CC.

A customer-specific code list, containing codes defined by A customer,is assigned to the GDT LogisticUnitShapeCode 35800CC. There are nopredefined values of the code values. The attributes of the GDTLogisticUnitShapeCode 35800CC can be assigned the following values:listID=“10041”, listAgencyID which is the ID of the Customer (ID from DE3055, if listed there), listVersionID which is assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, and thelistAgencySchemeAgencyID which is the ID of the organization from DE3055 that manages the listAgencySchemeID scheme.

The GDT LogisticUnitShapeCode 35800CC can be used by a logistic unit tospecify its physical form. Examples for customer-specific code semanticsinclude a Box-shaped which specifies the Logistic Unit is box-shaped, aBarrel-shaped which specifies the Logistic Unit is barrel-shaped and aContainer-shaped which specifies the Logistic Unit is container-shaped.

(xxxxxxxxxxxx) LogisticUnitUsageID

A GDT LogisticUnitUsageID 35800CD is a unique identifier for a LogisticUnit Usage.

A Logistic Unit Usage is a logistics purpose for which Logistic Unitsare grouped. The Logistic Unit Usage can represent a process or anactivity, such as conveying, packing, or storing. An example of a GDTLogisticUnitUsageID 35800CD is:<LogisticUnitUsageID>12345678901234567890</LogisticUnitUsageID><LogisticUnitUsageID>CONVEYING</LogisticUnitUsageID>

The structure of GDT LogisticUnitUsageID 35800CD is depicted in FIG.358CD. For the GDT LogisticUnitUsageID 35800CD, the Category is Element(E) 35801CD, the Object Class is Logistic Unit Group 35802CD, theProperty is Identification 35803CD, the Representation/Association isIdentifier 35804CD, the Type is CCT 35805CD, the Type Name is Identifier35806CD and the Length is from one to forty 35807CD.

For the scheme ID 35808CD, the Category is Attribute (A) 34509CD, theObject Class is Identification Scheme 35810CD, the Property isIdentification 35811CD, the Representation/Association is Identifier35812CD, the Type is XSD 35813CD, the Type Name is token 35814CD, andthe Length is from one to sixty 35815CD. The Cardinality is zero or one35816CD.

For the scheme Version ID 35817CD, the Category is Attribute (A)34518CD, the Object Class is Identification Scheme 35819CD, the Propertyis Version 35820CD, the Representation/Association is Identifier 35821CD, the Type is XSD 35822CD, the Type Name is token 35823CD, and theLength is from one to fifteen 35824CD. The Cardinality is zero or one35825CD.

For the scheme Agency ID 35826CD, the Category is Attribute (A) 34527CD,the Object Class is Identification Scheme-Agency 35828CD, the Propertyis Identification 35829CD, the Representation/Association is Identifier35830CD, the Type is XSD 35831CD, the Type Name is token 35832CD, andthe Length is from one to sixty 35833CD. The Cardinality is zero or one35834CD.

For the scheme Agency-Scheme ID 35835CD, the Category is Attribute (A)34536CD, the Object Class is Identification Scheme-Agency 35837CD, theProperty is Scheme 35838CD, the Representation/Association is Identifier35839CD, the Type is XSD 35840CD, the Type Name is token 35841 CD, andthe Length is from one to sixty 35842CD. The Cardinality is zero or one35843CD.

For the scheme Agency-Scheme Agency ID 35844CD, the Category isAttribute (A) 34545CD, the Object Class is Identification Scheme-Agency35846CD, the Property is Scheme Agency 35847CD, theRepresentation/Association is Identifier 35848CD, the Type is XSD35849CD, the Type Name is token 358450CD, and the Length is from one tothree 35851CD. The Cardinality is zero or one 35852CD.

The GDT LogisticUnitUsageID 35800CD includes many attributes. A schemeID 35808CD is an ID of the ID scheme. It is released and maintained bythe responsible organization of the ID scheme. The GDT owner mustretrieve the correct ID from the responsible organization. If there isno unique ID available, the name of the identifier or identifier typemay be entered, which can be used in the corresponding standard,specification, or scheme of the responsible organization.

A scheme Agency ID 35826CD is the ID of the organization maintaining theID scheme. This identification is released by an organization, forexample DUNS, EAN or SWIFT The GDT owner must retrieve the correct IDfrom the responsible organization.

A scheme Version ID 35817CD is a version of the ID scheme. It isreleased and maintained by the organization, which is named in schemeAgency ID 35826CD. The GDT owner must retrieve the relevant version IDfrom the responsible organization. If there is no version for the IDscheme, the version of the standard, the specification, or the schemecan be used.

A scheme Agency-Scheme ID 35835CD is the identification of the schema,which identifies the organization named in scheme Agency ID 35826CD.It's a certain scheme ID of partners, companies or members, for exampleDUNS+4, of an organization named in scheme Agency-Scheme Agency ID35844CD, for example DUNS, EAN or SWIFT.

A scheme Agency-Scheme Agency ID 35844CD is an identification of themaintaining organization, for example DUNS, EAN or SWIFT which isresponsible for the identification of the organization named in schemeAgency ID 35826CD.

(yyyyyyyyyyyy) LogisticsBranchingJoinID

A GDT LogisticsBranchingJoinID 35800CE is a unique identifier of ajoining of a branching in a process description in logistics. At a join,the alternative production and transportation paths that were split by abranching are reunited in one common path. An example of a GDTLogisticsBranchingJoinID 35800CE is:

<LogisticsBranchingJoinID>C3PO</LogisticsBranchingJoinID>

The structure of GDT LogisticsBranchingJoinID 35800CE is depicted inFIG. 358CE. For the GDT LogisticsBranchingJoinID 35800CE, the ObjectClass is Logistics Branching Join 35802CE, the Property isIdentification 35804CE, the Representation/Association is Identifier35806CE, the Type is CCT 35808CE, the Type Name is Identifier 35810CE,and the Length is from one to forty 35812CE. The remark 35814CE showsthat GDT LogisticsBranchingJoinID 35800CE may be restricted.

The GDT LogisticsBranchingJoinID 35800CE may be unique in the usagecontext.

(zzzzzzzzzzzz) LogisticsBranchingPathID

A GDT LogisticsBranchingPathID 35800CF is a unique identifier of a pathof a branching in a process description in logistics. A path is a linearsequence of operations in a process description in logistics. An exampleof a GDT LogisticsBranchingPathID 35800CF is:

<LogisticsBranchingPathID>F3335</LogisticsBranchingPathID>

The structure of GDT LogisticsBranchingPathID 35800CF is depicted inFIG. 358CF. For the GDT LogisticsBranchingPathID 35800CF, the ObjectClass is Logistics Branching Path 35802CF, the Property isIdentification 35804CF, the Representation/Association is Identifier35806CF, the Type is CCT 35808CF, the Type Name is Identifier 35810CF,and the Length is from one to forty 35812CF. The remark 35814CF showsthat GDT LogisticsBranchingPathID 35800CF may be restricted.

The GDT LogisticsBranchingPathID 35800CF may be unique in the usagecontext.

(aaaaaaaaaaaaa) LogisticsTaskFolderRegistrantTypeCode

A GDT LogisticsTaskFolderRegistrantTypeCode 35800CG is the codedrepresentation of the type of object registered at a logistics taskfolder. A logistics task folder is a folder for storing and grouping oflogistics tasks according to business criteria. It determines thebusiness assignment criteria that a logistics task must meet to bestored in a specific folder and contains details about the processorsthat are registered at the folder. An example of a GDTLogisticsTaskFolderRegistrantTypeCode 35800CG is:

<LogisticsTaskFolderRegistrantTypeCode>1</LogisticsTaskFolderRegistrantTypeCode>

The structure of GDT LogisticsTaskFolderRegistrantTypeCode 35800CG isdepicted in FIG. 358CG. For the GDTLogisticsTaskFolderRegistrantTypeCode 35800CG, the Object Class isLogistics Task Folder Registrant 35802CG, the Property is Type 35804CG,the Representation/Association is Code 35806CG, the Type is CCT 35808CG,the Type Name is Code 35810CG, and the Length is from one to two35812CG. The remark 35814CG shows that GDTLogisticsTaskFolderRegistrantTypeCode 35800CG may be restricted.

Exactly one fixed SAP code list has been assigned to the GDTLogisticsTaskFolderRegistrantTypeCode 35800CG. The attributes are asfollows: listID=10155, listAgencyID=310, listVersionID which is theversion of the relevant code list assigned and managed by SAP AG.

Possible code values for the GDT LogisticsTaskFolderRegistrantTypeCode35800CG are one and two. One describes a User, which is the objectregistered by a user. Two describes an End-user device, which is theobject registered is an end-user device.

(bbbbbbbbbbbbb) LogisticsTaskFolderTypeCode

A GDT LogisticsTaskFolderTypeCode 35800CH is the coded representation ofthe type of the logistics task folder. A logistics task folder is afolder for storing and grouping of logistics tasks according to businesscriteria. It determines the business assignment criteria that alogistics task must meet to be stored in a specific folder and containsdetails about the processors that are registered at the folder. Anexample of a GDT LogisticsTaskFolderTypeCode 35800CH is:

<LogisticsTaskFolderTypeCode>1</LogisticsTaskFolderTypeCode>

The structure of GDT LogisticsTaskFolderTypeCode 35800CH is depicted inFIG. 358CH. For the GDT LogisticsTaskFolderTypeCode 35800CH, the ObjectClass is Logistics Task Folder 35802CH, the Property is Type 35804CH,the Representation/Association is Code 35806CH, the Type is CCT 35808CH,the Type Name is Code 35810CH, and the Length is from one to two35812CH. The remark 35814CH shows that GDT LogisticsTaskFolderTypeCode35800CH may be restricted.

The GDT LogisticsTaskFolderTypeCode 35800CH can be used to restrict whata logistics task folder can be used for and how it behaves.

Exactly one fixed SAP code list has been assigned to GDTLogisticsTaskFolderTypeCode 35800CH. The attributes are as follows:listID=10154, listAgencyID=310, listVersionID which is the version ofthe relevant code list assigned and managed by SAP AG which is to bedetermined.

Possible code values for the GDT LogisticsTaskFolderTypeCode 35800CH areone, two and three. One describes a Standard, which is a folder forstoring tasks that can be assigned. Two describes an Exception, which isa folder for storing tasks that cannot be assigned initially. Threedescribes a Template, which is a template for creating new folders.

(ccccccccccccc) LogisticsTaskTypeCode

A GDT LogisticsTaskTypeCode 35800CI is the coded representation of thetype of a logistics task. A logistics task is a task that a processorexecutes at a specific time at a predefined work step within aproduction or site logistics process. An example of a GDTLogisticsTaskTypeCode 35800CI is:

<LogisticsTaskTypeCode>1</LogisticsTaskTypeCode>

The structure of GDT LogisticsTaskTypeCode 35800CI is depicted in FIG.358CI. For the GDT LogisticsTaskTypeCode 35800CI, the Object Class isLogistics Task 35802CI, the Property is Type 35804CI, theRepresentation/Association is Code 35806CI, the Type is CCT 35808CI, theType Name is Code 35810CI, and the Length is from one to two 35812CI.The remark 35814CI shows that GDT LogisticsTaskTypeCode 35800CI may berestricted.

The GDT LogisticsTaskTypeCode 35800CI can be used to restrict what alogistics task folder can be used for and how it behaves.

Exactly one fixed SAP code list has been assigned to GDTLogisticsTaskFolderTypeCode 35800CH. The attributes are as follows:listID=10153, listAgencyID=310, listVersionID which is the version ofthe relevant code list assigned and managed by SAP AG which is to bedetermined.

Possible code values for the GDT LogisticsTaskTypeCode 35800CI are oneand two. One describes a Production Task, which is a task used inproduction. Two describes aSite Logistics Task, which is a task used insite logistics.

(ddddddddddddd) MaritalStatusCode

A GDT MaritalStatusCode 35800CJ is the coded description of maritalstatus. An example of a GDT MaritalStatusCode 35800CJ is:

<MaritalStatusCode>2</MaritalStatusCode>

The structure of GDT MaritalStatusCode 35800CJ is depicted in FIG.358CJ. For the GDT MaritalStatusCode 35800CJ, the Property is MaritalStatus 35802CJ, the Representation/Association is Code 35804CJ, the Typeis CCT 35806CJ, the Type Name is Code 35808CJ and the Length is one35810CJ. The remark 35812CJ shows that GDT MaritalStatusCode 35800CJ maybe restricted.

For the list ID 35814CJ, the Category is Attribute (A) 34516CJ, theObject Class is Code List 35818CJ, the Property is Identification35820CJ, the Representation/Association is Identifier 35822CJ, the Typeis XSD 35824CJ, and the Type Name is token 35826CJ. The Cardinality iszero or one 35828CJ.

For the list Agency ID 35830CJ, the Category is Attribute (A) 34532CJ,the Object Class is Code List Agency 35834CJ, the Property isIdentification 35836CJ, the Representation/Association is Identifier35838CJ, the Type is XSD 35840CJ, and the Type Name is token 35842CJ.The Cardinality is zero or one 35844CJ.

For the list Version ID 35846CJ, the Category is Attribute (A) 34548CJ,the Object Class is Code List 35850CJ, the Property is Version 35852CJ,the Representation/Association is Identifier 35854CJ, the Type is XSD35856CJ, and the Type Name is token 35858CJ. The Cardinality is zero orone 35860CJ.

For the list Agency-Scheme ID 35862CJ, the Category is Attribute34564CJ, the Object Class is Code List Agency 35866CJ, the Property isScheme 35868CJ, the Representation/Association is Identifier 35870CJ,the Type is XSD 35872CJ, and the Type Name is token 35874CJ. TheCardinality is zero or one 35876CJ.

For the list Agency-Scheme Agency ID 35878CJ, the Category is Attribute34580CJ, the Object Class is Code List Agency 35882CJ, the Property isScheme Agency 35884CJ, the Representation/Association is Identifier35886CJ, the Type is XSD 35888CJ, and the Type Name is token 35890CJ.The Cardinality is zero or one 35892CJ.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10357”, listAgencyID which is theID of the Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, listAgencySchemeAgencyID whichis the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

Examples of possible codes are Married, indicating the person is marriedand Single, indicating the person is single.

The following dictionary objects can be assigned to this GDT in mySAPsystems: Data element: BU_MARST and Domain: BU_MARST.

(eeeeeeeeeeeee) MaterialInputID

A GDT MaterialInputID 35800CK is a unique identifier for a materialinput in logistics. A material input is a quantitative input of amaterial that is required for the execution of a logistic process. Anexample of a GDT MaterialInputID 35800CK is:

<MaterialInputID>4711</MaterialInputID>

The structure of GDT MaterialInputID 35800CK is depicted in FIG. 358CK.For the GDT MaterialInputID 35800CK, the Object Class is Material Input35802CK, the Property is Identification 35804CK, theRepresentation/Association is Identifier 35806CK, the Type is CCT35808CK, the Type Name is Identifier 35810CK, and the Length is from oneto six 35812CK. The remark 35814CK shows that GDT MaterialInputID35800CK may be restricted.

The GDT MaterialInputID 35800CK is unique in the context of the businessobject to which it belongs.

(fffffffffffff) MaterialOutputID

A GDT MaterialOutputID 35800CL is a unique identifier for a materialoutput in logistics. A material output is a quantitative output of amaterial that is the planned result of a logistic process. An example ofa GDT MaterialOutputID 35800CL is:

<MaterialOutputID>4711</MaterialOutputID>

The structure of GDT MaterialOutputID 35800CL is depicted in FIG. 358CL.For the GDT MaterialOutputID 35800CL, the Object Class is MaterialOutput 35802CL, the Property is Identification 35804CL, theRepresentation/Association is Identifier 35806CL, the Type is CCT35808CL, the Type Name is Identifier 35810CL, and the Length is from oneto six 35812CL. The remark 35814CL shows that GDT MaterialOutputID35800CL may be restricted.

The GDT MaterialOutputID 35800CL is unique in the context of thebusiness object to which it belongs.

(ggggggggggggg) MaterialRoleCode

A GDT MaterialRoleCode 35800CM is the code indicating the role of amaterial. An example of a GDT MaterialRoleCode 35800CM is:

-   -   <MaterialRoleCode>2</MaterialRoleCode>

The structure of GDT MaterialRoleCode 35800CM is depicted in FIG. 358CM.For the GDT MaterialRoleCode 35800CM, the Object Class is Material35802CM, the Property is Role 35804CM, the Representation/Association isCode 35806CM, the Type is CCT 35808CM, the Type Name is Code 35810CM,and the Length is from one to two 35812CM. The remark 35814CM shows thatGDT MaterialRoleCode 35800CM may be restricted.

The GDT MaterialRoleCode 35800CM can be used to describe the role of amaterial in a process.

Exactly one fixed SAP code list has been assigned to the GDTMaterialRoleCode 35800CM. The attributes are as follows: listID=“10158”,and listAgencyID=“310”.

Qualified GDT MaterialRoleCode 35800CM qualifiers includeJointProductionMaterialRoleCode, MaterialInputMaterialRoleCode, andMaterialOutputMaterialRoleCode. JointProductionMaterialRoleCode isdefined as the role of the created material in a joint productionprocess. Joint production is the production of several materials in onemanufacturing process. MaterialInputMaterialRoleCode is defined as therole of the incoming material an a production or packaging process.MaterialOutputMaterialRoleCode is defined as the role of the outgoingmaterial an a production or packaging process.

Possible code values for the GDT MaterialRoleCode 35800CM are one, two,three and four. One describes a Main Product. The main product is thematerial to be produced. Two describes a Co-Product. The co-product is adesirable material that is produced during the production of the mainproduct. Three describes a By-Product. The by-product is an undesirablematerial that is produced during the production of the main product.Four describes Packaging Material. The packaging material is a removablewrapping that can be used to protect another material during shipment,for example.

(hhhhhhhhhhhhh) MaternityProtectionDeliveryTypeCode

A GDT MaternityProtectionDeliveryTypeCode 35800CN is the codedrepresentation of the type of a delivery of a child according tomaternity protection regulations. An example of a GDTMaternityProtectionDeliveryTypeCode 35800CN is:

<MaternityProtectionDeliveryTypeCode>1</MaternityProtectionDeliveryTypeCode

The structure of GDT MaternityProtectionDeliveryTypeCode 35800CN isdepicted in FIG. 358CN. For the GDT MaternityProtectionDeliveryTypeCode35800CN, the Object Class is Maternity Protection 35801CN, the Propertyis Delivery Type 35802CN, the Representation/Association is Code35804CN, the Type is CCT 35806CN, the Type Name is Code 35808CN and theLength is from one to two 35810CN. The remark 35812CN shows that GDTMaternityProtectionDeliveryTypeCode 35800CN may be restricted.

For the list ID 35814CN, the Category is Attribute (A) 34516CN, theObject Class is Code List 35818CN, the Property is Identification35820CN, the Representation/Association is Identifier 35822CN, the Typeis XSD 35824CN, and the Type Name is token 35826CN. The Cardinality iszero or one 35828CN.

For the list Agency ID 35830CN, the Category is Attribute (A) 34532CN,the Object Class is Code List Agency 35834CN, the Property isIdentification 35836CN, the Representation/Association is Identifier35838CN, the Type is XSD 35840CN, and the Type Name is token 35842CN.The Cardinality is zero or one 35844CN.

For the list Version ID 35846CN, the Category is Attribute (A) 34548CN,the Object Class is Code List 35850CN, the Property is Version 35852CN,the Representation/Association is Identifier 35854CN, the Type is XSD35856CN, and the Type Name is token 35858CN. The Cardinality is zero orone 35860CN.

For the list Agency-Scheme ID 35862CN, the Category is Attribute (A)34564CN, the Object Class is Code List Agency 35866CN, the Property isScheme 35868CN, the Representation/Association is Identifier 35870CN,the Type is XSD 35872CN, and the Type Name is token 35874CN. TheCardinality is zero or one 35876CN.

For the list Agency-Scheme Agency ID 35878CN, the Category is Attribute(A) 34580CN, the Object Class is Code List Agency 35882CN, the Propertyis Scheme Agency 35884CN, the Representation/Association is Identifier35886CN, the Type is XSD 35888CN, and the Type Name is token 35890CN.The Cardinality is zero or one 35892CN.

Several fixed, country-specific code lists, which are different atruntime, can be assigned to the GDT MaternityProtectionDeliveryTypeCode35800CN. The GDT MaternityProtectionDeliveryTypeCode 35800CN can beused, for example, in the calculation of the Maternity Protection periodaccording to various delivery types. The Maternity Protection period canbe calculated differently, as provided by the national law, for thevarious delivery types.

GDT MaternityProtectionDeliveryTypeCode 35800CN for ‘DE’ (Germany) is asfollows: listID=“10090”, listAgencyID=“310”, listVersionID which is theversion for the current code list administered by SAP AG.

Possible code values for the GDT MaternityProtectionDeliveryTypeCode35800CN are one, two and three. One is for Normal, representing a normaldelivery of a child defined as not premature or stillborn. Two is forPreterm Delivery, representing a premature birth. The premature stillbirth will be considered as a still birth not a premature birth. Threeis for Still Birth, representing a still birth where the child is borndead.

(iiiiiiiiiiiii) MileageReimbursementVehicleClassCode

A GDT MileageReimbursementVehicleClassCode 35800CO is the codedrepresentation of a vehicle class to which the same statutory,contractual, or company-specific expense regulations apply regarding thereimbursement of travel costs. An example of a GDTMileageReimbursementVehicleClassCode 35800CO is:

<MileageReimbursementVehicleClassCode>1</MileageReimbursementVehicleClassCode>

The structure of GDT MileageReimbursementVehicleClassCode 35800CO isdepicted in FIG. 358CO. For the GDT MileageReimbursementVehicleClassCode35800CO, the Object Class is Mileage Reimbursement Vehicle 35802CO, theProperty is Class 35804CO, the Representation/Association is Code35806CO, the Type is CCT 35808CO, the Type Name is Code 35810CO, and theLength is from one to two 35812CO. The remark 35814CO shows that GDTMileageReimbursementVehicleClassCode 35800CO may be restricted.

The GDT MileageReimbursementVehicleClassCode 35800CO may currently beused with business objects.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10358”, listAgencyID which is theID of the Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, and listAgencySchemeAgencyIDwhich is the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

An example for the use of the GDT MileageReimbursementVehicleClassCode35800CO is the legal regulation in Great Britain that stipulates fourclasses. These classes are cars with engines up to 1000 cc, cars withengines from 1001 to 1500 cc. cars with engines from 1501 to 2000 cc,and cars with engines over 2000 cc.

(jjjjjjjjjjjjj) MileageReimbursementVehicleTypeCode

A GDT MileageReimbursementVehicleTypeCode 35800CP is the codedrepresentation of a vehicle type to which the same statutory,contractual, or company-specific expense regulations apply regarding thereimbursement of travel costs. An example of a GDTMileageReimbursementVehicleTypeCode 35800CP is:

<MileageReimbursementVehicleTypeCode>1</MileageReimbursementVehicleTypeCode>

The structure of GDT MileageReimbursementVehicleTypeCode 35800CP isdepicted in FIG. 358CP. For the GDT MileageReimbursementVehicleTypeCode35800CP, the Object Class is Mileage Reimbursement Vehicle 35802CP, theProperty is Type 35804CP, the Representation/Association is Code35806CP, the Type is CCT 35808CP, the Type Name is Code 35810CP, and theLength is from one to two 35812CP. The remark 35814CP shows that GDTMileageReimbursementVehicleTypeCode 35800CP may be restricted.

The GDT MileageReimbursementVehicleTypeCode 35800CP may currently beused with business objects.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10359”, listAgencyID which is theID of the Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, and listAgencySchemeAgencyIDwhich is the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

An example for the use of the GDT MileageReimbursementVehicleTypeCode35800CP is a passenger motor vehicle, which applies to most statutoryexpense regulations. Other examples for the use of the GDTMileageReimbursementVehicleTypeCode 35800CP is the Norwegian law whichincludes other types of transportation means. Examples of these typesinclude a motor scooter, a bicycle, on foot, a passenger motor vehicle,a large boat, a small boat, a motorcycle, other land or water vehicles,and a snowmobile.

(kkkkkkkkkkkkk) NumberingMethodCode

A GDT NumberingMethodCode 35800CQ represents a numbering method in theform of a code.

A numbering method is the way in which numbering takes place. Numberingis understood to mean “the formation, assignment, management and usageof numbers” for numbering objects. Numbering objects, in thisdefinition, can be objects, data carriers, persons or facts. A number,in the context of numbering, is an established sequence of characters,such as letters, digits or special characters. The number created doesnot have to be unique. Therefore, a number can be used several timeswithin a particular numbering method.

Numbering, as described above, is not the same as the numbering of a setin a computability theory. It is also not the same as coding. An exampleof a GDT NumberingMethodCode 35800CQ is:

<NumberingMethodCode>1</NumberingMethodCode>

The structure of GDT NumberingMethodCode 35800CQ is depicted in FIG.358CQ. For the GDT NumberingMethodCode 35800CQ, the Object Class isNumbering 35804CQ, the Property is Method 35806CQ, theRepresentation/Association is Code 35808CQ, the Type is GDT 35810CQ, theType Name is Code 35812CQ and the Length is from one to ten 35814CQ. Theremark 35815CP shows that GDT NumberingMethodCode 35800CQ may berestricted.

For the list Agency ID 35816CQ, the Category is Attribute (A) 34518CQ,the Object Class is Code List Agency 35820CQ, the Property isIdentification 35822CQ, the Representation/Association is Identifier35824CQ, the Type is XSD 35826CQ, and the Type Name is token 35828CQ.The Cardinality is zero or one 35830CQ.

For the list Version ID 35832CQ, the Category is Attribute (A) 34534CQ,the Object Class is Code List 35836CQ, the Property is Version 35838CQ,the Representation/Association is Identifier 35840CQ, the Type is XSD35842CQ, and the Type Name is token 35844CQ. The Cardinality is zero orone 35846CQ.

For the list Agency-Scheme ID 35848CQ, the Category is Attribute (A)34550CQ, the Object Class is Code List Agency 35852CQ, the Property isScheme 35854CQ, the Representation/Association is Identifier 35856CQ,the Type is XSD 35858CQ, and the Type Name is token 35860CQ. TheCardinality is zero or one 35862CQ.

For the list Agency-Scheme Agency ID 35864CQ, the Category is Attribute(A) 34566CQ, the Object Class is Code List Agency 35868CQ, the Propertyis Scheme Agency 35870CQ, the Representation/Association is Identifier35872CQ, the Type is XSD 35874CQ, and the Type Name is token 35876CQ.The Cardinality is zero or one 35878CQ.

There are alternative code lists that differ at configuration and/orruntime. Possible code values for the GDT NumberingMethodCode 35800CQare one, two and three. One represents a Number Range. The number istaken from a number range. The number range is an area in which numbersthat refer to business objects can be assigned. Examples of businessobjects may include business partners, general ledger accounts, orders,posting documents or materials. Every number range consists of one ormore number range intervals. Whether the number is assigned internallyor externally is stated for every number range interval. In the case ofinternal number assignment, the system automatically assigns aconsecutive number that occurs within the relevant number rangeinterval. In the case of external number assignment, the number for theobject is assigned by the user or by an external system. It is importantthat the number occurs in the relevant number range interval. The numberrange object and number range interval constitute the input parametersof the method.

Two represents a Numbering Scheme. The number is created using anumbering scheme. The numbering scheme describes the formal constructionof a classification system with regard to the number of hierarchylevels, as well as the meaning and the numbering of hierarchy elements.The numbering scheme to be used is the input parameter of the method.

Three represents a Universal Unique Identifier (UUID). The number iscreated as a UUID. The method does not have any input parameters.

The attributes have the following values: listID=“10075”,listAgencyID=“310”, and listVersionID is the version of the relevantcode list assigned and managed by SAP AG which is to be determined.

The customer can extend the code list attributes. A list Agency ID35816CQ is the ID of the customer. An ID assigned by an organization maybe used. Examples of this are the business IDs assigned by DUNS, EAN andSWIFT.

A list Version ID 35832CQ is a version of the relevant code list. It isassigned and administered by the customer listed in the list Agency ID35816CQ. A list Agency-Scheme ID 35848CQ is an ID of the scheme by whichthe customer listed in the list Agency ID 35816CQ is identified. It is aparticular identification scheme for partners, businesses, and members,for example DUNS+4, of an administering organization, for example, EAN,DUNS and SWIFT, that is listed in a list Agency-Scheme Agency ID35864CQ. The list Agency-Scheme Agency ID 35864CQ is the ID of theadministering organization, for example DUNS, EAN or SWIFT, that isresponsible for identifying the organization listed in the list AgencyID 35816CQ.

If the numbering method ensures that a number is created only once, thenumber created can be used to identify objects. The GDTNumberingMethodCode 35800CQ can be used to determine the method used fornumbering objects.

An example of the use of the GDT NumberingMethodCode 35800CQ is wherebusiness partner numbers are taken from a number range. In the case ofexternal number assignment, the number is checked against a numberrange. Another example involves product category numbers that can becreated using a numbering scheme (COMM_SCHEMET) that is assigned to theproduct category hierarchy, which determines how it is constructed.

(lllllllllllll) NumberRangeIntervalBusinessPartnerGroupCode

A GDT NumberRangeIntervalBusinessPartnerGroupCode 35800CR is the codedrepresentation of a group of business partners for whom the numbers canbe assigned from the same number range. A number range interval is aninterval of successive alphanumeric characters within a number range.There can be several non-overlapping number range intervals within anumber range. An example of a GDTNumberRangeIntervalBusinessPartnerGroupCode 35800CR is:

<NumberRangeIntervalBusinessPartnerGroupCode>1</NumberRangeIntervalBusinessPartnerGroupCode>

The structure of GDT NumberRangeIntervalBusinessPartnerGroupCode 35800CRis depicted in FIG. 358CR. For the GDTNumberRangeIntervalBusinessPartnerGroupCode 35800CR, the Object ClassQualifier is Number Range Interval 35802CR, the Object Class is BusinessPartner Group 35804CR, the Representation/Association is Code 35806CR,the Type is CCT 35808CR, the Type Name is Code 35810CR, and the Lengthis from one to four 35812CR. The remark 35814CR shows that GDTNumberRangeIntervalBusinessPartnerGroupCode 35800CR may be restricted.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10360”, listAgencyID which is theID of the Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, and listAgencySchemeAgencyIDwhich is the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

Examples of the codes for the GDT

NumberRangeIntervalBusinessPartnerGroupCode 35800CR may be majorcustomers and legacy customers. Major customers are major customers withinternal number assignment. Legacy customers are legacy customers withexternal number assignment.

The following dictionary objects can be assigned to this GDT in mySAPsystems, the

Data element: BU_GROUP.

(mmmmmmmmmmmmm) OccupationCode

A GDT OccupationCode 35800CS represents the occupation of a person inthe form of a code. An example of a GDT OccupationCode 35800CS is:

<OccupationCode>1</OccupationCode>

The structure of GDT OccupationCode 35800CS is depicted in FIG. 358CS.For the GDT OccupationCode 35800CS, the Property is Occupation 35802CS,the Representation/Association is Code 35804CS, the Type is CCT 35806CS,the Type Name is Code 35808CS and the Length is from one to four35810CS. The remark 35812CS shows that GDT OccupationCode 35800CS may berestricted.

For the list ID 35814CS, the Category is Attribute (A) 34516CS, theObject Class is Code List 35818CS, the Property is Identification35820CS, the Representation/Association is Identifier 35822CS, the Typeis XSD 35824CS, and the Type Name is token 35826CS. The Cardinality iszero or one 35828CS.

For the list Agency ID 35830CS, the Category is Attribute (A) 34532CS,the Object Class is Code List Agency 35834CS, the Property isIdentification 35836CS, the Representation/Association is Identifier35838CS, the Type is XSD 35840CS, and the Type Name is token 35842CS.The Cardinality is zero or one 35844CS.

For the list Version ID 35846CS, the Category is Attribute (A) 34548CS,the Object Class is Code List 35850CS, the Property is Version 35852CS,the Representation/Association is Identifier 35854CS, the Type is XSD35856CS, and the Type Name is token 35858CS. The Cardinality is zero orone 35860CS.

For the list Agency-Scheme ID 35862CS, the Category is Attribute (A)34564CS, the Object Class is Code List Agency 35866CS, the Property isScheme 35868CS, the Representation/Association is Identifier 35870CS,the Type is XSD 35872CS, and the Type Name is token 35874CS. TheCardinality is zero or one 35876CS.

For the list Agency-Scheme Agency ID 35878CS, the Category is Attribute(A) 34580CS, the Object Class is Code List Agency 35882CS, the Propertyis Scheme Agency 35884CS, the Representation/Association is Identifier35886CS, the Type is XSD 35888CS, and the Type Name is token 35890CS.The Cardinality is zero or one 35892CS.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10362”, listAgencyID which is theID of the Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, and listAgencySchemeAgencyIDwhich is the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

Examples of the GDT OccupationCode 35800CS are teacher and student. Thecode is set to teacher if the person is a teacher. The code is set tostudent if the person is a student.

(nnnnnnnnnnnnn) CreditCommitmentTypeCode

A GDT CreditCommitmentTypeCode 35800CT is a coded representation of thetype of a payment obligation (liability). An example of GDTCreditCommitmentTypeCode 35800CT is:

<CreditCommitmentTypeCode>001</CreditCommitmentTypeCode>

The structure of GDT CreditCommitmentTypeCode 35800CT is depicted inFIG. 358CT. For the GDT CreditCommitmentTypeCode 35800CT, the ObjectClass is Credit Commitment 35804CT, the Property is Type 35806CT, theRepresentation/Association is Code 35808CT, the Type is CCT 35810CT, theType Name is Code 35812CT, and the Length is three 35814CT.

The data type GDT CreditCommitmentTypeCode 35800CT may be used to informcentral credit management about the type of payment obligation. The datatype GDT CreditCommitmentTypeCode 35800CT may use the following codes:001 (i.e., liability from a sales order), 002 (i.e., liability from anaccounting open item, for example, a receivable from delivery andservice), 003 (i.e., liability from a special general ledgertransaction, for example, a down payment or collateral), 004 (i.e.,liability from a delivery), 005 (i.e., liability from a billingdocument).

The CreditCommitmentTypeCode is an SAP proprietary code list with fixedpredefined values. Changes to the permitted values involve changes tothe interface. This code list corresponds to the entries in tableUKM_COMM_TYPE in SAP FSCM Credit Management.

(ooooooooooooo) CurrencyUsageCode

A GDT CurrencyUsageCode 35800CU is a coded representation of how acurrency can be used. An example of GDT CurrencyUsageCode 35800CU is:

<CurrencyUsageCode>1</CurrencyUsageCode>

The structure of GDT CurrencyUsageCode 35800CU is depicted in FIG.358CU. For the GDT CurrencyUsageCode 35800CU, the Property is CurrencyUsage 35806CU, the Representation/Association is Code 35808CU, the Typeis CCT 35810CU, the Type Name is Code 35812CU, and the Length is fromone to three 35814CU. The remark 35818CU shows that the GDTCurrencyUsageCode 35800CU may be restricted.

The data type GDT CurrencyUsageCode 35800CU is a fixed code list. Theattributes listID=“10051”, listAgencyID=“310”, listVersionID=(to bedefined) are missing in the structure as they would be filled withconstant values at run-time. The data type GDT CurrencyUsageCode 35800CUmay use the following codes: 1 (i.e., a currency can be used for thepayment of wages), 2 (i.e., a currency can be used for transactions withcustomers or vendors).

(ppppppppppppp) CustomerPriceListTypeCode

A GDT CustomerPriceListTypeCode 35800CV is a coded representation of aprice list type for customers. For example, a price list type maydescribe the underlying structure of a price list according to itscharacteristic usage. An example of GDT CustomerPriceListTypeCode35800CV is:

<CustomerPriceListTypeCode>1</CustomerPriceListTypeCode>

The structure of GDT CustomerPriceListTypeCode 35800CV is depicted inFIG. 358CV. For the GDT CustomerPriceListTypeCode 35800CV, the ObjectClass is Customer Price List Type 35804CV, theRepresentation/Association is Code 35808CV, the Type is CCT 35810CV, theType Name is Code 35812CV, and the Length is from one to two 35814CV.The remark 35818CV shows that the GDT CustomerPriceListTypeCode 35800CVmay be restricted.

The data type GDT CustomerPriceListTypeCode 35800CV may use thefollowing codes: Wholesale (i.e., the price list is for wholesalecustomers), Retail (i.e., the price list is for retail customers),Public Sector (i.e., the price list is for public sector customers),Internet (i.e., the price list is for internet sales).

A customer-specific code list is assigned to the code. A customer maydetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10336,” listAgencyID—ID of theCustomer (ID from DE 3055, if listed there), listVersionID—version ofthe particular code list. Assigned and managed by the Customer,listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055, and listAgencySchemeAgencyID—ID of the organization fromDE 3055 that manages the listAgencySchemeID scheme.

In messages, CustomerPriceListTypeCode 35800CV may be used when bothsender and recipient have access to shared or harmonized BusinessConfiguration, for example, during internal communication in anenterprise.

The data type CustomerPriceListTypeCode may be used to define price listtype for customers based on price lists that have the same features.Examples for semantics of the code are: Wholesale—the price list is forwholesale customers, Retail—the price list is for retail customers,Public sector—the price list is for public sector customers orInternet—the price list is for internet sales.

(qqqqqqqqqqqqq) DataOriginTypeCode

A GDT DataOriginTypeCode 35800CW is a coded description of where thedata originates. An example of GDT DataOriginTypeCode 35800CW is:

<DataOriginTypeCode>1</DataOriginTypeCode>

The structure of GDT DataOriginTypeCode 35800CW is depicted in FIG.358CW. For the GDT DataOriginTypeCode 35800CW, the Property Qualifier isData 35802CW, the Property is Origin Type 35803CW, theRepresentation/Association is Code 35804CW, the Type is CCT 35805CW, theType Name is Code 35806CW, and the Length is from one to four 35807CW.The remark 35809CW shows that the GDT DataOriginTypeCode 35800CW may berestricted.

For the ListID 35810CW, the Category is Attribute (A) 35811CW, theObject Class is CodeList 35812CW, the Property is Identification35813CW, the Representation/Association is Identifier 35814CW, the Typeis XSD 35815CW, the Type Name is Token 35816CW, and the Cardinality iszero or one 35818CW.

For the ListAgencyID 35820CW, the Category is Attribute (A) 35821CW, theObject Class is CodeListAgency 35822CW, the Property is Identification35823CW, the Representation/Association is Identifier 35824CW, the Typeis XSD 35825CW, the Type Name is Token 35826CW, and the Cardinality iszero or one 35828CW.

For the ListVersionID 35830CW, the Category is Attribute (A) 35831CW,the Object Class is CodeList 35832CW, the Property is Version 35833CW,the Representation/Association is Identifier 35834CW, the Type is XSD35835CW, the Type Name is Token 35836CW, and the Cardinality is zero orone 35838CW.

For the ListAgency-SchemeID 35840CW, the Category is Attribute (A)35841CW, the Object Class is CodeListAgency 35842CW, the Property isScheme 35843CW, the Representation/Association is Identifier 35844CW,the Type is XSD 35845CW, the Type Name is Token 35846CW, and theCardinality is zero or one 35848CW.

For the ListAgency-SchemeAgencyID 35850CW, the Category is Attribute (A)35851CW, the Object Class is CodeListAgency 35852CW, the Property isSchemeAgency 35853CW, the Representation/Association is Identifier35854CW, the Type is XSD 35855CW, the Type Name is Token 35856CW, andthe Cardinality is zero or one 35858CW.

The data type GDT DataOriginTypeCode 35800CW may use the followingcodes: legacy data transfer (i.e., the data comes from the transfer oflegacy data), address purchase (i.e., the data comes from the purchaseof addresses).

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10337,” listAgencyID—ID of theCustomer (ID from DE 3055, if listed there), listVersionID—version ofthe particular code list. Assigned and managed by the Customer,listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055, and listAgencySchemeAgencyID—ID of the organization fromDE 3055 that manages the listAgencySchemeID scheme.

The DataOriginTypeCode 35800CW can be used to display the origin of thedata that is saved in a data processing system. Examples of the possiblesemantics of the codes are: Legacy data transfer where the data comesfrom the transfer of legacy data and Address purchase where the datacomes from the purchase of addresses.

The following dictionary objects can be assigned to this GDT in mySAPsystems: Data element: BU_SOURCE and Domain: BU_SOURCE.

(rrrrrrrrrrrrr) DebitCreditCode

A GDT DebitCreditCode 35800CX is a coded representation of a credit ordebit side of an account. An example of GDT DebitCreditCode 35800CX is:

<DebitCreditCode>1</DebitCreditCode>

The structure of GDT DebitCreditCode 35800CX is depicted in FIG. 358CX.For the GDT DebitCreditCode 35800CX, the Object Class is Debit Credit35804CX, the Representation/Association is Code 35808CX, the Type is CCT35810CX, the Type Name is Code 35812CX, and the Length is one 35814CX.The remark 35818CX shows that the GDT DebitCreditCode 35800CX may berestricted.

The data type GDT DebitCreditCode 35800CX may use the following codes: 1(i.e., Debit), 2 (i.e., Credit). The DebitCreditCode 35800CX may be usedfor a G/L account posting, for example, to denote whether an amount isposted to the G/L account as a credit or a debit posting. TheDebitCreditCode may be used for a G/L account posting, for example, todenote whether an amount is posted to the G/L account as a credit or adebit posting.

(sssssssssssss) DisabledPersonCertificateTypeCode

A GDT DisabledPersonCertificateTypeCode 35800CY is a code indicating thetype of certificate relating to a person's disability. An example of GDTDisabledPersonCertificateTypeCode 35800CY is:

<DisabledPersonCertificateTypeCode>4</DisabledPersonCertificateTypeCode>

The structure of GDT DisabledPersonCertificateTypeCode 35800CY isdepicted in FIG. 358CY. For the GDT DisabledPersonCertificateTypeCode35800CY, the Object Class is DisabledPersonCertificate 35804CY, theProperty is Type 35806CY, the Representation/Association is Code35808CY, the Type is CCT 35810CY, the Type Name is Code 35812CY, and theLength is from one to two 35814CY. The remark 35818CY shows that the GDTDisabledPersonCertificateTypeCode 35800CY may be restricted.

The data type GDT DisabledPersonCertificateTypeCode 35800CY may use thefollowing codes: 1 (i.e., this certificate is an ID for a severedisability or a letter documenting the recognized disability), 2 (i.e.,this certificate is a letter documenting that the person is on a parwith a disabled person), 3 (i.e., this certificate is a letterdocumenting that a disabled person can be calculated several times), 4(i.e., this certificate is a letter documenting that the person is orhas been a miner and has a disability). TheDisabledPersonCertificateTypeCode 35800CY may be used in PersonnelAdministration to fulfill the employer's legal obligations with regardto the contributions for severely disabled persons, for example, in acountry such as Germany.

The attributes of the code list are as follows: listID=“10048”,listAgencyID=“310” and listVersionID—Version of the relevant code list.Assigned and managed by SAP AG.

(ttttttttttttt) DisabledPersonStatisticExceptionReasonCode

A GDT DisabledPersonStatisticExceptionReasonCode 35800CZ is a codeindicating the reason for an exception when entering the statistic datafor a disabled person. An example of GDTDisabledPersonStatisticExceptionReasonCode 35800CZ is:

<DisabledPersonStatisticExceptionReasonCode>3</DisabledPersonStatisticExceptionReasonCode>

The structure of GDT DisabledPersonStatisticExceptionReasonCode 35800CZis depicted in FIG. 358CZ. For the GDTDisabledPersonStatisticExceptionReasonCode 35800CZ, the Object Class isDisabled Person 35804CZ, the Property is Statistic Exception Reason35806CZ, the Representation/Association is Code 35808CZ, the Type is CCT35810CZ, the Type Name is Code 35812CZ, and the Length is from one totwo 35814CZ. The remark 35818CZ shows that the GDTDisabledPersonStatisticExceptionReasonCode 35800CZ may be restricted.

The data type GDT DisabledPersonStatisticExceptionReasonCode 35800CZ mayuse the following codes: 1 (i.e., the employer, natural person, isexcluded from the statistical data entry if the employer is severelydisabled), 2 (i.e., disabled persons who participate in measures in thecompany for rehabilitation purposes are excluded from the statisticaldata entry), 3 (i.e., persons who can only work part-time for less than18 hours due to their severe disability are excluded from thestatistical data entry), 4 (i.e., persons who are severely disabled andare employed for re-familiarization purposes are excluded from thestatistical data entry), 5 (i.e., persons who were selected aftercontinual practice in their jobs are excluded from the statistical dataentry), 6 (i.e., persons who are severely disabled and are entitled to ajob are excluded from the statistical data entry), 7 (i.e., persons whoare severely disabled and participate in job-creating measures areexcluded from the statistical data entry), 8 (i.e., persons who areseverely disabled and are in a work relationship that does not serveprimarily as an acquisition but rather is motivated predominantly forcharitable reasons are excluded from the statistical data entry), 9(i.e., persons who are severely disabled and are in a work relationshipthat does not serve primarily as an acquisition but rather is motivatedpredominantly for religious reasons are excluded from the statisticaldata entry), 10 (i.e., persons who are severely disabled and are in awork relationship that lasts for a maximum of eight weeks and only ifnot employed marginally or for a short time) are excluded from thestatistical data entry), 11 (i.e., severely disabled persons that arenot relevant for the survey are excluded from the statistical dataentry), 12 (i.e., severely disabled persons are excluded from thestatistical data entry if their part-time job may be attributed as awork center and position reserved for severely disabled persons), 13(i.e., severely disabled persons are excluded from the statistical dataentry if their work relationship is suspended due to military ornon-military service, parental leave, or unpaid leave, or due to drawinga temporary annuity or during semiretirement in the release phase,provided that a replacement employee is hired for them), 14 (i.e.,severely disabled persons whose work relationship is defined in Creationof Employment Opportunities of the Federal Social Security Act, BSHG,are excluded from the statistical data entry), 15 (i.e., severelydisabled persons are excluded from the statistical data entry if theyhave a short-term work relationship for which a position reserved forseverely disabled persons is specified).

There are exception rules that apply for certain person groups whencreating statistics. For example, severely disabled employees, who areonly allowed to work part-time (less than 18 hours/week) due to theirdisability, are processed differently for statutory statisticalpurposes. The DisabledPersonStatisticExceptionReasonCode 35800CZ can beused to describe these exceptions.

(uuuuuuuuuuuuu) DisabledPersonWorkCapabilityLimitationCode

A GDT DisabledPersonWorkCapabilityLimitationCode 35800DA is a codedrepresentation of the limitation of a disabled person's work capability.An example of GDT DisabledPersonWorkCapabilityLimitationCode 35800DA is:

<DisabledPersonWorkCapabilityLimitationCode listID=4711listAgencyID=310>1</DisabledPersonWorkCapabilityLimitationCode>

The structure of GDT DisabledPersonWorkCapabilityLimitationCode 35800DAis depicted in FIG. 358DA. For the GDTDisabledPersonWorkCapabilityLimitationCode 35800DA, the Object Class isDisabled Person 35801DA, the Property is Work Capability Limitation35803DA, the Representation/Association is Code 35804DA, the Type is CCT35805DA, the Type Name is Code 35806DA, and the Length is from one totwo 35807DA. The remark 35809DA shows that the GDTDisabledPersonWorkCapabilityLimitationCode 35800DA may be restricted.

For the ListID 35810DA, the Category is Attribute (A) 35811DA, theObject Class is CodeList 35812DA, the Property is Identification35813DA, the Representation/Association is Identifier 35814DA, the Typeis XSD 35815DA, the Type Name is Token 35816DA, and the Cardinality iszero or one 35818DA.

For the ListAgencyID 35820DA, the Category is Attribute (A) 35821DA, theObject Class is CodeListAgency 35822DA, the Property is Identification35823DA, the Representation/Association is Identifier 35824DA, the Typeis XSD 35825DA, the Type Name is Token 35826DA, and the Cardinality iszero or one 35828DA.

For the ListVersionID 35830DA, the Category is Attribute (A) 35831DA,the Object Class is CodeList 35832DA, the Property is Version 35833DA,the Representation/Association is Identifier 35834DA, the Type is XSD35835DA, the Type Name is Token 35836DA, and the Cardinality is zero orone 35838DA.

For the ListAgency-SchemeID 35840DA, the Category is Attribute (A)35841DA, the Object Class is CodeListAgency 35842DA, the Property isScheme 35843DA, the Representation/Association is Identifier 35844DA,the Type is XSD 35845DA, the Type Name is Token 35846DA, and theCardinality is zero or one 35848DA.

For the ListAgency-SchemeAgencyID 35850DA, the Category is Attribute (A)35851DA, the Object Class is CodeListAgency 35852DA, the Property isSchemeAgency 35853DA, the Representation/Association is Identifier35854DA, the Type is XSD 35855DA, the Type Name is Token 35856DA, andthe Cardinality is zero or one 35858DA.

The data type GDT DisabledPersonWorkCapabilityLimitationCode 35800DA mayuse the following codes: 1 (i.e., the person's work capability is notlimited), 2 (i.e., the person's work capability is not limited), 3(i.e., the person can only work in a seated position).

(vvvvvvvvvvvvv) DisagioDeductionEventTypeCode

A GDT DisagioDeductionEventTypeCode 35800DB is a coded representation ofa group of house banks based on the viewpoint of a similar determinationof accounts in accounting. For example, the entities may be. An exampleof GDT DisagioDeductionEventTypeCode 35800DB is:

<DisagioDeductionEventTypeCode>1</DisagioDeductionEventTypeCode>

The structure of GDT DisagioDeductionEventTypeCode 35800DB is depictedin FIG. 358DB. For the GDT DisagioDeductionEventTypeCode 35800DB, theObject Class is Disagio 35804DB, the Property is Deduction Event Type35806DB, the Representation/Association is Code 35808DB, the Type is CCT35810DB, the Type Name is Code 35812DB, and the Length is from one totwo 35814DB. The remark 35818DB shows that the GDTDisagioDeductionEventTypeCode 35800DB may be restricted.

The data type GDT DisagioDeductionEventTypeCode 35800DB may use thefollowing codes: 1 (i.e., the disagio deduction is made with the firstpartial disbursement of a loan), 2 (i.e., the disagio deduction is madeproportionally for each partial disbursement of a loan), 3 (i.e., thedisagio deduction is made with the last partial disbursement of a loan).The DisagioDeductionEventTypeCode may be used in the context of loancontracts.

The DisagioDeductionEventTypeCode uses an SAP proprietary code list withpredefined values. In the SAP ERP system the DisagioDeductionTypeCode isbased on the data element SDISEIN in the software component EA-FINSERV.

(wwwwwwwwwwwww) DisagioPercent

A GDT DisagioPercent 35800DC is a percentage amount by which theexchange rate of a security or loan commitment capital, or the parity ofa currency lies below the nominal value. An example of GDTDisagioPercent 35800DC is:

<DisagioPercent>2.5</DisagioPercent>

The structure of GDT DisagioPercent 35800DC is depicted in FIG. 358DC.For the GDT DisagioPercent 35800DC, the Category is Element (E) 35802DC,the Object Class is Disagio 35804DC, the Representation/Association isPercent 35808DC, the Type is GDT 35810DC, the Type Name is Percent35812DC, and the Length is a maximum of three digits with three placesafter the decimal point 35814DC. The remark 35818DC shows that the GDTDisagioPercent 35800DC may be restricted.

The DisagioPercent 35800DC is stated as a positive percentage. TheDisagioPercent 35800DC may be used to calculate either the disbursementobligation for a loan granted or the exchange rate of a security.

(xxxxxxxxxxxxx) DistributionChannelCode

A GDT DistributionChannelCode 35800DD is a coded representation of adistribution channel. For example, a distribution channel may be achannel via which goods or services reach the customer. An example ofGDT DistributionChannelCode 35800DD is:

<DistributionChannelCode>1</DistributionChannelCode>

The structure of GDT DistributionChannelCode 35800DD is depicted in FIG.358DD. For the GDT DistributionChannelCode 35800DD, the Object Class isDistribution Channel 35801DD, the Representation/Association is Code35804DD, the Type is CCT 35805DD, the Type Name is Code 35806DD, and theLength is from one to two 35807DD. The remark 35809DD shows that the GDTDistributionChannelCode 35800DD may be restricted.

For the ListID 35810DD, the Category is Attribute (A) 35811DD, theObject Class is CodeList 35812DD, the Property is Identification35813DD, the Representation/Association is Identifier 35814DD, the Typeis XSD 35815DD, the Type Name is Token 35816DD, and the Cardinality iszero or one 35818DD.

For the ListAgencyID 35820DD, the Category is Attribute (A) 35821DD, theObject Class is CodeListAgency 35822DD, the Property is Identification35823DD, the Representation/Association is Identifier 35824DD, the Typeis XSD 35825DD, the Type Name is Token 35826DD, and the Cardinality iszero or one 35828DD.

For the ListVersionID 35830DD, the Category is Attribute (A) 3583 IDD,the Object Class is CodeList 35832DD, the Property is Version 35833DD,the Representation/Association is Identifier 35834DD, the Type is XSD35835DD, the Type Name is Token 35836DD, and the Cardinality is zero orone 35838DD.

For the ListAgency-SchemeID 35840DD, the Category is Attribute (A)35841DD, the Object Class is CodeListAgency 35842DD, the Property isScheme 35843DD, the Representation/Association is Identifier 35844DD,the Type is XSD 35845DD, the Type Name is Token 35846DD, and theCardinality is zero or one 35848DD.

For the ListAgency-SchemeAgencyID 35850DD, the Category is Attribute (A)35851DD, the Object Class is CodeListAgency 35852DD, the Property isSchemeAgency 35853DD, the Representation/Association is Identifier35854DD, the Type is XSD 35855DD, the Type Name is Token 35856DD, andthe Cardinality is zero or one 35858DD.

The data type GDT DistributionChannelCode 35800DD may use the followingcodes: Retail Sales (i.e., goods or services reach the customer via thedistribution channel “Retail Sales”), Direct Sales (i.e., goods orservices reach the customer via the distribution channel “DirectSales”), Internet Sales (i.e., goods or services reach the customer viathe distribution channel “Internet Sales”).

(yyyyyyyyyyyyy) DivisionCode

A GDT DivisionCode 35800DE is a coded representation of a division. Forexample, a division may define the responsibility for sales or profitsfor salable materials or services. An organizational unit may have adivision; however, a division is not an organizational unit. An exampleof GDT DivisionCode 35800DE is:

<DivisionCode>1</DivisionCode>

The structure of GDT DivisionCode 35800DE is depicted in FIG. 358DE. Forthe GDT DivisionCode 35800DE, the Object Class is Division 35801DE, theRepresentation/Association is Code 35804DE, the Type is CCT 35805DE, theType Name is Code 35806DE, and the Length is from one to two 35807DE.The remark 35809DE shows that the GDT DivisionCode 35800DE may berestricted.

For the ListID 35810DE, the Category is Attribute (A) 35811DE, theObject Class is CodeList 35812DE, the Property is Identification35813DE, the Representation/Association is Identifier 35814DE, the Typeis XSD 35815DE, the Type Name is Token 35816DE, and the Cardinality iszero or one 35818DE.

For the ListAgencyID 35820DE, the Category is Attribute (A) 35821DE, theObject Class is CodeListAgency 35822DE, the Property is Identification35823DE, the Representation/Association is Identifier 35824DE, the Typeis XSD 35825DE, the Type Name is Token 35826DE, and the Cardinality iszero or one 35828DE.

For the ListVersionID 35830DE, the Category is Attribute (A) 35831DE,the Object Class is CodeList 35832DE, the Property is Version 35833DE,the Representation/Association is Identifier 35834DE, the Type is XSD35835DE, the Type Name is Token 35836DE, and the Cardinality is zero orone 35838DE.

For the ListAgency-SchemeID 35840DE, the Category is Attribute (A)35841DE, the Object Class is CodeListAgency 35842DE, the Property isScheme 35843DE, the Representation/Association is Identifier 35844DE,the Type is XSD 35845DE, the Type Name is Token 35846DE, and theCardinality is zero or one 35848DE.

For the ListAgency-SchemeAgencyID 35850DE, the Category is Attribute (A)35851DE, the Object Class is CodeListAgency 35852DE, the Property isSchemeAgency 35853DE, the Representation/Association is Identifier35854DE, the Type is XSD 35855DE, the Type Name is Token 35856DE, andthe Cardinality is zero or one 35858DE.

The data type GDT DivisionCode 35800DE may use the following codes: cars(i.e., division for the sale of cars), trucks (i.e., division for thesale of trucks), buses (i.e., division for the sale of buses). Acustomer-specific code list is assigned to the DivisionCode. A customerdefines the codes in the code list.

The attributes of DivisionCode can be assigned the following values:listID=“10114,” listAgencyID—ID of the Customer (ID from DE 3055 iflisted there), listVersionID—Assigned and managed by the Customer,listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055, and listAgencySchemeAgencyID—ID of the organization (takenfrom DE 3055) that manages the scheme of the listAgencySchemeID.

(zzzzzzzzzzzzz) DueCategoryCode

A GDT DueCategoryCode 35800DF is a coded representation of the category(receivable or payable) of an item due for payment. An example of GDTDueCategoryCode 35800DF is:

<DueCategoryCode>1</DueCategoryCode>

The structure of GDT DueCategoryCode 35800DF is depicted in FIG. 358DF.For the GDT DueCategoryCode 35800DF, the Object Class is Due 35804DF,the Property is Category 35806DF, the Representation/Association is Code35808DF, the Type is CCT 35810DF, the Type Name is Code 35812DF, and theLength is one 35814DF. The remark 35818DF shows that the GDTDueCategoryCode 35800DF may be restricted.

The data type GDT DueCategoryCode 35800DF may use the following codes: 1(i.e., a payable is debts incurred either as a result of a serviceclaimed or a down payment or an incoming payment), 2 (i.e., a receivableis the claim to payment for a service provided). The DueCategoryCode35800DF can be used in DueItemManagement to differentiate an item duefor payment by receivables and payables.

(aaaaaaaaaaaaaa) DurationValueRecurrence

A GDT DurationValueRecurrence 35800DG is a representation for a numberof recurrences within a time frame. For example, two recurrences in onemonth or eight recurrences in 50 days. An example of GDTDurationValueRecurrence 35800DG is: <DurationValueRecurrence>  <Duration>P7D</Duration>   <Value>1</Value> </DurationValueRecurrence>

The structure of GDT DurationValueRecurrence 35800DG is depicted in FIG.358DG. For the GDT DurationValueRecurrence 35800DG, the Object Class isDurationValueRecurrence 35801DG, and the Representation/Association isDetails 35804DG.

For the Duration 35810DG, the Object Class is DurationValueRecurrence35812DG, the Property is Duration 35813DG, theRepresentation/Association is Duration 35814DG, the Type is GDT 35815DG,the Type Name is Duration 35816DG, and the Cardinality is one 35818DG.

For the Value 35820DG, the Object Class is DurationValueRecurrence35822DG, the Property is Value 35823DG, the Representation/Associationis Value 35824DG, the Type is GDT 35825DG, the Type Name is IntegerValue 35826DG, the Length is from one to three 35827DG, and theCardinality is one 35828DG.

The Duration 35810DG indicates the time frame within which the specifiednumber of recurrences takes place. The Value 35820DG is the number ofrecurrences (in terms of the time frame).

(bbbbbbbbbbbbbb) EffectiveYieldCalculationMethodCode

A GDT EffectiveYieldCalculationMethodCode 35800DH is a codedrepresentation of the method for calculating the effective interestrate. For example, the effective interest rate indicates the actualprofitability of a capital investment or the actual costs of a loan. Inaddition to the nominal interest rate, other factors such as disagio,fees, and repayment type, are used to calculate the effective interestrate. An example of GDT EffectiveYieldCalculationMethodCode 35800DH is:

<EffectiveYieldCalculationMethodCode>1</EffectiveYieldCalculationMethodCode

The structure of GDT EffectiveYieldCalculationMethodCode 35800DH isdepicted in FIG. 358DH. For the GDT EffectiveYieldCalculationMethodCode35800DH, the Object Class is Effective Yield 35804DH, the Property isCalculation Method 35806DH, the Representation/Association is Code35808DH, the Type is CCT 35810DH, the Type Name is Code 35812DH, and theLength is from one to two 35814DH.

The data type GDT EffectiveYieldCalculationMethodCode 35800DH may usethe following codes: 1 (i.e., effective interest rate calculationaccording to price regulations, PAngV), 2 (i.e., effective interest ratecalculation according to AIBD/ISMA), 3 (i.e., effective interest ratecalculation according to Braess), 4 (i.e., effective interest ratecalculation according to Moosmüller), 5 (i.e., effective interest ratecalculation according to US American method), 6 (i.e., effectiveinterest rate calculation on current daily basis, EU Act/365), 8 (i.e.,effective interest rate calculation on monthly basis, EU 30.42/365), 9(i.e., linear effective interest rate calculation).

(cccccccccccccc) EmployeeTimeAccountLineItemTypeCode

A GDT EmployeeTimeAccountLineItemTypeCode 35800DI is a codedrepresentation of the type of a line item of an employee time accountaccording to criteria resulting from laws, agreements, companyrequirements, control tasks, etc. For example, the line item may containa quantitative change of an employee time account on a certain date. Aline item may be characterized by a type. An example of GDTEmployeeTimeAccountLineItemTypeCode 35800DI is:

<EmployeeTimeAccountLineItemTypeCode>1</EmployeeTimeAccountLineItemTypeCode>

The structure of GDT EmployeeTimeAccountLineItemTypeCode 35800DI isdepicted in FIG. 358DI. For the GDT EmployeeTimeAccountLineItemTypeCode35800DI, the Object Class is EmployeeTimeAccountLineItem 35801DI, theProperty is Type 35803DI, the Representation/Association is Code35804DI, the Type is CCT 35805DI, the Type Name is Code 35806DI, and theLength is from one to six 35807DI. The remark 35809DI shows that the GDTEmployeeTimeAccountLineItemTypeCode 35800DI may be restricted.

For the ListID 35810DI, the Category is Attribute (A) 35811DI, theObject Class is CodeList 35812DI, the Property is Identification35813DI, the Representation/Association is Identifier 35814DI, the Typeis XSD 35815DI, the Type Name is Token 35816DI, the Length is from oneto sixty 35817DI, and the Cardinality is zero or one 35818DI.

For the ListAgencyID 35820DI, the Category is Attribute (A) 35821DI, theObject Class is CodeListAgency 35822DI, the Property is Identification35823DI, the Representation/Association is Identifier 35824DI, the Typeis XSD 35825DI, the Type Name is Token 35826DI, the Length is from oneto sixty 35827DI, and the Cardinality is zero or one 35828DI.

For the ListVersionID 35830DI, the Category is Attribute (A) 35831DI,the Object Class is CodeList 35832DI, the Property is Version 35833DI,the Representation/Association is Identifier 35834DI, the Type is XSD35835DI, the Type Name is Token 35836DI, the Length is from one tofifteen 35837DI, and the Cardinality is zero or one 35838DI.

For the ListAgency-SchemeID 35840DI, the Category is Attribute (A) 35841DI, the Object Class is CodeListAgency 35842DI, the Property is Scheme35843DI, the Representation/Association is Identifier 35844DI, the Typeis XSD 35845DI, the Type Name is Token 35846DI, the Length is from oneto sixty 35847DI, and the Cardinality is zero or one 35848DI.

For the ListAgency-SchemeAgencyID 35850DI, the Category is Attribute (A)35851DI, the Object Class is CodeListAgency 35852DI, the Property isSchemeAgency 35853DI, the Representation/Association is Identifier35854DI, the Type is XSD 35855DI, the Type Name is Token 35856DI, theLength is from one to three 35857DI, and the Cardinality is zero or one35858DI.

The data type GDT EmployeeTimeAccountLineItemTypeCode 35800DI may usethe following codes: deduction (i.e., the type of an employee timeaccount line item that reduces the balance of the account, such as, avacation), entitlement (i.e., the type of an employee time account lineitem that increased the balance of the account, such as, the yearlyentitlement for vacations). The EmployeeTimeAccountLineItemTypeCode35800DI can be used for capturing the semantic meaning of the line itemin the employee time account. This type code defines the business usageof the corresponding data of the line item for other applications aswell. For example, this data may be further used for reporting purposesor for additional business processes like the payroll process.

(dddddddddddddd) EmployeeTimeAccountTypeCode

A GDT EmployeeTimeAccountTypeCode 35800DJ is a coded representation ofthe type of an employee time account according to criteria resultingfrom laws, agreements, company requirements, control tasks, etc. Forexample, an employee time account may be a summary of valuation results.The valuation results may be recorded in employee time accounts in theform of line items. An example of GDT EmployeeTimeAccountTypeCode35800DJ is:

<EmployeeTimeAccountTypeCode>1</EmployeeTimeAccountTypeCode>

The structure of GDT EmployeeTimeAccountTypeCode 35800DJ is depicted inFIG. 358DJ. For the GDT EmployeeTimeAccountTypeCode 35800DJ, the ObjectClass is EmployeeTimeAccount 35801DJ, the Property is Type 35803DJ, theRepresentation/Association is Code 35804DJ, the Type is CCT 35805DJ, theType Name is Code 35806DJ, and the Length is from one to six 35807DJ.The remark 35809DJ shows that the GDT EmployeeTimeAccountTypeCode35800DJ may be restricted.

For the ListID 35810DJ, the Category is Attribute (A) 35811DJ, theObject Class is CodeList 35812DJ, the Property is Identification35813DJ, the Representation/Association is Identifier 35814DJ, the Typeis XSD 35815DJ, the Type Name is Token 35816DJ, the Length is from oneto sixty 35817DJ, and the Cardinality is zero or one 35818DJ.

For the ListAgencyID 35820DJ, the Category is Attribute (A) 35821DJ, theObject Class is CodeListAgency 35822DJ, the Property is Identification35823DJ, the Representation/Association is Identifier 35824DJ, the Typeis XSD 35825DJ, the Type Name is Token 35826DJ, the Length is from oneto sixty 35827DJ, and the Cardinality is zero or one 35828DJ.

For the ListVersionID 35830DJ, the Category is Attribute (A) 35831DJ,the Object Class is CodeList 35832DJ, the Property is Version 35833DJ,the Representation/Association is Identifier 35834DJ, the Type is XSD35835DJ, the Type Name is Token 35836DJ, the Length is from one tofifteen 35837DJ, and the Cardinality is zero or one 35838DJ.

For the ListAgency-SchemeID 35840DJ, the Category is Attribute (A)35841DJ, the Object Class is CodeListAgency 35842DJ, the Property isScheme 35843DJ, the Representation/Association is Identifier 35844DJ,the Type is XSD 35845DJ, the Type Name is Token 35846DJ, the Length isfrom one to sixty 35847DJ, and the Cardinality is zero or one 35848DJ.

For the ListAgency-SchemeAgencyID 35850DJ, the Category is Attribute (A)35851DJ, the Object Class is CodeListAgency 35852DJ, the Property isSchemeAgency 35853DJ, the Representation/Association is Identifier35854DJ, the Type is XSD 35855DJ, the Type Name is Token 35856DJ, theLength is from one to three 35857DJ, and the Cardinality is zero or one35858DJ.

The data type GDT EmployeeTimeAccountTypeCode 35800DJ may use thefollowing codes: paid vacation account (i.e., the type of an employeetime account that holds vacations the employee is paid for), overtimeaccount (i.e., the type of an employee time account that holds workingtimes exceeding the normal working time of an employee), sick leaveaccount (i.e., the type of an employee time account that holds absencescaused by illness).

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10342,” listAgencyID—ID of theCustomer (ID from DE 3055, if listed there), listVersionID—version ofthe particular code list. Assigned and managed by the Customer,listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055 and listAgencySchemeAgencyID—ID of the organization from DE3055 that manages the listAgencySchemeID scheme.

(eeeeeeeeeeeeee) EnterpriseMealsReimbursementExpenseReporterGroupCode

A GDT EnterpriseMealsReimbursementExpenseReporterGroupCode 35800DK is acoded representation of a group of expense reporters to whom the samecompany provisions apply regarding reimbursement of expenses for meals.An example of GDT EnterpriseMealsReimbursementExpenseReporterGroupCode35800DK is:

<EnterpriseMealsReimbursementExpenseReporterGroupCode>1</EnterpriseMealsReimbursementExpenseReporterGroupCode>

The structure of GDTEnterpriseMealsReimbursementExpenseReporterGroupCode 35800DK is depictedin FIG. 358DK. For the GDTEnterpriseMealsReimbursementExpenseReporterGroupCode 35800DK, theProperty is Enterprise_MealsReimbursement_ExpenseReporterGroup 35806DK,the Representation/Association is Code 35808DK, the Type is CCT 35810DK,the Type Name is Code 35812DK, and the Length is from one to two35814DK. The remark 35818DK shows that the GDTEnterpriseMealsReimbursementExpenseReporterGroupCode 35800DK may berestricted.

The data type GDT EnterpriseMealsReimbursementExpenseReporterGroupCode35800DK may use the following codes: frequent traveler (i.e., businesstravelers who travel an average of 10 days per month or more),occasional travelers (i.e., business travelers who travel an average ofless than 10 days per month). ForEnterpriseMealsReimbursementExpenseReporterGroupCode 35800DK there is acorresponding StatutoryMealsReimbursementExpenseReporterGroupCode as acoded representation of a group of expense reporters to whom the samestatutory or agreement-based provisions apply regarding reimbursement ofexpenses for meals.

The attributes of the code are assigned the following values:listID=“10344,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list.Assigned and managed by the Customer, listAgencySchemeID—ID of thescheme if the listAgencyID does not come from DE 3055, andlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme.

(ffffffffffffff) EnterpriseMileageReimbursementExpenseReporterGroupCode

A GDT EnterpriseMileageReimbursementExpenseReporterGroupCode 35800DL isa coded representation of a group of expense reporters to whom the samecompany provisions apply regarding reimbursement of travel costs. Forexample, the entities may be. An example of GDTEnterpriseMileageReimbursementExpenseReporterGroupCode 35800DL is:

<EnterpriseMileageReimbursementExpenseReporterGroupCode>1</EnterpriseMileageReimbursementExpenseReporterGroupCode>

The structure of GDTEnterpriseMileageReimbursementExpenseReporterGroupCode 35800DL isdepicted in FIG. 358DL. For the GDTEnterpriseMileageReimbursementExpenseReporterGroupCode 35800DL, theProperty is Enterprise_MileageReimbursement_ExpenseReporterGroup35806DL, the Representation/Association is Code 35808DL, the Type is CCT35810DL, the Type Name is Code 35812DL, and the Length is from one totwo 35814DL. The remark 35818DL shows that the GDTEnterpriseMileageReimbursementExpenseReporterGroupCode 35800DL may berestricted.

The data type GDT EnterpriseMileageReimbursementExpenseReporterGroupCode35800DL may use the following codes: office employees with private car(i.e., employees who are mainly office-based and use a private car),field employees with private car (i.e., employees who work mainly in thefield and use a private car). ForEnterpriseMileageReimbursementExpenseReporterGroupCode 35800DL there isa corresponding StatutoryMileageReimbursementExpenseReporterGroupCode asa coded representation of a group of expense reporters to whom the samestatutory or agreement-based provisions apply regarding reimbursement ofexpenses for travel costs.

The attributes of the code are assigned the following values:listID=“10344,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list.Assigned and managed by the Customer, listAgencySchemeID—ID of thescheme if the listAgencyID does not come from DE 3055, andlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme.

(gggggggggggggg) ExpenseClassificationFunctionalAreaCode

A GDT ExpenseClassificationFunctionalAreaCode 35800DM is a codedrepresentation of a functional area to which costs can be assigned inthe profit and loss statements using cost of sales accounting(“classification of expenses by function”). For example, a functionalarea may correspond to a subtask involved in achieving the company goal,such as procurement, production, administration, or marketing, and doesnot represent an organizational unit. An example of GDTExpenseClassificationFunctionalAreaCode 35800DM is:

<ExpenseClassificationFunctionalAreaCode>PROD

</ExpenseClassificationFunctionalAreaCode>

The structure of GDT ExpenseClassificationFunctionalAreaCode 35800DM isdepicted in FIG. 358DM. For the GDTExpenseClassificationFunctionalAreaCode 35800DM, the Property isExpenseClassification_Functional Area 35803DM, theRepresentation/Association is Code 35804DM, the Type is CCT 35805DM, theType Name is Code 35806DM, and the Length is from one to four 35807DM.The remark 35809DM shows that the GDTExpenseClassificationFunctionalAreaCode 35800DM may be restricted.

For the ListAgencyID 35810DM, the Category is Attribute (A) 35811DM, theObject Class is CodeListAgency 35812DM, the Property is Identification35813DM, the Representation/Association is Identifier 35814DM, the Typeis XSD 35815DM, the Type Name is Token 35816DM, and the Cardinality iszero or one 35818DM.

For the ListVersionID 35820DM, the Category is Attribute (A) 35821DM,the Object Class is CodeList 35822DM, the Property is Version 35823DM,the Representation/Association is Identifier 35824DM, the Type is XSD35825DM, the Type Name is Token 35826DM, and the Cardinality is zero orone 35828DM.

For the ListAgency-SchemeID 35830DM, the Category is Attribute (A)35831DM, the Object Class is CodeListAgency 35832DM, the Property isScheme 35833DM, the Representation/Association is Identifier 35834DM,the Type is XSD 35835DM, the Type Name is Token 35836DM, and theCardinality is zero or one 35838DM.

For the ListAgency-SchemeAgencyID 35840DM, the Category is Attribute (A)35841DM, the Object Class is CodeListAgency 35842DM, the Property isSchemeAgency 35843DM, the Representation/Association is Identifier35844DM, the Type is XSD 35845DM, the Type Name is Token 35846DM, andthe Cardinality is zero or one 35848DM.

The data type GDT ExpenseClassificationFunctionalAreaCode 35800DM mayuse the following codes: I (i.e., production costs of the activitiesperformed to obtain the sales revenue), 2 (i.e., sales costs), 3 (i.e.,general administration costs).

The data type GDT ExpenseClassificationFunctionalAreaCode 35800DM is anextendable SAP code list. Customers can change this code list. In itsunchanged state, the SAP code list has the following attributes:listID=“10074,” listAgencyID=“310,” and listVersionID=Version of therelevant code list. Assigned and managed by SAP AG.

If A customer makes changes to the SAP code list, the values of theattributes are changed as follows: listAgencyID—ID of the Customer (IDfrom DE 3055 if listed there), listVersionID—Assigned and managed byCustomer, listAgencySchemeID—ID of the scheme if the listAgencyID is nottaken from DE 3055, and listAgencySchemeAgencyID—ID of the organization(taken from DE 3055) that managed the scheme of the listAgencySchemeID

(hhhhhhhhhhhhhh) ExpenseReportActivityStayTypeCode

A GDT ExpenseReportActivityStayTypeCode 35800DN is a codedrepresentation of an activity-specific stay type within an expensereport. For example, an activity-specific stay type may be aclassification within an expense report of stays for a business tripbased on the tasks for which the expense reporter submits an expensereport. An example of GDT ExpenseReportActivityStayTypeCode 35800DN is:

<ExpenseReportActivityStayTypeCode>1</ExpenseReportActivityStayTypeCode>

The structure of GDT ExpenseReportActivityStayTypeCode 35800DN isdepicted in FIG. 358DN. For the GDT ExpenseReportActivityStayTypeCode35800DN, the Object Class is ExpenseReportActivity_StayType 35804DN, theRepresentation/Association is Code 35808DN, the Type is CCT 35810DN, theType Name is Code 35812DN, and the Length is from one to two 35814DN.The remark 35818DN shows that the GDT ExpenseReportActivityStayTypeCode35800DN may be restricted.

The data type GDT ExpenseReportActivityStayTypeCode 35800DN may use thefollowing codes: customer visit (i.e., visiting a customer), seminarvisit (i.e., attending a seminar), trade show visit (i.e., attending atrade show).

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10346,” listAgencyID—ID of theCustomer (ID from DE 3055, if listed there), listVersionID—version ofthe particular code list. Assigned and managed by the Customer,listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055, and listAgencySchemeAgencyID—ID of the organization fromDE 3055 that manages the listAgencySchemeID scheme.

(iiiiiiiiiiiiii) ExpenseReportEnterpriseStayTypeCode

A GDT ExpenseReportEnterpriseStayTypeCode 35800DO is a codedrepresentation of an enterprise-specific stay type within an expensereport. For example, an enterprise-specific stay type may classifywithin an expense report the stays for a business trip based on criteriathat can be defined individually by the company. An example of GDTExpenseReportEnterpriseStayTypeCode 35800DO is:

<ExpenseReportEnterpriseStayTypeCode>1</ExpenseReportEnterpriseStayTypeCode>

The structure of GDT ExpenseReportEnterpriseStayTypeCode 35800DO isdepicted in FIG. 358DO. For the GDT ExpenseReportEnterpriseStayTypeCode35800DO, the Object Class is Expense Report Enterprise_Stay Type35804DO, the Representation/Association is Code 35808DO, the Type is CCT35810DO, the Type Name is Code 35812DO, and the Length is from one totwo 35814DO. The remark 35818DO shows that the GDTExpenseReportEnterpriseStayTypeCode 35800DO may be restricted.

The data type GDT ExpenseReportEnterpriseStayTypeCode 35800DO may usethe following codes: stay on-site (i.e., trip between sites), stay at alocation greater than 100 km from the site, stay at a location 50 to 100km from the site, stay at a location less than 50 km from the site.

The attributes of the code are assigned the following values:listID=“10347,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list.Assigned and managed by the Customer, listAgencySchemeID—ID of thescheme if the listAgencyID does not come from DE 3055 andlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme.

(jjjjjjjjjjjjjj) ExpenseReportExpenseCategoryCode

A GDT ExpenseReportExpenseCategoryCode 35800DP is a coded representationof an expense category within an expense report. For example, an expensecategory may be a collection of expense types based on commonalties inthe settlement procedure, dialog behavior, or statistical evaluation. Anexample of GDT ExpenseReportExpenseCategoryCode 35800DP is:

<ExpenseReportExpenseCategoryCode>2</ExpenseReportExpenseCategoryCode>

The structure of GDT ExpenseReportExpenseCategoryCode 35800DP isdepicted in FIG. 358DP. For the GDT ExpenseReportExpenseCategoryCode35800DP, the Object Class is ExpenseReportExpense 35804DP, the Propertyis Category 35806DP, the Representation/Association is Code 35808DP, theType is CCT 35810DP, the Type Name is Code 35812DP, and the Length isone 35814DP. The remark 35818DP shows that the GDTExpenseReportExpenseCategoryCode 35800DP may be restricted.

The data type GDT ExpenseReportExpenseCategoryCode 35800DP may use thefollowing codes: 1 (i.e., accommodations receipts), 2 (i.e., mealsreceipts), 3 (i.e., travel costs receipts), 4 (i.e., other receipts), 5(i.e., meals receipts whose daily total is compared against a maximumrate).

The value range of the ExpenseReportExpenseCategoryCode is an SAP codelist with fixed, predefined values. The values are listed in theAppendix. The attributes of the CCT Code are filled implicitly with thefollowing values: listID=“0083,” listAgencyID=“310,” andlistVersionID—Version of the code list. Assigned and administered by SAPAG.

(kkkkkkkkkkkkkk) ExpenseReportExpenseTypeCode

A GDT ExpenseReportExpenseTypeCode 35800DQ is a coded representation ofan expense type within an expense report. For example, an expense typemay be a classification of the expenses of an expense reporter based oncommonalties in the settlement procedure, dialog behavior, paymentbehavior, posting behavior, or statistical evaluation. An example of GDTExpenseReportExpenseTypeCode 35800DQ is:

<ExpenseReportExpenseTypeCode>HOTL</ExpenseReportExpenseTypeCode>

The structure of GDT ExpenseReportExpenseTypeCode 35800DQ is depicted inFIG. 358DQ. For the GDT ExpenseReportExpenseTypeCode 35800DQ, the ObjectClass is ExpenseReportExpense 35804DQ, the Property is Type 35806DQ, theRepresentation/Association is Code 35808DQ, the Type is CCT 35810DQ, theType Name is Code 35812DQ, and the Length is from one to four 35814DQ.The remark 35818DQ shows that the GDT ExpenseReportExpenseTypeCode35800DQ may be restricted.

The data type GDT ExpenseReportExpenseTypeCode 35800DQ may use thefollowing codes: train (i.e., train ticket), gasoline (i.e., gasolinereceipt), entertainment (i.e., entertainment receipt), flight (i.e.,airline receipt), hotel (i.e., hotel receipt), rental car (i.e., rentalcar receipt), parking fee, postage, private share to be paid back to thecompany, other (i.e., other receipt), taxi (i.e., taxi receipt),telephone (i.e., telephone receipt), tip, toll sticker, visa.

The attributes of the code are assigned the following values:listID=“10348,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list.Assigned and managed by the Customer, listAgencySchemeID—ID of thescheme if the listAgencyID does not come from DE 3055, andlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme.

(llllllllllllll) ExpenseReportID

A GDT ExpenseReportID 35800DR is an identifier for an expense report ofan expense reporter. An example of GDT ExpenseReportID 35800DR is:

<ExpenseReportID>8021963</ExpenseReportID>

The structure of GDT ExpenseReportID 35800DR is depicted in FIG. 358DR.For the GDT ExpenseReportID 35800DR, the Object Class is ExpenseReport35804DR, the Property is Identification 35806DR, theRepresentation/Association is Identifier 35808DR, the Type is CCT35810DR, the Type Name is Identifier 35812DR, and the Length is from oneto ten 35814DR. The remark 35818DR shows that the GDT ExpenseReportID35800DR may be restricted. An ExpenseReportID 35800DR may be representedas a 10-digit number.

(mmmmmmmmmmmmmm) ExpenseReportItinerarySegmentID

A GDT ExpenseReportItinerarySegmentID 35800DS is a unique identifier fora segment of an itinerary within an expense report. For example, asegment of an itinerary may specify the arrival time at a destination,or another time relevant to settlement, within a business trip of anexpense reporter. An example of GDT ExpenseReportItinerarySegmentID35800DS is:

<ExpenseReportItinerarySegmentID>1</ExpenseReportItinerarySegmentID>

The structure of GDT ExpenseReportItinerarySegmentID 35800DS is depictedin FIG. 358DS. For the GDT ExpenseReportItinerarySegmentID 35800DS, theObject Class is ExpenseReportItinerarySegment 35804DS, the Property isIdentification 35806DS, the Representation/Association is Identifier35808DS, the Type is CCT 35810DS, the Type Name is Identifier 35812DS,and the Length is from one to three 35814DS. The remark 35818DS showsthat the GDT ExpenseReportItinerarySegmentID 35800DS may be restricted.An ExpenseReportItinerarySegmentID 35800DS may be represented as athree-digit number.

(nnnnnnnnnnnnnn) ExpenseReportItinerarySegmentTypeCode

A GDT ExpenseReportItinerarySegmentTypeCode 35800DT is a codedrepresentation of a segment type of an itinerary within an expensereport. For example, a segment type of an itinerary may be aclassification of the segments of an itinerary based on statutory orbusiness criteria. A segment of an itinerary may specify the arrivaltime at a destination, or another time relevant to settlement, within abusiness trip of an expense reporter. An example of GDTExpenseReportItinerarySegmentTypeCode 35800DT is:

<ExpenseReportItinerarySegmentTypeCode>1</ExpenseReportItinerarySegmentTypeCode>

The structure of GDT ExpenseReportItinerarySegmentTypeCode 35800DT isdepicted in FIG. 358DT. For the GDTExpenseReportItinerarySegmentTypeCode 35800DT, the Object Class isExpenseReportItinerarySegment 35804DT, the Property is Type 35806DT, theRepresentation/Association is Code 35808DT, the Type is CCT 35810DT, theType Name is Code 35812DT, and the Length is from one to two 35814DT.The remark 35818DT shows that the GDTExpenseReportItinerarySegmentTypeCode 35800DT may be restricted.

The data type GDT ExpenseReportItinerarySegmentTypeCode 35800DT may usethe following codes: 1 (i.e., start of trip), 2 (i.e., end of trip), 3(i.e., border crossing from domestic country into foreign country), 4(i.e., border crossing for return to domestic country), 5 (i.e., landingat first destination), 6 (i.e., start with return flight), 7 (i.e.,first destination, start of trip), 8 (i.e., additional destination,arrival at destination).

The attributes of the CCT Code are filled implicitly with the followingvalues: listID=“10084,” listAgencyID=310, and listVersionID—Version ofthe code list. Assigned and administered by SAP.

An example of ExpenseReportSegments within an itinerary may include thefollowing list:

“Segment type B start of trip: Jun. 1, 2005 9:30 AM departure fromWalldorf

Segment type M first destination: Jun. 1, 2005 9:30 AM Darmstadt,Germany, visit company A, Schillerstrasse 3, 64297 Darmstadt

Segment type N second destination: Jun. 3, 2005 6:00 PM Mol, Belgium,visit company B, Vareselaan 126, 2400 Mol

Segment type N third destination: Jun. 5, 2005 1:00 PM Nancy, France,visit company C, Rue de l'Oratoire 34, 54000 Nancy

Segment type R border crossing: Jun. 8, 2005 4:00 PM return to domesticcountry

Segment type E end of trip: Jun. 8, 2005 6:30 PM arrival in Walldorf”

(oooooooooooooo) AG.ExpenseReportMileageCumulationPeriodTypeCode

A GDT ExpenseReportMileageCumulationPeriodTypeCode 35800DU is a codedrepresentation of the type of a calendar-based period of time for whichmileage cumulation takes place in a expense report. For example, amileage cumulation may be the sum of the distances of the trip segmentscovered by an expense reporter for the purpose of determining adistance-scaled travel flat rate within a calendar-based period of time.An example of GDT ExpenseReportMileageCumulationPeriodTypeCode 35800DUis:

<ExpenseReportMileageCumulationPeriodTypeCode>1</ExpenseReportMileageCumulationPeriodTypeCode>

The structure of GDT ExpenseReportMileageCumulationPeriodTypeCode35800DU is depicted in FIG. 358DU. For the GDTExpenseReportMileageCumulationPeriodTypeCode 35800DU, the Object Classis ExpenseReportMileageCumulationPeriod 35801DU, the Property is Type35803DU, the Representation/Association is Code 35804DU, the Type is CCT35805DU, the Type Name is Code 35806DU, the Length is one 35807DU, andthe Cardinality is one 35808DU. The remark 35809DU shows that the GDTExpenseReportMileageCumulationPeriodTypeCode 35800DU may be restricted.

For the ListAgencyID 35810DU, the Category is Attribute (A) 35811DU, theObject Class is CodeListAgency 35812DU, the Property is Identification35813DU, the Representation/Association is Identifier 35814DU, the Typeis XSD 35815DU, the Type Name is Token 35816DU, and the Cardinality iszero or one 35818DU.

For the ListVersionID 35820DU, the Category is Attribute (A) 35821DU,the Object Class is CodeList 35822DU, the Property is Version 35823DU,the Representation/Association is Identifier 35824DU, the Type is XSD35825DU, the Type Name is Token 35826DU, and the Cardinality is zero orone 35828DU.

For the ListAgency-SchemeID 35830DU, the Category is Attribute (A)35831DU, the Object Class is CodeListAgency 35832DU, the Property isScheme 35833DU, the Representation/Association is Identifier 35834DU,the Type is XSD 35835DU, the Type Name is Token 35836DU, and theCardinality is zero or one 35838DU.

For the ListAgency-SchemeAgencyID 35840DU, the Category is Attribute (A)35841DU, the Object Class is CodeListAgency 35842DU, the Property isSchemeAgency 35843DU, the Representation/Association is Identifier35844DU, the Type is XSD 35845DU, the Type Name is Token 35846DU, andthe Cardinality is zero or one 35848DU.

The data type GDT ExpenseReportMileageCumulationPeriodTypeCode 35800DUmay use the following codes: 1 (i.e., yearly cumulation of mileage), 2(i.e., monthly cumulation of mileage), 3 (i.e., weekly cumulation ofmileage).

An extensible SAP code list is assigned to theExpenseReportMileageCumulationPeriodTypeCode. A Customer can change thiscode list. In an unchanged SAP code list, the attributes are allocatedas follows: listID=[ID of the code list], listAgencyID=“310,” andlistVersionID=[version of the code list]. If a Customer makes changes tothe SAP code list, the allocation of the attributes changes as follows:listAgencyID—ID of Customer (ID from DE 3055 if listed there),listVersionID—assigned and managed by the Customer,listAgencySchemeID—ID of scheme if the listAgencyID does not come fromDE 3055, and listAgencySchemeAgencyID—ID of the organization from DE3055 that manages the scheme of the listAgencySchemeID.

(pppppppppppppp) ExpenseReportMileageID

A GDT ExpenseReportMileageID 35800DV is a unique identifier for themileage within an expense report. For example, the entities may be. Anexample of GDT ExpenseReportMileageID 35800DV is:

<ExpenseReportMileageID>1</ExpenseReportMileageID>

The structure of GDT ExpenseReportMileageID 35800DV is depicted in FIG.358DV. For the GDT ExpenseReportMileageID 35800DV, the Object Class isExpenseReportMileage 35804DV, the Property is Identification 35806DV,the Representation/Association is Identifier 35808DV, the Type is CCT35810DV, the Type Name is Identifier 35812DV, and the Length is from oneto three 35814DV. The remark 35818DV shows that the GDTExpenseReportMileageID 35800DV may be restricted. AnExpenseReportMileageID 35800DV may be represented as a three-digitnumber.

(qqqqqqqqqqqqqq) ExpenseReportProvisionVariantCode

A GDT ExpenseReportProvisionVariantCode 35800DW is a codedrepresentation of a variant of expense report provisions based on theterritory or expense reporting method. For example, an expense reportprovision may be a rule for determining the reimbursement of expensesand their taxation. An example of GDT ExpenseReportProvisionVariantCode35800DW is:

<ExpenseReportProvisionVariantCode>1</ExpenseReportProvisionVariantCode>

The structure of GDT ExpenseReportProvisionVariantCode 35800DW isdepicted in FIG. 358DW. For the GDT ExpenseReportProvisionVariantCode35800DW, the Object Class is ExpenseReportProvisionVariant 35804DW, theRepresentation/Association is Code 35808DW, the Type is CCT 35810DW, theType Name is Code 35812DW, and the Length is from one to four 35814DW.The remark 35818DW shows that the GDT ExpenseReportProvisionVariantCode35800DW may be restricted.

The data type GDT ExpenseReportProvisionVariantCode 35800DW may use thefollowing codes: German accounting (i.e., expense reporting based onGerman law), US accounting (i.e., expense reporting based on UnitedStates law).

The attributes of the code are assigned the following values:listID=“10349,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list.Assigned and managed by the Customer, listAgencySchemeID—ID of thescheme if the listAgencyID does not come from DE 3055, andlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme.

(rrrrrrrrrrrrrrrr) ExpenseReportReceiptID

A GDT ExpenseReportReceiptID 35800DX is a unique identifier for anexpense receipt within an expense report. For example, an expensereceipt may be proof of an expense incurred for the company. An exampleof GDT ExpenseReportReceiptID 35800DX is:

<ExpenseReportReceiptID>1</ExpenseReportReceiptID>

The structure of GDT ExpenseReportReceiptID 35800DX is depicted in FIG.358DX. For the GDT ExpenseReportReceiptID 35800DX, the Object Class isExpenseReportReceipt 35804DX, the Property is Identification 35806DX,the Representation/Association is Identifier 35808DX, the Type is CCT35810DX, the Type Name is Identifier 35812DX, and the Length is from oneto three 35814DX. The remark 35818DX shows that the GDTExpenseReportReceiptID 35800DX may be restricted. AnExpenseReportReceiptID 35800DX may be represented as a three-digitnumber.

(ssssssssssssss) ExpenseReportStatutoryStayTypeCode

A GDT ExpenseReportStatutoryStayTypeCode 35800DY is a codedrepresentation of a statutory stay type within an expense report. Forexample, a statutory stay type may classify within an expense report thestays for a business trip based on statutory criteria. An example of GDTExpenseReportStatutoryStayTypeCode 35800DY is:

<ExpenseReportStatutoryStayTypeCode>1</ExpenseReportStatutoryStayTypeCode>

The structure of GDT ExpenseReportStatutoryStayTypeCode 35800DY isdepicted in FIG. 358DY. For the GDT ExpenseReportStatutoryStayTypeCode35800DY, the Object Class is Expense Report 35804DY, the Property isStatutory_Stay Type 35806DY, the Representation/Association is Code35808DY, the Type is CCT 35810DY, the Type Name is Code 35812DY, and theLength is from one to two 35814DY. The remark 35818DY shows that the GDTExpenseReportStatutoryStayTypeCode 35800DY may be restricted.

The data type GDT ExpenseReportStatutoryStayTypeCode 35800DY may use thefollowing codes: business trip (i.e., trip taken for business reasons),private stay (i.e., private stay within a business trip, noreimbursement of per diems).

The attributes of the code are assigned the following values:listID=“10350,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list,listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055, and listAgencySchemeAgencyID—ID of the organization fromDE 3055 that manages the listAgencySchemeID scheme.

(tttttttttttttt) ExpenseReportTypeCode

A GDT ExpenseReportTypeCode 35800DZ is a coded representation of thetype of an expense report. For example, an expense report may be a listof receipts indicating the expenses incurred for the company that are tobe reimbursed to the expense reporter. In the case of a business trip,the expense report may also contain relevant general information on thetrip such as destinations, dates and times, and mileages. An example ofGDT ExpenseReportTypeCode 35800DZ is:

<ExpenseReportTypeCode>1</ExpenseReportTypeCode>

The structure of GDT ExpenseReportTypeCode 35800DZ is depicted in FIG.358DZ. For the GDT ExpenseReportTypeCode 35800DZ, the Object Class isExpenseReport 35804DZ, the Property is Type 35806DZ, theRepresentation/Association is Code 35808DZ, the Type is CCT 35810DZ, theType Name is Code 35812DZ, and the Length is from one to two 35814DZ.The remark 35818DZ shows that the GDT ExpenseReportTypeCode 35800DZ maybe restricted.

The data type GDT ExpenseReportTypeCode 35800DZ may use the followingcodes: domestic business trip (i.e., business trip where the travelerremains in his or her domestic country), international business trip(i.e., business trip where the traveler spends part or all of the timein a foreign country), expense report without business trip (i.e.,accounting for expenses that were not incurred in connection with abusiness trip).

The attributes of the code are assigned the following values:listID=“10351,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list.Assigned and managed by the Customer, listAgencySchemeID—ID of thescheme if the listAgencyID does not come from DE 3055, andlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme.

(uuuuuuuuuuuuuu) ExpenseReporterGroupCode

A GDT ExpenseReporterGroupCode 35800EA is a coded representation of agroup of expense reporters for the purpose of expense reporting. Anexample of GDT ExpenseReporterGroupCode 35800EA is:

<ExpenseReporterGroupCode>1</ExpenseReporterGroupCode>

The structure of GDT ExpenseReporterGroupCode 35800EA is depicted inFIG. 358EA. For the GDT ExpenseReporterGroupCode 35800EA, the ObjectClass is ExpenseReporterGroup 35804EA, the Representation/Association isCode 35808EA, the Type is CCT 35810EA, the Type Name is Code 35812EA,and the Length is from one to four 35814EA. The remark 35818EA showsthat the GDT ExpenseReporterGroupCode 35800EA may be restricted.

The data type GDT ExpenseReporterGroupCode 35800EA may use the followingcodes: office employees (i.e., employees who are mainly office-based),field employees (i.e., employees who work mainly in the field).

The attributes of the code are assigned the following values:listID=“10352,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list,listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055, and listAgency-SchemeAgencyID—ID of the organization fromDE 3055 that manages the listAgencySchemeID scheme.

(vvvvvvvvvvvvvv) FiscalYearValue

A GDT FiscalYearValue 35800EB is a numerical value that designates afiscal year. For example, a fiscal year (business year) may be aspecific period of time designated by a numerical year value for whichthe profit and loss of a company is regularly accounted (inventory andbalance sheet). An example of GDT FiscalYearValue 35800EB is:

<FiscalYearValue>2005</FiscalYearValue>

The structure of GDT FiscalYearValue 35800EB is depicted in FIG. 358EB.For the GDT FiscalYearValue 35800EB, the Object Class is FiscalYear35804EB, the Representation/Association is Value 35808EB, the Type isXsd 35810EB, the Type Name is nonNegativeInteger 35812EB, and the Lengthis four 35814EB.

A FiscalYearValue 35800EB may be represented by a four digit positivenumber. A FiscalYearValue 35800EB may be used, for example, to assigntransactions to legal reporting periods. A financial statement may bereported for a specific fiscal year. A fiscal year contains a number ofdesignated accounting periods. The fiscal year of a company is notnecessarily identical with a calendar year, for example, the fiscal year“2005” of a company may begin on Oct. 1, 2004 and end on Sep. 30, 2005.

(wwwwwwwwwwwwww) HandlingUnitID

A GDT HandlingUnitID 35800EC is a unique identifier for a HandlingUnit.For example, a HandlingUnit may be a physical unit that is handledindividually and only occurs once in the real world. The HandlingUnitmay describe the logistical and physical aspects of products orpackaging units. An example of GDT HandlingUnitID 35800EC is:

<HandlingUnitID schemeID=“SSCC” schemeAgencyID=“9”>

254222298765432106</HandlingUnitID>

The structure of GDT HandlingUnitID 35800EC is depicted in FIG. 358EC.For the GDT HandlingUnitID 35800EC, the Object Class is HandlingUnit35801EC, the Property is Identification 35803EC, theRepresentation/Association is Identifier 35804EC, the Type is CCT35805EC, the Type Name is Identifier 35806EC, and the Length is from oneto forty 35807EC. The remark 35809EC shows that the GDT HandlingUnitID35800EC may be restricted.

For the SchemeID 35810EC, the Category is Attribute (A) 35811EC, theObject Class is IdentificationScheme 35812EC, the Property isIdentification 35813EC, the Representation/Association is Identifier35814EC, the Type is XSD 35815EC, the Type Name is Token 35816EC, theLength is from one to sixty 35817EC, and the Cardinality is zero or one35818EC.

For the SchemeAgencyID 35820EC, the Category is Attribute (A) 35821EC,the Object Class is IdentificationScheme-Agency 35822EC, the Property isIdentification 35823EC, the Representation/Association is Identifier35824EC, the Type is XSD 35825EC, the Type Name is Token 35826EC, theLength is from one to sixty 35827EC, and the Cardinality is zero or one35828EC.

For the SchemeAgencySchemeID 35830EC, the Category is Attribute (A)35831EC, the Object Class is IdentificationScheme-Agency 35832EC, theProperty is Procedure 35833EC, the Representation/Association isIdentifier 35834EC, the Type is XSD 35835EC, the Type Name is Token35836EC, the Length is from one to sixty 35837EC, and the Cardinality iszero or one 35838EC.

For the SchemeAgencySchemeAgencyID 35840EC, the Category is Attribute(A) 35841EC, the Object Class is IdentificationScheme-Agency 35842EC,the Property is SchemeAgency 35843EC, the Representation/Association isIdentifier 35844EC, the Type is XSD 35845EC, the Type Name is Token35846EC, the Length is from one to three 35847EC, and the Cardinality iszero or one 35848EC.

A handling unit can consist of an empty load carrier. It may benecessary to specify the HandlingUnitID and the load carrier, whereaspacked products (loads), lower-level handling units, packagingmaterials, and additional packaging materials are optional.

(xxxxxxxxxxxxxx) HandlingUnitInternalID

A GDT HandlingUnitInternalID 35800ED is a proprietary identifier for aHandlingUnit. For example, a HandlingUnit may be a physical unit that ishandled individually and only occurs once in the real world. TheHandlingUnit may describe the logistical and physical aspects ofproducts or packaging units. An example of GDT HandlingUnitInternalID35800ED is:   <HandlingUnitInternalID schemeID=“HandlingUnitID”schemeAgencyID=“MPL_002“>01234567890123456789 </HandlingUnitInternalID>

The structure of GDT HandlingUnitInternalID 35800ED is depicted in FIG.358ED. For the GDT HandlingUnitInternalID 35800ED, the Object Class isHandlingUnit 35801ED, the Property Qualifier is Internal 35802ED, theProperty is Identification 35803ED, the Representation/Association isIdentifier 35804ED, the Type is GDT 35805ED, the Type Name isHandlingUnitID 35806ED, and the Length is from one to forty 35807ED. Theremark 35809ED shows that the GDT HandlingUnitInternalID 35800ED may berestricted.

For the SchemeID 35810ED, the Category is Attribute (A) 35811ED, theObject Class is IdentificationScheme 35812ED, the Property isIdentification 35813ED, the Representation/Association is Identifier35814ED, the Type is XSD 35815ED, the Type Name is Token 35816ED, theLength is from one to sixty 35817ED, and the Cardinality is zero or one35818ED.

For the SchemeAgencyID 35820ED, the Category is Attribute (A) 35821ED,the Object Class is IdentificationScheme-Agency 35822ED, the Property isIdentification 35823ED, the Representation/Association is Identifier35824ED, the Type is XSD 35825ED, the Type Name is Token 35826ED, theLength is from one to sixty 35827ED, and the Cardinality is zero or one35828ED.

The attributes of HandlingUnitInternalID 35800ED are filled as follows:schemeID, HandlingUnitID (Identification of a HandlingUnit using anidentifier) and sche-meAgencyID (Business system in which the identifierwas assigned).

(yyyyyyyyyyyyyy) HandlingUnitStandardID

A GDT HandlingUnitStandardID 35800EE is a standardized identifier for aHandlingUnit. For example, a HandlingUnit may be a physical unit that ishandled individually and only occurs once in the real world. TheHandlingUnit may describe the logistical and physical aspects ofproducts or packaging units. An example of GDT HandlingUnitStandardID35800EE is:

<HandlingUnitStandardID schemeID=“SSCC”

schemeAgencyID=“9”>254222298765432106</HandlingUnitStandardID>

The structure of GDT HandlingUnitStandardID 35800EE is depicted in FIG.358EE. For the GDT HandlingUnitStandardID 35800EE, the Object Class isHandlingUnit 35801EE, the Property Qualifier is Standard 35802EE, theProperty is Identification 35803EE, the Representation/Association isIdentifier 35804EE, the Type is CCT 35805EE, the Type Name isHandlingUnitID 35806EE, and the Length is from one to forty 35807EE. Theremark 35809EE shows that the GDT HandlingUnitStandardID 35800EE may berestricted.

For the SchemeID 35810EE, the Category is Attribute (A) 35811EE, theObject Class is IdentificationScheme 35812EE, the Property isIdentification 35813EE, the Representation/Association is Identifier35814EE, the Type is XSD 35815EE, the Type Name is Token 35816EE, theLength is from one to sixty 35817EE, and the Cardinality is zero or one35818EE.

For the SchemeAgencyID 35820EE, the Category is Attribute (A) 35821EE,the Object Class is IdentificationScheme-Agency 35822EE, the Property isIdentification 35823EE, the Representation/Association is Identifier35824EE, the Type is XSD 35825EE, the Type Name is Token 35826EE, theLength is from one to sixty 35827EE, and the Cardinality is zero or one35828EE.

The following codes and schemes are supported: “SchemeAgencyID”identifies the agency that manages the identification scheme, 9(EAN.UCC, International Numbering Association) for schemeID, SSCC—theSerial Shipping Container Code, which is up to 18 characters long, andGRAI—the Global Returnable Asset Identifier, which is up to 30characters long.

(zzzzzzzzzzzzzz) Indicator

A GDT Indicator 35800EF is a binary encoded specification of a fact thathas the value “0” or “1”, which may represent, for example, “true” or“false”. An example of GDT Indicator 35800EF is:

<Indicator>true</Indicator>

The structure of GDT Indicator 35800EF is depicted in FIG. 358EF. Forthe GDT Indicator 35800EF, the Category is simpleType 35801EF, theProperty is Indicator 35806EF, the Representation/Association is Content35808EF, the Type is XSD 35810EF, and the Type Name is Boolean 35812EF.“Indicator” may be used for binary classifications, indicators, flags,etc. The representation term for the CCT “Indicator” is Indicator.

(aaaaaaaaaaaaaaa) IndividualProductGroupID

A GDT IndividualProductGroupID 35800EG is a unique identifier for agroup of individual products. For example, an individual product may bea single unit of a product. It may be globally unique and the singleunit may be identified by an identifier, such as a serial ID or avehicle identification number (VIN). An example of GDTIndividualProductGroupID 35800EG is:

<IndividualProductGroupID>0601</IndividualProductGroupID>

The structure of GDT IndividualProductGroupID 35800EG is depicted inFIG. 358EG. For the GDT IndividualProductGroupID 35800EG, the ObjectClass is Individual Product Group 35804EG, the Property isIdentification 35806EG, the Representation/Association is Identifier35808EG, the Type is CCT 35810EG, the Type Name is Identifier 35812EG,and the Length is from one to four 35814EG. The remark 35818EG showsthat the GDT IndividualProductGroupID 35800EG may be restricted.

The data type GDT IndividualProductGroupID 35800EG may use the followingcodes: refrigerators (i.e., a group of individual products whose singleunits are identified by their refrigerator serial numbers), vehicles(i.e., a group of individual products whose single units are identifiedby their vehicle identification numbers).

(bbbbbbbbbbbbbbb) IndustrialSectorCode

A GDT IndustrialSectorCode 35800EH is a coded description of anindustry. For example, an industry may be the classification of acompany according to the main focus of its business activities. Retail,banking, services, industry, health service, public sector, media, andso on, may be defined as industries. An example of GDTIndustrialSectorCode 35800EH is:

<IndustrialSectorCode listID=“ISIC Rev.3.1” listAgencyID=“United NationsStatistics Division”>9000</IndustrialSectorCode>

The structure of GDT IndustrialSectorCode 35800EH is depicted in FIG.358EH. For the GDT IndustrialSectorCode 35800EH, the Property isIndustrial Sector 35803EH, the Representation/Association is Code35804EH, the Type is CCT 35805EH, the Type Name is Code 35806EH, and theLength is from one to ten 35807EH. The remark 35809EH shows that the GDTIndustrialSectorCode 35800EH may be restricted.

For the ListID 35810EH, the Category is Attribute (A) 35811EH, theObject Class is CodeList 35812EH, the Property is Identification35813EH, the Representation/Association is Identifier 35814EH, the Typeis XSD 35815EH, the Type Name is Token 35816EH, and the Cardinality iszero or one 35818EH.

For the ListAgencyID 35820EH, the Category is Attribute (A) 35821EH, theObject Class is CodeListAgency 35822EH, the Property is Identification35823EH, the Representation/Association is Identifier 35824EH, the Typeis XSD 35825EH, the Type Name is Token 35826EH, and the Cardinality iszero or one 35828EH.

For the ListVersionID 35830EH, the Category is Attribute (A) 35831EH,the Object Class is CodeList 35832EH, the Property is Version 35833EH,the Representation/Association is Identifier 35834EH, the Type is XSD35835EH, the Type Name is Token 35836EH, and the Cardinality is zero orone 35838EH.

For the ListAgency-SchemeID 35840EH, the Category is Attribute (A)35841EH, the Object Class is CodeListAgency 35842EH, the Property isScheme 35843EH, the Representation/Association is Identifier 35844EH,the Type is XSD 35845EH, the Type Name is Token 35846EH, and theCardinality is zero or one 35848EH.

For the ListAgency-SchemeAgencyID 35850EH, the Category is Attribute (A)35851EH, the Object Class is CodeListAgency 35852EH, the Property isSchemeAgency 35853EH, the Representation/Association is Identifier35854EH, the Type is XSD 35855EH, the Type Name is Token 35856EH, andthe Cardinality is zero or one 35858EH.

The data type GDT IndustrialSectorCode 35800EH may use the followingcodes: retail sector (i.e., companies in this industry work primarily inthe retail sector), wholesale sector (i.e., companies in this industrywork primarily in the wholesale sector).

If the GDT IndustrialSectorCode (industry) can be used in the context ofthe GDT IndustryClassificationSystemCode (industry system), the codevalue of the instance of the IndustryClassificationSystemCode determinesthe attributes of the instance of IndustrialSectorCode.

he attributes of the code can be assigned the following values:listID=“10353,” listAgencyID—ID of the Customer (ID from DE 3055, iflisted there), listVersionID—version of the particular code list.As-signed and managed by the Customer, listAgencySchemeID—ID of thescheme if the listAgencyID does not come from DE 3055, andlistAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme.

(ccccccccccccccc) IndustryClassificationSystemCode

A GDT IndustryClassificationSystemCode 35800EI is a coded description ofan industry system. For example, an industry system may be a list ofindustries that is organized systematically and, if required,hierarchically. Each of the following standards listed may represent apossible code value from a code list for industry systems: theInternational Standard Industrial Classification of United NationsStatistics Division, the NACE code (i.e., the economic classification ofthe European Union). An example of GDT IndustryClassificationSystemCode35800EI is:

<IndustryClassificationSystemCode>123</IndustryClassificationSystemCode>

The structure of GDT IndustryClassificationSystemCode 35800EI isdepicted in FIG. 358EI. For the GDT IndustryClassificationSystemCode35800EI, the Property is Industry Classification System 35803EI, theRepresentation/Association is Code 35804EI, the Type is CCT 35805EI, theType Name is Code 35806EI, and the Length is from one to four 35807EI.The remark 35809EI shows that the GDT IndustryClassificationSystemCode35800EI may be restricted.

For the ListID 35810EI, the Category is Attribute (A) 35811EI, theObject Class is CodeList 35812EI, the Property is Identification35813EI, the Representation/Association is Identifier 35814EI, the Typeis XSD 35815EI, the Type Name is Token 35816EI, and the Cardinality iszero or one 35818EI.

For the ListAgencyID 35820EI, the Category is Attribute (A) 35821EI, theObject Class is CodeListAgency 35822EI, the Property is Identification35823EI, the Representation/Association is Identifier 35824EI, the Typeis XSD 35825EI, the Type Name is Token 35826EI, and the Cardinality iszero or one 35828EI.

For the ListVersionID 35830EI, the Category is Attribute (A) 35831EI,the Object Class is CodeList 35832EI, the Property is Version 35833EI,the Representation/Association is Identifier 35834EI, the Type is XSD35835EI, the Type Name is Token 35836EI, and the Cardinality is zero orone 35838EI.

For the ListAgency-SchemeID 35840EI, the Category is Attribute (A)35841EI, the Object Class is CodeListAgency 35842EI, the Property isScheme 35843EI, the Representation/Association is Identifier 35844EI,the Type is XSD 35845EI, the Type Name is Token 35846EI, and theCardinality is zero or one 35848EI.

The data type GDT IndustryClassificationSystemCode 35800EI may use thefollowing codes: timber processing industries (i.e., this industrysystem includes the industries involved in using timber such as joinery,carpentry, furniture manufacturers, and so on), agricultural industries(i.e., this industry system includes those industries that can be linkedto agriculture in its broadest sense such as forestry enterprises,breeding establishments, garden nurseries and farms).

(ddddddddddddddd) InspectionResultValuationTypeCode

A GDT InspectionResultValuationTypeCode 35800EJ is a codedrepresentation of a type of automatic valuation for an inspectionresult. For example, the valuation type may define how an inspectionresult is valuated. The valuation may be performed based onnonconforming units or based on the number of defects. An example of GDTInspectionResultValuationTypeCode 35800EJ is:

<InspectionResultValuationTypeCode>1</InspectionResultValuationTypeCode>

The structure of GDT InspectionResultValuationTypeCode 35800EJ isdepicted in FIG. 358EJ. For the GDT InspectionResultValuationTypeCode35800EJ, the Object Class is Inspection 35804EJ, the Property isResult_Valuation Type 35806EJ, the Representation/Association is Code35808EJ, the Type is CCT 35810EJ, the Type Name is Code 35812EJ, and theLength is one 35814EJ. The remark 35818EJ shows that the GDTInspectionResultValuationTypeCode 35800EJ may be restricted.

The data type GDT InspectionResultValuationTypeCode 35800EJ may use thefollowing codes: 1 (i.e., automatic valuation based on nonconformingunits), 2 (i.e., automatic valuation based on the number of defects).The InspectionResultValuationTypeCode 35800EJ may be used in the contextof an inspection. The InspectionResultValuationTypeCode 35800EJ mayprovide information about the valuation type used during an automaticvaluation of the inspection result. An automatic valuation based onnonconforming units could, for example, lead to a rejection of aninbound delivery if there are more than three nonconforming units.

(eeeeeeeeeeeeeee) InspectionScopeCode

A GDT InspectionScopeCode 35800EK is a coded representation of aninspection scope. For example, initially, the inspection scope maydefine if an inspection is to take place or not. If an inspection is tobe performed, the inspection scope may define whether it is a 100%inspection or a sampling inspection. An example of GDTInspectionScopeCode 35800EK is:

<InspectionScopeCode>C</InspectionScopeCode>

The structure of GDT InspectionScopeCode 35800EK is depicted in FIG.358EK. For the GDT InspectionScopeCode 35800EK, the Object Class isInspectionScope 35804EK, the Representation/Association is Code 35808EK,the Type is CCT 35810EK, the Type Name is Code 35812EK, and the Lengthis one 35814EK. The remark 35818EK shows that the GDTInspectionScopeCode 35800EK may be restricted.

The data type GDT InspectionScopeCode 35800EK may use the followingcodes: N (i.e., no inspection is performed for an object), C (i.e.,every object of the total inspection quantity is inspected), S (i.e., anumber of objects of the total inspection quantity are inspected, thenumber being defined in accordance with specific criteria).

The attributes contains the following values: listID=“10093,”listAgencyID=“310,” and listVersionID—Version of the relevant code list.Assigned and managed by SAP AG. In the SAP system with the QIE,InspectionScopeCode is represented by the following dictionary objects:Data element: QIE_TV_INSP_PROC and Domain: QIE_INSP_PROC.

(fffffffffffffff) InspectionStageID

A GDT InspectionStageID 35800EL is an identifier for an inspectionstage. For example, within a dynamic modification rule (seeDynamicModificationRuleCode), the inspection stage may define whether aninspection is to be performed or skipped. The inspection stage may alsodefine the inspection severity (see InspectionSeverityCode) with whichthe inspection is performed and may contain the conditions for a changeto another inspection stage. In some implementations, the inspectionseverity is only relevant for inspections with a sampling scheme.Typically, a change of inspection stage brings about a reduction of theinspection scope. The dynamic modification rule may contain possibleinspection stages for a particular process of inspection scopereduction. An example of GDT InspectionStageID 35800EL is:

<InspectionStageID>3</InspectionStageID>

The structure of GDT InspectionStageID 35800EL is depicted in FIG.358EL. For the GDT InspectionStageID 35800EL, the Object Class isInspectionStage 35804EL, the Property is Identification 35806EL, theRepresentation/Association is Identifier 35808EL, the Type is CCT35810EL, the Type Name is Identifier 35812EL, and the Length is from oneto fifteen 35814EL. The remark 35818EL shows that the GDTInspectionStageID 35800EL may be restricted. The InspectionStageID35800EL may be unique within an inspection rule.

(ggggggggggggggg) InstallationPointID

A GDT InstallationPointID 35800EM is a unique identifier for aninstallation point. For example, an installation point may be thephysical or logical location at which a business object, for example amaterial or software, is installed during a certain period of time. Aninstallation point may have a multilevel structure. An example of GDTInstallationPointID 35800EM is:

<InstallationPointID>4711</InstallationPointID>

The structure of GDT InstallationPointID 35800EM is depicted in FIG.358EM. For the GDT InstallationPointID 35800EM, the Object Class isInstallation Point 35801EM, the Property is Identification 35803EM, theRepresentation/Association is Identifier 35804EM, the Type is CCT35805EM, the Type Name is Identifier 35806EM, and the Length is from oneto eighteen 35807EM. The remark 35809EM shows that the GDTInstallationPointID 35800EM may be restricted.

For the SchemeID 35810EM, the Category is Attribute (A) 35811EM, theObject Class is IdentificationScheme 35812EM, the Property isIdentification 35813EM, the Representation/Association is Identifier35814EM, the Type is XSD 35815EM, the Type Name is Token 35816EM, theLength is from one to sixty 35817EM, and the Cardinality is zero or one35818EM.

For the SchemeAgencyID 35820EM, the Category is Attribute (A) 35821EM,the Object Class is IdentificationScheme-Agency 35822EM, the Property isIdentification 35823EM, the Representation/Association is Identifier35824EM, the Type is XSD 35825EM, the Type Name is Token 35826EM, theLength is from one to sixty 35827EM, and the Cardinality is zero or one35828EM.

The data type GDT InstallationPointID 35800EM may use, for example,numeric characters, such as, any sequence of characters from thecharacter set {0, 1, 2, 3, 4, 5, 6, 7, 8, 9} with a length of 18. Insome implementations, character strings containing only zeroes orleading zeroes are not allowed. The attributes may be used as follows.The schemeID 35810EM identifies an identification scheme. Theidentification scheme represents the context that can be used toidentify an object. The schemeID 35810EM may be unique within the agencythat manages this identification scheme. The schemeAgencyID 35820EMidentifies the agency that manages an identification scheme.

The attributes of the code list are used as follows: schemeID—identifiesan identification scheme and schemeAgencyID—identifies the agency thatmanages an identification scheme. In SAP systems, theInstallationPointID is described by the following dictionary objects:Data element: IB_INSTANCE and domain: IB_INSTANCE.

(hhhhhhhhhhhhhhh) InstalledBaseCategoryCode

A GDT InstalledBaseCategoryCode 35800EN is a coded representation of thecategory of an installed base and is differentiated by customer specificcriteria. For example, an installed base may be structured after afunctional arrangement of business objects at a logical or physicalplace. An example of GDT InstalledBaseCategoryCode 35800EN is:

<InstalledBaseCategoryCode>1</InstalledBaseCategoryCode>

The structure of GDT InstalledBaseCategoryCode 35800EN is depicted inFIG. 358EN. For the GDT InstalledBaseCategoryCode 35800EN, the ObjectClass is InstalledBase 35801EN, the Property is Category 35803EN, theRepresentation/Association is Code 35804EN, the Type is CCT 35805EN, theType Name is Code 35806EN, and the Length is from one to two 35807EN.The remark 35809EN shows that the GDT InstalledBaseCategoryCode 35800ENmay be restricted.

For the ListAgencyID 35810EN, the Category is Attribute (A) 35811 EN,the Object Class is CodeListAgency 35812EN, the Property isIdentification 35813EN, the Representation/Association is Identifier35814EN, the Type is XSD 35815EN, the Type Name is Token 35816EN, andthe Cardinality is zero or one 35818EN.

For the ListVersionID 35820EN, the Category is Attribute (A) 35821EN,the Object Class is CodeList 35822EN, the Property is Version 35823EN,the Representation/Association is Identifier 35824EN, the Type is XSD35825EN, the Type Name is Token 35826EN, and the Cardinality is zero orone 35828EN.

For the ListAgency-SchemeID 35830EN, the Category is Attribute (A)35831EN, the Object Class is CodeListAgency 35832EN, the Property isScheme 35833EN, the Representation/Association is Identifier 35834EN,the Type is XSD 35835EN, the Type Name is Token 35836EN, and theCardinality is zero or one 35838EN.

For the ListAgency-SchemeAgencyID 35840EN, the Category is Attribute (A)35841EN, the Object Class is CodeListAgency 35842EN, the Property isSchemeAgency 35843EN, the Representation/Association is Identifier35844EN, the Type is XSD 35845EN, the Type Name is Token 35846EN, andthe Cardinality is zero or one 35848EN.

The data type GDT InstalledBaseCategoryCode 35800EN may use thefollowing codes: building (i.e., the installed base comprises abuilding), machines (i.e., the installed base comprises machines).

(iiiiiiiiiiiiiii) InstalledBaseID

A GDT InstalledBaseID 35800EO is a unique identifier for an installedbase. For example, an installed base may be a functionally-structuredarrangement of business objects at a logical or physical location. Anexample of GDT InstalledBaseID 35800EO is:

<InstalledBaseID>4711</InstalledBaseID>

The structure of GDT InstalledBaseID 35800EO is depicted in FIG. 358EO.For the GDT InstalledBaseID 35800EO, the Object Class is Installed Base35801EO, the Property is Identification 35803EO, theRepresentation/Association is Identifier 35804EO, the Type is CCT35805EO, the Type Name is Identifier 35806EO, and the Length is from oneto eighteen 35807EO. The remark 35809EO shows that the GDTInstalledBaseID 35800EO may be restricted.

For the SchemeID 35810EO, the Category is Attribute (A) 35811EO, theObject Class is IdentificationScheme 35812EO, the Property isIdentification 35813EO, the Representation/Association is Identifier35814EO, the Type is XSD 35815EO, the Type Name is Token 35816EO, theLength is from one to sixty 35817EO, and the Cardinality is zero or one35818EO.

For the SchemeAgencyID 35820EO, the Category is Attribute (A) 35821EO,the Object Class is IdentificationScheme-Agency 35822EO, the Property isIdentification 35823EO, the Representation/Association is Identifier35824EO, the Type is XSD 35825EO, the Type Name is Token 35826EO, theLength is from one to sixty 35827EO, and the Cardinality is zero or one35828EO.

The data type GDT InstalledBaseID 35800EO may use, for example, numericcharacters, such as, any sequence of characters from the character set{0, 1, 2, 3, 4, 5, 6, 7, 8, 9} with a length of 18. In someimplementations, character strings containing only zeroes or leadingzeroes are not allowed. The attributes may be used as follows. TheschemeID 35810EO identifies an identification scheme. The identificationscheme represents the context that can be used to identify an object.The schemeID 35810EO is only unique within the agency that manages thisidentification scheme. The schemeAgencyID 35820EO identifies the agencythat manages an identification scheme.

The attributes are used as follows: schemeID—identifies anidentification scheme. and schemeAgencyID—identifies the agency thatmanages an identification scheme.

(jjjjjjjjjjjjjj) IntegratedProductionProcessModelID

A GDT IntegratedProductionProcessModelID 35800EP is a unique identifierfor an integrated production process model. For example, anIntegratedProductionProcessModel may be a grouping of one or moreProductionSegments for a production process. A ProductionSegment may bea section in the production of a material in a LogisticsDivision. Anexample of GDT IntegratedProductionProcessModelID 35800EP is:

<IntegratedProductionProcessModelID>CPRD_(—)1</IntegratedProductionProcessModelID>

The structure of GDT IntegratedProductionProcessModelID 35800EP isdepicted in FIG. 358EP. For the GDT IntegratedProductionProcessModelID35800EP, the Object Class is IntegratedProductionProcessModel 35804EP,the Property is Identification 35806EP, the Representation/Associationis Identifier 35808EP, the Type is CCT 35810EP, the Type Name isIdentifier 35812EP, and the Length is from one to forty 35814EP. Theremark 35818EP shows that the GDT IntegratedProductionProcessModelID35800EP may be restricted.

(kkkkkkkkkkkkkk) IntegratedSiteLogisticsProcessModelID

A GDT IntegratedSiteLogisticsProcessModelID 35800EQ is a uniqueidentifier for an IntegratedSiteLogisticsProcessModel. For example, anIntegratedSiteLogisticsProcessModel may be a model that defines alogistic process managed by a logistics division, for example, byspecifying a sequence of process segments. An example of GDTIntegratedSiteLogisticsProcessModelID 35800EQ is:

<IntegratedSiteLogisticsProcessModelID>STANDARD_RECEIVING

</IntegratedSiteLogisticsProcessModelID>

The structure of GDT IntegratedSiteLogisticsProcessModelID 35800EQ isdepicted in FIG. 358EQ. For the GDTIntegratedSiteLogisticsProcessModelID 35800EQ, the Object Class isIntegrated Site Logistics Process Model 35804EQ, the Property isIdentification 35806EQ, the Representation/Association is Identifier35808EQ, the Type is CCT 35810EQ, the Type Name is Identifier 35812EQ,and the Length is from one to forty 35814EQ. The remark 35818EQ showsthat the GDT IntegratedSiteLogisticsProcessModelID 35800EQ may berestricted.

(llllllllllllll) InventoryResponsibleOrganisationalUnitTypeCode

A GDT InventoryResponsibleOrganisationalUnitTypeCode 35800ER is a codedrepresentation of the type of an organizational unit that is responsiblefor an inventory. For example, an inventory may be the quantity of allmaterials at a location with their reservations for consumers. Anexample of GDT InventoryResponsibleOrganisationalUnitTypeCode 35800ERis:

<InventoryResponsibleOrganisationalUnitTypeCode>1</InventoryResponsibleOrganisationalUnitTypeCode>

The structure of GDT InventoryResponsibleOrganisationalUnitTypeCode35800ER is depicted in FIG. 358ER. For the GDTInventoryResponsibleOrganisationalUnitTypeCode 35800ER, the Object Classis Inventory 35804ER, the Property is Responsible Organizational UnitType 35806ER, the Representation/Association is Code 35808ER, the Typeis CCT 35810ER, the Type Name is Code 35812ER, the Length is one35814ER, and the Cardinality is one 35816ER. The remark 35818ER showsthat the GDT InventoryResponsibleOrganisationalUnitTypeCode 35800ER maybe restricted.

The data type GDT InventoryResponsibleOrganisationalUnitTypeCode 35800ERmay use the following codes: 1 (i.e., organizational unit responsiblefor inventory at a site), 2 (i.e., organizational unit responsible forinventory in a logistics division), 3 (i.e., organizational unitresponsible for inventory in a logistics area), 4 (i.e., organizationalunit responsible for inventory at a resource, for example, a shelf butnot an employee). The InventoryResponsibleOrganisationalUnitTypeCode35800ER defines the organizational unit responsible for inventorymanagement in more detail.

The attributes of the code list are used as follows: listID=“10080,”listAgencyID=“310,” and listVersionID—Version of the relevant code list.Assigned and managed by SAP AG.

(mmmmmmmmmmmmmmm) InventorySeparatingValues

A GDT InventorySeparatingValues 35800ES are values of stock-separatingattributes that are required for stock posting. For example,stock-separating attributes may be criteria that are used todifferentiate one stock from other stocks. An example of GDTInventorySeparatingValues 35800ES is:   <InventorySeparatingValues>  <MaterialUUID>42d3cfca-5996-57b0-e100-00000a44201b</   MaterialUUID>  <BatchUUID>32d3cfca-8796-57b0-e100-00000a42201a</   BatchUUID>  <OwnerPartyUUID>51d3cfca-1996-57b0-e100- 00000a42201c</OwnerPartyUUID>  <SupplyPlanningAreaUUID>35d3cfca-3996-57b0-e100-   00000a42201d  </SupplyPlanningAreaUUID>  <InventoryUsabilityStatusCode>1</InventoryUsabiltiyStatusCode>  <ConsignmentIndicator>1</ConsignmentIndicator  <SubcontractingIndicator></SubcontractingIndicator>  <PackagingMaterialTiedIndicator></   PackagingMaterialTiedIndicator>  </InventorySeparatingValues>

The structure of GDT InventorySeparatingValues 35800ES is depicted inFIG. 358ES. For the GDT InventorySeparatingValues 35800ES, the ObjectClass is Inventory Separating Values 35801ES, and theRepresentation/Association is Details 35804ES.

For the MaterialUUID 35810ES, the Category is Element (E) 35811ES, theObject Class is Inventory Separating Values 35812ES, the Property isMaterial 35813ES, the Representation/Association is Identifier 35814ES,the Type is GDT 35815ES, the Type Name is UUID 35816ES, the Length isthirty-six 35817ES, and the Cardinality is one 35818ES.

For the BatchUUID 35820ES, the Category is Element (E) 35821ES, theObject Class is Inventory Separating Values 35822ES, the Property isBatch 35823ES, the Representation/Association is Identifier 35824ES, theType is GDT 35825ES, the Type Name is UUID 35826ES, the Length isthirty-six 35827ES, and the Cardinality is zero or one 35828ES.

For the OwnerPartyUUID 35830ES, the Category is Element (E) 35831ES, theObject Class is Inventory Separating Values 35832ES, the Property isOwner Party 35833ES, the Representation/Association is Identifier35834ES, the Type is GDT 35835ES, the Type Name is UUID 35836ES, theLength is thirty-six 35837ES, and the Cardinality is one 35838ES.

For the SupplyPlanningAreaUUID 35840ES, the Category is Element (E)35841ES, the Object Class is Inventory Separating Values 35842ES, theProperty is Supply Planning Area 35843ES, the Representation/Associationis Identifier 35844ES, the Type is GDT 35845ES, the Type Name is UUID35846ES, the Length is thirty-six 35847ES, and the Cardinality is zeroor one 35848ES.

For the InventoryUsabilityStatusCode 35850ES, the Category is Element(E) 35851ES, the Object Class is Inventory Separating Values 35852ES,the Property is Inventory Usability Status 35853ES, theRepresentation/Association is Code 35854ES, the Type is GDT 35855ES, theType Name is InventoryUsabilityStatusCode 35856ES, the Length is fromone to two 35857ES, and the Cardinality is one 35858ES.

For the ConsignmentIndicator 35860ES, the Category is Element (E)35861ES, the Object Class is Inventory Separating Values 35862ES, theProperty is Consignment 35863ES, the Representation/Association isIndicator 35864ES, the Type is GDT 35865ES, the Type Name isConsignmentIndicator 35866ES, and the Cardinality is zero or one35868ES.

For the SubcontractionIndicator 35870ES, the Category is Element (E)35871ES, the Object Class is Inventory Separating Values 35872ES, theProperty is Subcontracting 35873ES, the Representation/Association isIndicator 35874ES, the Type is GDT 35875ES, the Type Name isSubcontractingIndicator 35876ES, and the Cardinality is zero or one35878ES.

For the PackagingMaterialTiedIndicator 35880ES, the Category is Element(E) 35881ES, the Object Class is Inventory Separating Values 35882ES,the Property is Packaging Material Tied 35883ES, theRepresentation/Association is Indicator 35884ES, the Type is GDT35885ES, the Type Name is PackagingMaterialTiedIndicator 35886ES, andthe Cardinality is zero or one 35888ES.

In some implementations, the MaterialUUID 35810ES may be a unique,global identifier for a material. The BatchUUID 35820ES may be a unique,global identifier for a batch (homogeneous partial quantity of amaterial). The OwnerPartyUUID 35830ES may be a unique, global identifierfor the inventory owner. The SupplyPlanningAreaUUID 35840ES may be aunique, global identifier for an area in planning for which theavailability of products on time is guaranteed. TheInventoryUsabilityStatusCode 35850ES may be coded information on the useof the inventory (such as locked for further business processes, orquality inspection). The ConsignmentIndicator 35860ES may be aconsignment stock indicator. The SubcontractingIndicator 35870ES may bean indicator for stock with subcontractor. ThePackagingMaterialTiedIndicator 35880ES may indicate whether or not apackaging material (load carrier, additional packaging material) is aphysical part of a HandlingUnit or a LogisticsUnit.

(nnnnnnnnnnnnnnn) OperationActivityID

A GDT OperationActivityID 35800ET is a unique identifier of an activityin an operation. An activity is a processing or transportation sectionof a process description in logistics on a lower-level than theoperation. An example of a GDT OperationActivityID 35800ET is:

<OperationActivityID>ASSEMBLY_(—)023</OperationActivityID>

The structure of GDT OperationActivityID 35800ET is depicted in FIG.358ET. For the GDT OperationActivityID 35800ET, the Object Class isOperation Activity 35802ET, the Property is Identification 35804ET, theRepresentation/Association is Identifier 35806ET, the Type is CCT35808ET, the Type Name is Identifier 35810ET, and the Length is from oneto forty 35812ET. The remark 35814ET shows that GDT OperationActivityID35800ET may be restricted.

The GDT OperationActivityID 35800ET is explicit in the context of anoperation.

(ooooooooooooooo) OperationActivityStepID

A GDT OperationActivityStepID 35800EU is a unique identifier of a workstep of an activity in an operation. A work step is the description of adetailed work instruction of a process description in logistics. Anexample of a GDT OperationActivityStepID 35800EU is:

<OperationActivityStepID>STEP_(—)10</OperationActivityStepID>

The structure of GDT OperationActivityStepID 35800EU is depicted in FIG.358EU. For the GDT OperationActivityStepID 35800EU, the Object Class isOperation Activity Step 35802EU, the Property is Identification 35804EU,the Representation/Association is Identifier 35806EU, the Type is CCT35808EU, the Type Name is Identifier 35810EU, and the Length is from oneto forty 35812EU. The remark 35814EU shows that GDTOperationActivityStepID 35800EU may be restricted.

The GDT OperationActivityStepID 35800EU is explicit in the context of anoperation.

(ppppppppppppppp) OperationActivityTypeCode

A GDT OperationActivityTypeCode 35800EV is the coded representation of acategorization of operations. An activity is a processing ortransportation section of a process description in logistics on alower-level than the operation. An example of a GDTOperationActivityTypeCode 35800EV is:

<OperationActivityTypeCode>1</OperationActivityTypeCode>

The structure of GDT OperationActivityTypeCode 35800EV is depicted inFIG. 358EV. For the GDT OperationActivityTypeCode 35800EV, the ObjectClass is Operation Activity 35804EV, the Property is Type 35806EV, theRepresentation/Association is Code 35808EV, the Type is CCT 35810EV, theType Name is Code 35812EV and the Length is from one to four 35814EV.The remark 35815CP shows that GDT OperationActivityTypeCode 35800EV maybe restricted.

For the list Agency ID 35816EV, the Category is Attribute (A) 34518EV,the Object Class is Code List Agency 35820EV, the Property isIdentification 35822EV, the Representation/Association is Identifier35824EV, the Type is XSD 35826EV, and the Type Name is token 35828EV.The Cardinality is one 35830EV.

For the list Version ID 35832EV, the Category is Attribute (A) 34534EV,the Object Class is Code List 35836EV, the Property is Version 35838EV,the Representation/Association is Identifier 35840EV, the Type is XSD35842EV, and the Type Name is token 35844EV. The Cardinality is one35846EV.

For the list Agency-Scheme ID 35848EV, the Category is Attribute (A)34550EV, the Object Class is Code List Agency 35852EV, the Property isScheme 35854EV, the Representation/Association is Identifier 35856EV,the Type is XSD 35858EV, and the Type Name is token 35860EV. TheCardinality is zero or one 35862EV.

For the list Agency-Scheme Agency ID 35864EV, the Category is Attribute(A) 34566EV, the Object Class is Code List Agency 35868EV, the Propertyis Scheme Agency 35870EV, the Representation/Association is Identifier35872EV, the Type is XSD 35874EV, and the Type Name is token 35876EV.The Cardinality is zero or one 35878EV.

An extendable SAP code list is assigned to the GDTOperationActivityTypeCode 35800EV. Customers can change this code list.In its unchanged state, the SAP code list has the following attributes:listID=“10130”, listAgencyID=“310”, listVersionID=Version of therelevant code list assigned and managed by SAP AG. If A customer makeschanges to the SAP code list, the values of the attributes are changedas follows: listAgencyID which is the ID of the Customer (ID from DE3055 if listed there), listVersionID which is assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID is not taken from DE 3055, and listAgencySchemeAgencyIDwhich is the ID of the organization (taken from DE 3055) that managesthe scheme of the listAgencySchemeID.

Every GDT OperationActivityTypeCode 35800EV has to be assigned toexactly one OperationActivityCategoryCode. The customer can extend thecode list, for example, to include the code: Clean.

Possible code values for the GDT OperationActivityTypeCode 35800EV areone through nine. Setup is code one. Setup is an activity that preparesthe work center for the operations to be executed. Produce is code two.Produce is a processing of a material at a work center. Setup and teardown are not a part of processing. Tear Down is code three. Tear Down isan activity that returns the work center to its original state afterprocessing the operations. Single Move is code four. Single Move is asingle transport of materials or logistics units from one location toanother target location. Collective Move is code five. Collective Moveis a collective transport of materials or logistics units from severallocations to another target location. Distributed Move is code six.Distributed Move is a distributed transport of materials or logisticsunits from one location to several target locations. Pack is code seven.Pack is a packing of materials or logistics units in a logistics unit.Unpack is code eight. Unpack is an unpacking of materials or logisticsunits from a logistics unit. Homogeneous Pack is code nine. HomogeneousPack is a packing of a quantity of one material or exactly one logisticsunit into a logistics unit.

(qqqqqqqqqqqqqqq) OperationID

A GDT OperationID 35800EW is a unique identifier of an operation. Anoperation is a self-contained section of a process in a logisticsprocess description that is always completely executed on one or moreresources that represent the main resources. An example of a GDTOperationID 35800EW is:

<OperationID>OP42</OperationID>

The structure of GDT OperationID 35800EW is depicted in FIG. 358EW. Forthe GDT OperationID 35800EW, the Object Class is Operation 35802EW, theProperty is Identification 35804EW, the Representation/Association isIdentifier 35806EW, the Type is CCT 35808EW, the Type Name is Identifier35810EW, and the Length is from one to forty 35812EW. The remark 35814EWshows that GDT OperationID 35800EW may be restricted.

The GDT OperationID 35800EW may be unique in the usage context.

(rrrrrrrrrrrrrrr) OperationTypeCode

A GDT OperationTypeCode 35800EX is the coded representation of acategorization of operations. The type categorizes operations accordingto task. An operation is a self-contained process section in a logisticsprocess description that is always completely executed on one or moreresources that represent the main resources. An example of a GDTOperationTypeCode 35800EX is:

<OperationTypeCode>1</OperationTypeCode>

The structure of GDT OperationTypeCode 35800EX is depicted in FIG.358EX. For the GDT OperationTypeCode 35800EX, the Object Class isOperation 35804EX, the Property is Type 35806EX, theRepresentation/Association is Code 35808EX, the Type is CCT 35810EX, theType Name is Code 35812EX and the Length is from one to four 35814EX.The remark 35815CP shows that GDT OperationTypeCode 35800EX may berestricted.

For the list Agency ID 35816EX, the Category is Attribute (A) 34518EX,the Object Class is Code List Agency 35820EX, the Property isIdentification 35822EX, the Representation/Association is Identifier35824EX, the Type is XSD 35826EX, and the Type Name is token 35828EX.The Cardinality is one 35830EX.

For the list Version ID 35832EX, the Category is Attribute (A) 34534EX,the Object Class is Code List 35836EX, the Property is Version 35838EX,the Representation/Association is Identifier 35840EX, the Type is XSD35842EX, and the Type Name is token 35844EX. The Cardinality is one35846EX.

For the list Agency-Scheme ID 35848EX, the Category is Attribute (A)34550EX, the Object Class is Code List Agency 35852EX, the Property isScheme 35854EX, the Representation/Association is Identifier 35856EX,the Type is XSD 35858EX, and the Type Name is token 35860EX. TheCardinality is zero or one 35862EX.

For the list Agency-Scheme Agency ID 35864EX, the Category is Attribute(A) 34566EX, the Object Class is Code List Agency 35868EX, the Propertyis Scheme Agency 35870EX, the Representation/Association is Identifier35872EX, the Type is XSD 35874EX, and the Type Name is token 35876EX.The Cardinality is zero or one 35878EX.

An extendable SAP code list is assigned to the GDT OperationTypeCode35800EX. Customers can change this code list. In its unchanged state,the SAP code list has the following attributes: listID=“10132”,listAgencyID=“310”, listVersionID=Version of the relevant code listassigned and managed by SAP AG. If A customer makes changes to the SAPcode list, the values of the attributes are changed as follows:listAgencyID which is the ID of the Customer (ID from DE 3055 if listedthere), listVersionID which is assigned and managed by the Customer,listAgencySchemeID which is the ID of the scheme if the listAgencyID isnot taken from DE 3055, and listAgencySchemeAgencyID which is the ID ofthe organization (taken from DE 3055) that manages the scheme of thelistAgencySchemeID.

Every GDT OperationTypeCode 35800EX has to be assigned to exactly oneOperationCategoryCode. Together with the OperationCategoryCode this codebuilds up a two-level classification of operations. While theOperationCategoryCode with its fixed code list determines the businesslogic, the code list for the OperationTypeCode is extendable.

Example customer specific code values for the GDT OperationTypeCode35800EX are one through seven. Make is code one. Make is a productionoperation. Pack is code two. Pack is a packing operation that can meanpacking or unpacking. Move is code three. Move is a transportationoperation. Material Count is code four. Material Count is an operationfor counting the material physical inventory. In a material count, thequantity of materials is recorded. Logistic Unit Count is code five.Logistic Unit Count is an operation for counting the logistic unitphysical inventory. In a logistic unit count, the quantity of logisticunits is recorded. Handling Unit Count is code six. Handling Unit Countis an operation for counting the handling unit physical inventory. In ahandling unit count, the IDs of the handling units are recorded. CountApproval is code seven. Count Approval is an operation for approving theresult of a count operation.

(sssssssssssssss) OrganisationalCentreBusinessCharacterCode

A GDT OrganisationalCentreBusinessCharacterCode 35800EY is the codedrepresentation of a business role of an organizational unit. An exampleof a GDT OrganisationalCentreBusinessCharacterCode 35800EY is:

<OrganisationalCentreBusinessCharacterCode>1</OrganisationalCentreBusinessCharacterCode>

The structure of GDT OrganisationalCentreBusinessCharacterCode 35800EYis depicted in FIG. 358EY. For the GDTOrganisationalCentreBusinessCharacterCode 35800EY, the Object Class isOrganisational Centre 35802EY, the Property is Business Character35804EY, the Representation/Association is Code 35806EY, the Type is CCT35808EY, the Type Name is Code 35810EY, and the Length is from one totwo 35812EY. The remark 35814EY shows that GDTOrganisationalCentreBusinessCharacterCode 35800EY may be restricted.

The GDT OrganisationalCentreBusinessCharacterCode 35800EY is an SAP codelist. The GDT OrganisationalCentreBusinessCharacterCode 35800EY is afixed code list. The attributes listID=“10056”, listAgencyID=“310”,listVersionID=(to be defined) are missing in the structure as they wouldbe filled with constant values at run-time.

The GDT OrganisationalCentreBusinessCharacterCode 35800EY can includetwelve codes. Code one is Company. For code one, the business role,Company, is assigned to the organizational unit. Code two is Segment.For code two, the business role, Segment, is assigned to theorganizational unit. Code three is Profit center. For code three, thebusiness role, Profit center, is assigned to the organizational unit.Code four is Cost center. For code four, the business role, Cost center,is assigned to the organizational unit. Code five is Site. For codefive, the business role, Site, is assigned to the organizational unit.Code six is Logistics division. For code six, the business role,Logistics division, is assigned to the organizational unit. Code sevenis Sales unit. For code seven, the business role, Sales unit, isassigned to the organizational unit. Code eight is Service unit. Forcode eight, the business role, Service unit, is assigned to theorganizational unit. Code nine is Reporting line unit. For code nine,the business role, Reporting line unit, is assigned to theorganizational unit. Code ten is Purchasing unit. For code ten, thebusiness role, Purchasing unit, is assigned to the organizational unit.Code eleven is Shipping point. For code eleven, the business role,Shipping point, is assigned to the organizational unit. Code twelve isProgram. For code twelve, the business role, Program, is assigned to theorganizational unit.

The GDT OrganisationalCentreBusinessCharacterCode 35800EY is not used incross-enterprise communication.

(ttttttttttttttt) OrganisationalCentreHierarchyTypeCode

A GDT OrganisationalCentreHierarchyTypeCode 35800EZ is the codedrepresentation of the nature of an organizational hierarchy. An exampleof a GDT OrganisationalCentreHierarchyTypeCode 35800EZ is:

<OrganisationalCentreHierarchyTypeCode>2</OrganisationalCentreHierarchyTypeCode>

The structure of GDT OrganisationalCentreHierarchyTypeCode 35800EZ isdepicted in FIG. 358EZ. For the GDTOrganisationalCentreHierarchyTypeCode 35800EZ, the Object Class isOrganisational Centre 35802EZ, the Property is Hierarchy Type 35804EZ,the Representation/Association is Code 35806EZ, the Type is CCT 35808EZ,the Type Name is Code 35810EZ, and the Length is from one to four35812EZ. The remark 35814EZ shows that GDTOrganisationalCentreHierarchyTypeCode 35800EZ may be restricted.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10363”, listAgencyID which is theID of the ″Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, listAgencySchemeAgencyID whichis the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

Examples of possible code uses for the code GDTOrganisationalCentreHierarchyTypeCode 35800EZ may include a code fororganizational structure. For example, an organizational hierarchy is anorganizational structure. Another code may be for a financial structure.An organizational hierarchy can also be a financial structure. Anothercode may be for a structure of a sales organization. An organizationalhierarchy is a structure of a sales organization.

The GDT OrganisationalCentreHierarchyTypeCode 35800EZ must not be usedin cross-enterprise communication.

(uuuuuuuuuuuuuuu) OrganisationalCentreID

A GDT OrganisationalCentreID 35800FA is a unique identifier of anorganizational unit.

An organizational unit is a business unit of an organizationalstructure, for example, an organizational structure or a financialstructure, of an enterprise.

An organizational unit can take on one or several different businessroles, for example, a company, a cost center, a permanent establishmentor a reporting line unit. As a rule, an organizational unit is abusiness unit of the enterprise itself. However, it can also belong to acollaborative partner, if it is treated like an organizational unit ofthe enterprise itself in business processes.

An example of a GDT OrganisationalCentreID 35800FA is:

<OrganisationalCentreID>ABC4711</OrganisationalCentreID>

The structure of GDT OrganisationalCentreID 35800FA is depicted in FIG.358FA. For the GDT OrganisationalCentreID 35800FA, the Object Class isOrganisational Centre 35802FA, the Property is Identification 35804FA,the Representation/Association is Identifier 35806FA, the Type is CCT35808FA, the Type Name is Identifier 35810FA, and the Length is from oneto twenty 35812FA. The remark 35814FA shows that GDTOrganisationalCentreID 35800FA may be restricted.

The GDT OrganisationalCentreID 35800FA can be used when sender andrecipient access reconciled master data. The GDT OrganisationalCentreID35800FA must not be used in cross-enterprise communication. ExplicitGDTs should be used here for the different business roles.

(vvvvvvvvvvvvvvv) OrganisationalCentreTypeCode

A GDT OrganisationalCentreTypeCode 35800FB is the coded representationof the nature of an organizational unit. An example of a GDTOrganisationalCentreTypeCode 35800FB is:

<OrganisationalCentreTypeCode>1</OrganisationalCentreTypeCode>

The structure of GDT OrganisationalCentreTypeCode 35800FB is depicted inFIG. 358FB. For the GDT OrganisationalCentreTypeCode 35800FB, the ObjectClass is Organisational Centre 35802FB, the Property is Type 35804FB,the Representation/Association is Code 35806FB, the Type is CCT 35808FB,the Type Name is Code 35810FB, and the Length is from one to four35812FB. The remark 35814FB shows that GDT OrganisationalCentreTypeCode35800FB may be restricted.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10364”, listAgencyID which is theID of the Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, listAgencySchemeAgencyID whichis the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

A customer can define its own types of organizational units. These typescontain the assignment of different business roles, and preset attributevalues, for example.

Examples of possible code values for the GDTOrganisationalCentreTypeCode 35800FB are Department, Store and Branch.Department is an organizational unit that has the nature of adepartment. Store is an organizational unit that has the nature of astore. Branch is an organizational unit that has the nature of a branch.

The GDT OrganisationalCentreTypeCode 35800FB must not be used incross-enterprise communication.

(wwwwwwwwwwwwwww) PackingBillOfMaterialID

A GDT PackingBillOfMaterialID 35800FC is a unique identifier of apacking bill of material. A packing bill of material is a complete andstructured list of components that defines the packing structure oflogistic units (LUs). An example of a GDT PackingBillOfMaterialID35800FC is:

<PackingBillOfMaterialID>12345678901234567890</PackingBillOfMaterialID>

The structure of GDT PackingBillOfMaterialID 35800FC is depicted in FIG.358FC. For the GDT PackingBillOfMaterialID 35800FC, the Object Class isPacking Bill Of Material 35802FC, the Property is Identification35804FC, the Representation/Association is Identifier 35806FC, the Typeis CCT 35808FC, the Type Name is Identifier 35810FC, and the Length isfrom one to twenty 35812FC. The remark 35814FC shows that GDTPackingBillOfMaterialID 35800FC may be restricted.

For the scheme Agency ID 35816FC, the Category is Attribute (A) 34518FC,the Object Class is Identification Scheme-Agency 35820FC, the Propertyis Identification 35822FC, the Representation/Association is Identifier35824FC, the Type is XSD 35826FC, the Type Name is token 35828FC, andthe Length is from one to sixty 35830FC. The Cardinality is zero or one35832FC.

The scheme Agency ID 35816FC is the Business System in which theidentifier was assigned. The GDT is defined with a length of twentycharacters in accordance with the /SCWM/DE-PSID (CHAR20).

(xxxxxxxxxxxxxxx) PackingBillOfMaterialItemID

A GDT PackingBillOfMaterialItemID 35800FD is a unique identifier of anitem of a packing bill of material. An item of a packing bill ofmaterial is either a certain quantity of content to be packed or apackaging material that can be used for packaging. An example of a GDTPackingBillOfMaterialItemID 35800FD is:

<PackingBillOfMaterialItemID>5</PackingBillOfMaterialItemID>

The structure of GDT PackingBillOfMaterialItemID 35800FD is depicted inFIG. 358FD. For the GDT PackingBillOfMaterialItemID 35800FD, the ObjectClass is Packing Bill Of Material Item 35802FD, the Property isIdentification 35804FD, the Representation/Association is Identifier35806FD, the Type is CCT 35808FD, the Type Name is Identifier 35810FD,and the Length is from one to eight 35812FD. The remark 35814FD showsthat GDT PackingBillOfMaterialItemID 35800FD may be restricted.

The GDT PackingBillOfMaterialItemID 35800FD is a sequence of numberswith a maximum length of eight characters. Leading zeros are notsignificant. The GDT PackingBillOfMaterialItemID 35800FD can be used toenumerate the several items of a packing bill of material. The GDT isdefined with a length of eight characters in accordance with the dataelement/SCWM/DE_PS_CONTENT_SEQ (CHAR8).

(yyyyyyyyyyyyyyy) PartialDeliveryControlCode

A GDT PartialDeliveryControlCode 35800FE is the coded representation ofthe partial delivery control. The partial delivery control specifieswhether and in which form a customer allows partial deliveries. Anexample of a GDT PartialDeliveryControlCode 35800FE is:

<PartialDeliveryControlCode>1</PartialDeliveryControlCode>

The structure of GDT PartialDeliveryControlCode 35800FE is depicted inFIG. 358FE. For the GDT PartialDeliveryControlCode 35800FE, the ObjectClass is Partial Delivery 35802FE, the Property is Control 35804FE, theRepresentation/Association is Code 35806FE, the Type is CCT 35808FE, theType Name is Code 35810FE, and the Length is from one to two 35812FE.The remark 35814FE shows that GDT PartialDeliveryControlCode 35800FE maybe restricted.

The GDT PartialDeliveryControlCode 35800FE is a fixed SAP code list. Theattributes are as follows: listID=“10095”, listAgencyID=“310”, andlistVersionID which is the version of the relevant code list assignedand managed by SAP AG.

The code list for the GDT PartialDeliveryControlCode 35800FE includesvalues from one to seven. This code list is fixed and may not be changedby the customer.

Code one is partial delivery indicating that partial deliveries areallowed. Code two is one-time delivery on requested delivery date/time,indicating that only one delivery on the requested delivery date/time isallowed. Code three is complete delivery indicating that only a completedelivery, i.e. the entire quantity, is allowed. Code four is completedelivery of order indicating, for the order that only a completedelivery, i.e. the entire quantity, is allowed. Code five is one-timedelivery of order on requested delivery date/time. This indicates thatfor the order only one delivery on the requested delivery date/time isallowed. Code six is one-time delivery of item on requested deliverydate/time. This indicates that for the item only one delivery on therequested delivery date/time is allowed. Partial deliveries for theorder are allowed. Code seven is complete delivery item. This indicatesthat for the item only a complete delivery, i.e. the entire quantity, isallowed. Partial deliveries for the order are allowed.

The GDT PartialDeliveryControlCode 35800FE may currently be used inbusiness objects and A2A messages. In the code list only one value fordescribing partial delivery agreements is allowed. Codes 1, 2, 3 are tobe used only for documents. Codes 4, 5, 6, 7 are to be used for masterdata. The GDT PartialDeliveryControlCode 35800FE can be used, forexample, in the sales order and in the customer master. The individualcharacteristics of the partial delivery control specify basic deliveryagreements with reference to the maximum number of partial deliveries,date/time and quantity tolerances, and delivery groups that may be takeninto consideration when deliveries are created.

(zzzzzzzzzzzzzzz) PaymentAdviceTypeCode

A GDT PaymentAdviceTypeCode 35800FF is the coded representation of thetype of a payment advice note. An example of a GDT PaymentAdviceTypeCode35800FF is:

<PaymentAdviceTypeCode>1</PaymentAdviceTypeCode>

The structure of GDT PaymentAdviceTypeCode 35800FF is depicted in FIG.358FF. For the GDT PaymentAdviceTypeCode 35800FF, the Object Class isPayment Advice 35802FF, the Property is Type 35804FF, theRepresentation/Association is Code 35806FF, the Type is CCT 35808FF, theType Name is Code 35810FF, and the Length is from one to two 35812FF.The remark 35814FF shows that GDT PaymentAdviceTypeCode 35800FF may berestricted.

The GDT PaymentAdviceTypeCode 35800FF is an SAP code list with theimplicitly given attributes listID=“10058”, listAgencyID=“310” andlistVersionID=“tbd”.

The code list for the GDT PaymentAdviceTypeCode 35800FF includes codesone, two and three. Code one indicates a business partner payment advicenote, which is a payment advice note from the business partner. Code twoindicates a debit payment advice note. A debit payment advice note is apayment advice note from the house bank which notifies of a debit of thereceiver's bank account. Code three indicates a credit memo paymentadvice note. A credit memo payment advice note is a payment advice notefrom the house bank which notifies of a cash receipt to the receiver'sbank account.

The GDT PaymentAdviceTypeCode 35800FF can be used to specify the type ofa payment advice note. In the liquidity forecast, assumptions can bemade about the time and probability of an incoming payment of thenotified amount.

A payment advice note message with the PaymentAdviceTypeCode 1corresponds to the IDoc message type REMADV.A payment advice notemessage with the PaymentAdviceTypeCode 2 corresponds to the IDoc messagetype DEBADV. A payment advice note message with thePaymentAdviceTypeCode 3 corresponds to the IDoc message type CREADV.

(aaaaaaaaaaaaaaaa) PaymentBlock

A GDT PaymentBlock 35800FG specifies the reason and time for a businessdocument block in payment transactions. An example of a GDT PaymentBlock35800FG is: <PaymentBlock> <BlockingReasonCode>1</BlockingReasonCode><ExpirationDateTime>2004-04-19T12:21Z</ExpirationDateTime><CreationUserAccountID>4711</CreationUserAccountID><CreationDateTime>2004-04-19T12:21Z</CreationDateTime> </PaymentBlock>

The structure of GDT PaymentBlock 35800FG is depicted in FIG. 358FG. Forthe GDT PaymentBlock 35800FG, the Object Class is Payment Block 35802FG,the Representation/Association is Details 35804FG, and the Type is GDT35806FG.

For the Blocking Reason Code 35808FG, the Category is Element (E)34510FG, the Object Class is Payment Block 35812FG, the Property isBlocking Reason Code 35814FG, the Representation/Association is Code35816FG, the Type is GDT 35818FG, and the Type Name is Blocking ReasonCode 35820FG. The Cardinality is zero or one 35822FG.

For the Expiration Date Time 35824FG, the Category is Element (E)34526FG, the Object Class is Payment Block 35828FG, the Property isExpiration Date Time 35830FG, the Representation/Association is DateTime 35832FG, the Type is GDT 35834FG, and the Type Name is Date Time35836FG. The Cardinality is one 35838FG.

For the Creation User Account ID 35840FG, the Category is Element (E)34542FG, the Object Class is Payment Block 35844FG, the Property isCreation User Account ID 35846FG, the Representation/Association isIdentifier 35848FG, the Type is GDT 35850FG, and the Type Name is UserAccount ID 35852FG. The Cardinality is zero or one 35854FG.

For the Creation Date Time 35856FG, the Category is Element (E) 34558FG,the Object Class is Payment Block 35860FG, the Property is Creation DateTime 35862FG, the Representation/Association is Date Time 35864FG, theType is GDT 35866FG, and the Type Name is Date Time 35868FG. TheCardinality is zero or one 35870FG.

The Blocking Reason Code 35808FG specifies the reason for thePaymentBlock. The Expiration Date Time 35824FG specifies the date andtime until the block is valid. The Creation User Account ID 35840FGspecifies the user ID of the person who has set the PaymentBlock. TheCreation Date Time 35856FG specifies the date and time when thePaymentBlock was set.

A time stamp 9999-12-31T23:59:59Z in the Expiration Date Time 35824FGmeans that the block is valid indefinitely. The PaymentBlock can beused, for example, in invoices to block them for payment.

(bbbbbbbbbbbbbbbb) PaymentCardCategoryCode

A GDT PaymentCardCategoryCode 35800FH is the coded representation of thecategory of a payment card. Payment cards are divided into a fewcategories according to the criteria acceptance and function, forexample, in credit cards and customer cards. An example of a GDTPaymentCardCategoryCode 35800FH is:

<PaymentCardCategoryCode>1</PaymentCardCategoryCode>

The structure of GDT PaymentCardCategoryCode 35800FH is depicted in FIG.358FH. For the GDT PaymentCardCategoryCode 35800FH, the Object Class isPayment Card 35802FH, the Property is Category 35804FH, theRepresentation/Association is Code 35806FH, the Type is CCT 35808FH, theType Name is Code 35810FH, and the Length is from one to two 35812FH.The remark 35814FH shows that GDT PaymentCardCategoryCode 35800FH may berestricted.

The GDT PaymentCardCategoryCode 35800FH is a fixed SAP code list. Theattributes of the CCT Code are filled implicitly with the followingvalues: listID=“10059”, listAgencyID=“310”, and listVersionID which isthe version of the code list assigned and administered by SAP AG.

The GDT PaymentCardCategoryCode 35800FH can be used in the GDTPaymentCard. Possible code values for the GDT PaymentCardCategoryCode35800FH are one, two and three. One is a credit card indicating that thepayment card is a credit card. Two is a debit card indicating thepayment card is a payment card on the basis of sufficient funds. Threeis a customer card indicating the payment card is a customer card withpayment function.

(cccccccccccccccc) PaymentCardTypeCode

A GDT PaymentCardTypeCode 35800FI is the coded representation of thetype of payment card. An example of a GDT PaymentCardTypeCode 35800FIis:

<PaymentCardTypeCode>3</PaymentCardTypeCode>

The structure of GDT PaymentCardTypeCode 35800FI is depicted in FIG.358FI. For the GDT PaymentCardTypeCode 35800FI, the Object Class isPayment Card 35802FI, the Property is Payment Card Type 35804FI, theRepresentation/Association is Code 35806FI, the Type is CCT 35808FI, theType Name is Code 35810FI, and the Length is from one to four 35812FI.The remark 35814FI shows that GDT PaymentCardTypeCode 35800FI may berestricted.

The GDT PaymentCardTypeCode 35800FI can be used in the GDT PaymentCard.There can be five code values for the GDT PaymentCardTypeCode 35800FI.One is American Express for an American Express card. Two is VISA for aVISA card. Three is Mastercard for a Mastercard card. Four is Diners fora Diners card. Five is maestro for maestro.

The GDT PaymentCardTypeCode 35800FI is a fixed SAP code list. Theattributes of the CCT Code are filled implicitly with the followingvalues: listID=“10060”, listAgencyID=“310”, and listVersionID which isthe version of the code list assigned and administered by SAP AG.

(dddddddddddddddd) PaymentDifferenceReasonCode

A GDT PaymentDifferenceReasonCode 35800FJ is the coded representation ofthe reason for a payment difference. A payment difference is theamount-based difference between the expected payment and the actualpayment. A reason for a payment difference may be the deduction offreight costs. An example of a GDT PaymentDifferenceReasonCode 35800FJis:

<PaymentDifferenceReasonCode>40</PaymentDifferenceReasonCode>

The structure of GDT PaymentDifferenceReasonCode 35800FJ is depicted inFIG. 358FJ. For the GDT PaymentDifferenceReasonCode 35800FJ, the ObjectClass is Payment Difference 35802FJ, the Property is Reason 35804FJ, theRepresentation/Association is Code 35806FJ, the Type is CCT 35808FJ, theType Name is Code 35810FJ, and the Length is from one to three 35812FJ.The remark 35814FJ shows that GDT PaymentDifferenceReasonCode 35800FJmay be restricted.

Exactly one fixed standard code list UN/EDIFACT 4465 is permitted(www.unece.org/trade/untdid/d00a/tred/tred4465.htm) is to be assigned tothe code. The attributes can be assigned values as follows:listID=“4465”, listAgencyID=“6”, listVersionID=[version of the code listwhich is assigned by the standardization organization (if available)].

(eeeeeeeeeeeeeeee) PaymentInstruction

A GDT PaymentInstruction 35800FK is an instruction about how a paymentshould be carried out or which additional activities should be carriedout within a payment. An example of a GDT PaymentInstruction 35800FK is:

Payee should be called: <PaymentInstruction>   <ID>1</ID>   <CodelistID=”MT103” listAgencyID=”17”>PHOB</Code>  <CodeDescription>Telephone notification to beneficiary</  CodeDescription> <Note>+49 6227 747474</Note> </PaymentInstruction>Payment should only take place after the payee has been identified:<PaymentInstruction>   <ID>2</ID>   <Code listID=”MT103”listAgencyID=”17”>HOLD</Code>   <CodeDescription>Payment only afteridentification</   CodeDescription> </PaymentInstruction>

The structure of GDT PaymentInstruction 35800FK is depicted in FIG.358FK. For the GDT PaymentInstruction 35800FK, theRepresentation/Association is Details 35802FK.

For the ID 35804FK, the Representation/Association is Identifier35806FK, the Type is CCT 35808FK, the Type Name is Identifier 35810FK,and the Length is one 358312FK. The Cardinality is one 35814FK

For the Code 35816FK, the Representation/Association is Code 35818FK,the Type is GDT 35820FK, the Type Name is Payment Instruction Code35822FK. The Cardinality is one 35824FK.

For the Code Description 35826FK, the Representation/Association is Text35828FK, the Type is GDT 35830FK, the Type Name is Description 35832FK.The Cardinality is zero or one 35834FK.

For the Note 35836FK, the Representation/Association is Text 35838FK,the Type is GDT 35840FK, the Type Name is Note 35842FK. The Cardinalityis zero or one 35844FK.

The ID 35804FK is an identifier for an instruction, i.e. positionnumber. Up to four instructions are possible for a payment order inpayment transactions. The position number identifies these instructions.In some countries, the code of the instruction can be interpretedtogether with the position number. The Code 35816FK is a type ofinstruction. The Code Description 35826FK is a description of the typeof instruction. The Note 35836FK is an additional note with textualinformation that can be interpreted by an accounting clerk dependent onthe GDT PaymentInstruction 35800FK.

Instructions can be entered with a payment order to note that therecipient wants to be called by his bank as soon as the payment arrivesor to note that the payment can be carried out if the recipient canidentify himself.

(ffffffffffffffff) PaymentInstructionCode

A GDT PaymentInstructionCode 35800FL is the coded representation of aninstruction for a payment. An example of a GDT PaymentInstructionCode35800FL is:

<PaymentInstructionCode>PHON</PaymentInstructionCode>

The structure of GDT PaymentInstructionCode 35800FL is depicted in FIG.358FL. For the GDT PaymentInstructionCode 35800FL, the Object Class isPayment Instruction 35802FL, the Representation/Association is Code35804FL, the Type is CCT 35806FL, the Type Name is Code 35808FL and theLength is from one to ten 35810FL. The remark 35812FL shows that GDTPaymentInstructionCode 35800FL may be restricted.

For the list ID 35814FL, the Category is Attribute (A) 34516FL, theObject Class is Code List 35818FL, the Property is Identification35820FL, the Representation/Association is Identifier 35822FL, the Typeis XSD 35824FL, the Type Name is token 35826FL, and the Length is fromone to ten 35827FL. The Cardinality is optional 35828FL.

For the list Agency ID 35830FL, the Category is Attribute (A) 34532FL,the Object Class is Code List Agency 35834FL, the Property isIdentification 35836FL, the Representation/Association is Identifier35838FL, the Type is XSD 35840FL, the Type Name is token 35842FL, andthe Length is from one to sixty 35843FL. The Cardinality is optional35844FL.

For the list Agency-Scheme Agency ID 35846FL, the Category is Attribute(A) 34548FL, the Object Class is Code List Agency 35850FL, the Propertyis Scheme Agency 35852FL, the Representation/Association is Identifier35854FL, the Type is XSD 35856FL, the Type Name is token 35858FL, andthe Length is from one to three 35859FL. The Cardinality is optional35860FL.

Examples of code lists that may be used with the GDTPaymentInstructionCode 35800FL are standard code lists, country-specificcode lists and a proprietary code list.

The attributes are filled as follows to identify standard code lists:listAgencyID=Entry of the organization that the code list assigns inDE3055. The following code lists for the listAgencyID are supported atpresent: listAgencyID=“17” for the code lists according to S.W.I.F.T.guide, and listID=<Name of the SWIFT message format for this instructioncode> such as “MT103”. The listAgencySchemeAgencyID is not applicableThe attributes are filled as follows to identify country-specific codelists: listAgencyID=ISO code of the country according to ISO 3166-1, andlistAgencySchemeAgencyID=“5” (entry for ISO in DE3055). The attributesare filled as follows to identify the SAP proprietary code list:listID=“100611”, listAgencyID=“310”, and listAgencySchemeAgencyID is notapplicable.

A code list consists of a Payment Instruction Code associated with aposition. The position describes the position number of the instructionin which a code can be used. There are fifty-seven Payment InstructionCodes. Payment Instruction Code one is located at position one andindicates a letter (AT). Payment Instruction Code two is located atposition two and indicates a letter/airmail (AT). Payment InstructionCode three is located at position one and indicates a printed matter(AT). Payment Instruction Code four is located at position two andindicates a printed matter/airmail (AT). Payment Instruction Code fiveis located at positions one to three and indicates certified mail (AT).Payment Instruction Code six is located at position two and indicatescertified mail/airmail (AT). Payment Instruction Code seven is locatedat position four and indicates normal (AT). Payment Instruction Codeeight is located at position three and indicates standard normal (AT).Payment Instruction Code nine is located at position one and indicates acollection (BR). Payment Instruction Code ten is located at position oneand indicates due date is changed (BR). Payment Instruction Code elevenis located at position one and indicates field ‘Seu numero’ changed(BR). Payment Instruction Code twelve is located at position one andindicates field ‘Uso da empresa’ changed (BR). Payment Instruction Codethirteen is located at position one and indicates rebate (abatimento)(BR). Payment Instruction Code fourteen is located at position one andindicates rebate is cancelled (BR). Payment Instruction Code fifteen islocated at position one and indicates carried out by notary (BR).Payment Instruction Code sixteen is located at position one andindicates cancellation (BR). Payment Instruction Code seventeen islocated at position one and indicates regular payment order (FI).Payment Instruction Code eighteen is located at position one andindicates S.W.I.F.T. check (FI). Payment Instruction Code nineteen islocated at position one and indicates transfer to an account at the samebank (FI). Payment Instruction Code twenty is located at position oneand indicates Mail transfer (M.T.) (JP). Payment Instruction Codetwenty-one is located at position three and indicates hedged exchangerate (JP). Payment Instruction Code twenty-two is located at positionthree and indicates current rate of exchange (JP). Payment InstructionCode twenty-three is located at position three and indicates currentrate of exchange: payment in JPY equivalent (JP). Payment InstructionCode twenty-four is located at position three and indicates current rateof exchange: payment in PYCUR equivalent (JP). Payment Instruction Codetwenty-five is located at position one and indicates telegraphictransfer (T.T.) (JP). Payment Instruction Code twenty-six is located atposition two and indicates payment to account (JP). Payment InstructionCode twenty-seven is located at position three and indicates payment inJapanese yen (JP). Payment Instruction Code twenty-eight is located atposition two and indicates payment following notification (JP). PaymentInstruction Code thirty is located at position one and indicatesAutoGiro with notification (NO). Payment Instruction Code thirty-one islocated at position one and indicates AutoGiro without notification(NO). Payment Instruction Code thirty-two is located at position two andindicates generate bank check (post office bank, NO). PaymentInstruction Code thirty-three is located at position two and indicatespayment internal to post office bank (NO). Payment Instruction Codethirty-four is located at position two and indicates payment via Nordpay(post office bank, NO). Payment Instruction Code thirty-five is locatedat position two and indicates rapid money transfer (post office bank,NO). Payment Instruction Code thirty-six is located at positions one tofour and indicates notification to beneficiary's bank on best method(SWIFT: “TELE”). Payment Instruction Code thirty-seven is located atpositions one to four and indicates notification to beneficiary on bestmethod (SWIFT: “TELB”). Payment Instruction Code thirty-eight is locatedat positions one to four and indicates notification to intermediary bankon best method (SWIFT: “TELI”). Payment Instruction Code thirty-nine islocated at positions one to four and indicates confirmation of time andday of payment was made (SWIFT: “CONFIRM”). Payment Instruction Codeforty is located at positions one to four and indicates telephonenotification to beneficiary's bank (SWIFT: “PHON”). Payment InstructionCode forty-one is located at positions one to four and indicatestelephone notification to beneficiary (SWIFT: “PHOI”). PaymentInstruction Code forty-two is located at positions one to four andindicates telephone notification to intermediary bank (SWIFT: “PHOB”).Payment Instruction Code forty-three is located at positions one to fourand indicates payment to beneficiary only (SWIFT: “BONL”). PaymentInstruction Code forty-four is located at positions one to four andindicates payment by check only (SWIFT: “CHQB”). Payment InstructionCode forty-five is located at positions one to four and indicatespayment only after identification (SWIFT: “HOLD”). Payment InstructionCode forty-six is located at positions one to four and indicates paymentin settlement of a trade (SWIFT: “CORT”). Payment Instruction Codeforty-seven is located at positions one to four and indicates paymentbetween companies from the same group (SWIFT: “INTC”). PaymentInstruction Code forty-eight is located at positions one to four andindicates immediate payment/express payment order (SWIFT: “URGP”).Payment Instruction Code forty-nine is located at positions one to fourand indicates payment by agreed instruction (SWIFT: “OTHR”). PaymentInstruction Code fifty is located at positions one to four and indicatespayment using gross settlement system (SWIFT: “RTGS”). PaymentInstruction Code fifty-one is located at positions one to four andindicates payment using net settlement system (SWIFT: “NETS”). PaymentInstruction Code fifty-two is located at positions one to four andindicates same day value date at the beneficiary (SWIFT: “SDVA”).Payment Instruction Code fifty-three is located at positions one to fourand indicates following instructions are for beneficiary's bank (SWIFT:“ACC”). Payment Instruction Code fifty-four is located at positions oneto four and indicates following instructions are for recipient'scorrespondent bank (SWIFT: “REC”). Payment Instruction Code fifty-fiveis located at positions one to four and indicates following instructionsare for intermediary bank (SWIFT: “INT”). Payment Instruction Codefifty-six is located at positions one to four and indicates instructinginstitution (SWIFT: “INS”). Payment Instruction Code fifty-seven islocated at positions one to four and indicates information for thebeneficiary (SWIFT: “BNF”).

Some country-specific instruction codes can be interpreted together withthe position number of the instruction. In this case, thecountry-specific code lists contain the position number and instructioncode. The GDT PaymentInstructionCode 35800FL may be used in the GDTPaymentInstruction.

(gggggggggggggggg) InventoryValuationProcedureCode

A GDT InventoryValuationProcedureCode 35800FM is the codedrepresentation of a valuation procedure for an inventory. An inventoryvaluation procedure is a procedure that determines the monetary value ofan inventory. This procedure describes the influence of a businesstransaction on the inventory value and consequently on the calculationof the inventory price. An example of GDTInventoryValuationProcedureCode 35800FM is:

<InventoryValuationProcedureCode>1</InventoryValuationProcedureCode

The structure of GDT InventoryValuationProcedureCode 35800FM is depictedin FIG. 358FM. For the GDT InventoryValuationProcedureCode 35800FM, theObject Class is Inventory Valuation Procedure 35802FM, theRepresentation/Association is Code 35804FM, the Type is CCT 35806FM, theType Name is Code 35808FM and the Length is from one to three 35810FM.

A customer-specific code list is assigned to a code. A customer candetermine the codes in a code list. The attributes of the code areassigned the following values: listAgencyID which is the ID of theCustomer (ID from DE 3055, if listed there), listVersionID which is theversion of the particular code list. Assigned and managed by theCustomer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, or listAgencySchemeAgencyIDwhich is the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme Only one code list is allowed for a GDTInventoryValuationProcedureCode 35800FM. This code list is supplied bySAP and must not be changed by the customer. The attributes of the codeare assigned the following values: listID=“10054”, listAgencyID=“310”,and listVersionID is the version of the code list which is assigned andadministered by SAP AG and is to be determined.

The value range of the GDT InventoryValuationProcedureCode 35800FM maycomprise a proprietary code list. Possible values are one and two. Onedescribes the Standard Price valuation procedure. The Standard Priceprocedure valuates the inventory at a constant inventory price. Thisprice is usually calculated in standard cost planning. Two describes theMoving Average Price valuation procedure. The Moving Average Priceprocedure valuates the inventory at a moving average price. The movingaverage price is recalculated after each business transaction.

(hhhhhhhhhhhhhhhh) LegalEntityTypeCode

A GDT LegalEntityTypeCode 35800FN can represent, in the form of a code,a type of legal entity. A legal entity or legal person is a legalconstruct with rights and obligations, such as the possibility to sign acontract, and to sue or be sued.

This construct is generally an organization, such as a company or agovernment, that is composed exclusively of natural persons and that istreated under certain circumstances as a person in the eyes of the law.This person does not, however, correspond to the persons of which it iscomposed.

The legal personality of a legal person, including any rights,obligations, commitments and transactions, exists independently of everylegal or natural person of which it is composed. Thus, the legalliability of a legal entity does not correspond to the legal liabilityof the natural persons involved. The following are examples of legalentities: Cooperatives, associations, banks, stock corporations, jointstock companies, corporations, government institutions, municipalities,states, political parties, trade unions, trust companies. An example ofa GDT LegalEntityTypeCode 35800FN is:

<LegalEntityTypeCode>2</LegalEntityTypeCode>

The structure of GDT LegalEntityTypeCode 35800FN is depicted in FIG.358FN. For the GDT LegalEntityTypeCode 35800FN, the Property is LegalEntity Type 35802FN, the Representation/Association is Code 35804FN, theType is CCT 35806FN, the Type Name is Code 35808FN and the Length isfrom one to two 35810FN. The remark 35812FN shows that GDTLegalEntityTypeCode 35800FN may be restricted.

For the list ID 35814FN, the Category is Attribute 34516FN, the ObjectClass is Code List 35818FN, the Property is Identification 35820FN, theRepresentation/Association is Identifier 35822FN, the Type is XSD35824FN, and the Type Name is token 35826FN. The Cardinality is zero orone 35828FN.

For the list Agency ID 35830FN, the Category is Attribute 34532FN, theObject Class is Code List Agency 35834FN, the Property is Identification35836FN, the Representation/Association is Identifier 35838FN, the Typeis XSD 35840FN, and the Type Name is token 35842FN. The Cardinality iszero or one 35844FN.

For the list Version ID 35846FN, the Category is Attribute 34548FN, theObject Class is Code List 35850FN, the Property is Version 35852FN, theRepresentation/Association is Identifier 35854FN, the Type is XSD35856FN, and the Type Name is token 35858FN. The Cardinality is zero orone 35860FN.

For the list Agency-Scheme ID 35862FN, the Category is Attribute34564FN, the Object Class is Code List Agency 35866FN, the Property isScheme 35868FN, the Representation/Association is Identifier 35870FN,the Type is XSD 35872FN, and the Type Name is token 35874FN. TheCardinality is zero or one 35876FN.

For the list Agency-Scheme Agency ID 35878FN, the Category is Attribute34580FN, the Object Class is Code List Agency 35882FN, the Property isScheme Agency 35884FN, the Representation/Association is Identifier35886FN, the Type is XSD 35888FN, and the Type Name is token 35890FN.The Cardinality is zero or one 35892FN.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10354”, listAgencyID which is theID of the Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, and listAgencySchemeAgencyIDwhich is the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

The GDT LegalEntityTypeCode 35800FN is essentially used to classify thelegal entities of institutions, events, companies, archives, publicauthorities, natural parks, campaigns (Bread for the World),institutions, and so on. One of its uses with regard to the BusinessPartner, for example, is in the context of statutory reporting byinsurance companies in Germany to the Federal Financial SupervisoryAuthority (BaFin). Business partners or their legal entities are therebyclassified according to BaFin guidelines. The BaFin uses thisinformation to analyze risk spreading. Examples of the possiblesemantics of the codes are: Central bank where the legal entity is acentral bank, Association of local authorities where the legal entity isan association of local authorities, Society where the legal entity is asociety, and Individual enterprise where the legal entity is anindividual enterprise.

The following dictionary objects can be assigned to this GDT in mySAPsystems: Data element: BU_LEGAL_ORG and Domain: BU_LEGAL_ORG.

(iiiiiiiiiiiiiiii) LoanAmortizementCondition

A GDT LoanAmortizementCondition 35800FO is a repayment condition for aloan. It regulates the conditions to which a loan is to be repaid. Aloan can be repaid in the form of regular partial amounts or as a singleamount. Types of repayment that are possible include final repaymentwhere the loan is repaid at the end of its term in one amount. Anothertype of repayment is annuity repayment where annuity comprises initialrepayment and interest amount. Over time the repayment amount increasesand the interest amount decreases. Installment repayment is a type ofrepayment where the loan is repaid in equal installments. An example ofa GDT LoanAmortizementCondition 35800FO is: <LoanAmortizementCondition>  <CalculationDateRecurrence>     <Period>        <StartDate>2005-01-01</StartDate>  <EndDate>2010-01-01</EndDate> </Period>       <Duration>P1M</Duration>      <DaysValue>31</DaysValue>   </CalculationDateRecurrence>  <DueDateRecurrence>       <Duration>P1M</Duration>   <Period>        <StartDate>2005-01-01</StartDate>        <EndDate>2010-01-01</EndDate>   </Period>   </DueDateRecurrence>  <AnnuityRatePercent>3</AnnuityRatePercent></LoanAmortizementCondition>

The repayment condition is valid for the period from Jan. 1, 2005-Jan.1, 2010. An initial repayment of 3% has been agreed. The repayment iscalculated at the end of the month. The first due date for repayment isJan. 1, 2005.

The structure of GDT LoanAmortizementCondition 35800FO is depicted inFIG. 358FO. For the GDT LoanAmortizementCondition 35800FO, the ObjectClass is Loan Amortizement Condition 35801FO, the Property is Details35802FO.

For the Calculation Date Recurrence 35803FO, the Category is Element35804FO, the Object Class is Loan Amortizement Condition 35805FO, theProperty is Calculation Date 35806FO, the Representation/Association isRecurrence 35807FO, the Type is GDT 35808FO, and the Type Name is PeriodDuration Day Recurrence 35809FO. The Cardinality is zero or one 35810FO.

For the Due Date Recurrence 35811FO, the Category is Element 34512FO,the Object Class is Loan Amortizement Condition 35813FO, the Property isDue Date 35814FO, the Representation/Association is Recurrence 35815FO,the Type is GDT 35816FO, and the Type Name is Period Duration DayRecurrence 35817FO. The Cardinality is zero or one 35818FO.

For the Total Amorizement Indicator 35819FO, the Category is Element34520FO, the Object Class is Loan Amortizement Condition 35821FO, theProperty is Total Amorizement 35822FO, the Representation/Association isIndicator 35823FO, the Type is GDT 35824FO, and the Type Name is TotalAmorizement Indicator 35825FO. The Cardinality is zero or one 35826FO.

For the Annuity Rate Percent 35827FO, the Category is Element 34528FO,the Object Class is Loan Amortizement Condition 35829FO, the Property isAnnuity Rate 35830FO, the Representation/Association is Percent 35831FO,the Type is GDT 35832FO, and the Type Name is Percent 35833FO. TheCardinality is zero or one 35834FO.

For the Annuity Rate Amount 35835FO, the Category is Element 34536FO,the Object Class is Loan Amortizement Condition 35837FO, the Property isAnnuity Rate 35838FO, the Representation/Association is Amount 35839FO,the Type is GDT 35840FO, and the Type Name is Amount 35841FO. TheCardinality is zero or one 35842FO.

For the Installment Rate Percent 35843FO, the Category is Element34544FO, the Object Class is Loan Amortizement Condition 35845FO, theProperty is Installment Rate 35846FO, the Representation/Association isPercent 35847FO, the Type is GDT 35848FO, and the Type Name is Percent35849FO. The Cardinality is zero or one 35850FO.

For the Installment Rate Amount 35851FO, the Category is Element34552FO, the Object Class is Loan Amortizement Condition 35853FO, theProperty is Installment Rate 35854FO, the Representation/Association isAmount 35855FO, the Type is GDT 35856FO, and the Type Name is Amount35857FO. The Cardinality is zero or one 35858FO.

The Amortizement Condition may include seven elements. Calculation DateRecurrence indicates the regular recurring date when repayment iscalculated. Due Date Recurrence indicates the regular recurring date forthe due date for a repayment. Total Amortizement Indicator is anindicator showing that the loan is repaid at the end of the term in asingle amount. Annuity Rate Percent indicates an annuity repayment as apercentage. Annuity Rate Amount indicates an annuity repayment as anamount. Installment Rate Percent indicates an installment repayment as apercentage. Installment Rate Amount indicates a repayment amount whenpaying in installments.

One of the following optional elements: Total Amortizement Indicator.Annuity Rate Percent, Annuity Rate Amount, Installment Rate Percent,Installment Rate Amount may need to be stated.

(jjjjjjjjjjjjjjjjjj) LoanFeeCondition

A GDT LoanFeeCondition 35800FP is the fee condition for a loan. Lenderscharge fees for managing a loan account. The fees are either due as asingle payment or in a payment cycle. An example of a GDTLoanFeeCondition 35800FP is: <LoanFeeCondition>  <LoanFeeTypeCode>4711</LoanFeeTypeCode>   <CalculationDateRecurrence>  <Period>       <StartDate>2005-01-01</StartDate>      <EndDate>2010-01-01</EndDate>   </Period>    <Duration>P1Y</Duration>     <OffsetDuration>P1Y</OffsetDuration>  </CalculationDateRecurrence>   <DueDateRecurrence>   <Period>      <StartDate>2005-01-01</StartDate>      <EndDate>2010-01-01</EndDate>   </Period>    <Duration>P1Y</Duration>     <OffsetDuration>P1Y</OffsetDuration>  </DueDateRecurrence>   <RateAmount currencyCode=”EUR”>5</RateAmount></LoanFeeCondition>

Fee condition 4711 is valid for the period from Jan. 1, 2005-Jan. 1,2010. It amounts to 5 Euro per year. The calculation will take place onJan. 1, 2006 for the first time. The fee is due on Jan. 1, 2006 for thefirst time.

The structure of GDT LoanFeeCondition 35800FP is depicted in FIG. 358FP.For the GDT LoanFeeCondition 35800FP, the Representation/Association isDetails 35802FP.

For the Loan Fee Type Code 35804FP, the Category is Attribute 35806FP,the Object Class is Loan Fee Condition 35808FP, the Property is Loan FeeType 35810FP, the Representation/Association is Code 35812FP, the Typeis GDT 35814FP, and the Type Name is Loan Fee Type Code 35816FP. TheCardinality is one 35818FP.

For the Calculation Date Recurrence 35820FP, the Category is Element35822FP, the Object Class is Loan Fee Condition 35824FP, the Property isCalculation 35826FP, the Representation/Association is Recurrence35828FP, the Type is GDT 35830FP, and the Type Name is Period DurationDay Recurrence 35832FP. The Cardinality is one 35834FP.

For the Due Date Recurrence 35836FP, the Category is Element 35838FP,the Object Class is Loan Fee Condition 35840FP, the Property is Due Date35842FP, the Representation/Association is Recurrence 35844FP, the Typeis GDT 35846FP, and the Type Name is Period Duration Day Recurrence35848FP. The Cardinality is zero or one 35850FP.

For the Rate Percent 35852FP, the Category is Element 35854FP, theObject Class is Loan Fee Condition 35856FP, the Property is Rate35858FP, the Representation/Association is Percent 35860FP, the Type isGDT 35862FP, and the Type Name is Percent 35864FP. The Cardinality iszero or one 35866FP.

For the Rate Amount 35868FP, the Category is Element 35870FP, the ObjectClass is Loan Fee Condition 35872FP, the Property is Rate 35874FP, theRepresentation/Association is Amount 35876FP, the Type is GDT 35878FP,and the Type Name is Amount 35880FP. The Cardinality is zero or one35882FP.

The GDT LoanFeeCondition 35800FP may include five elements. Loan FeeType Code specifies the type of fee. Calculation Date Recurrenceindicates the regular recurring date when the fee is to be calculated.Due Date Recurrence indicates the regular recurring date when the fee isdue. Rate Percent specifies a relative fee based on the loan amount.Rate Amount represents the absolute fee.

One of the following optional elements may be stated: Rate Percent orRate Amount. The GDT LoanFeeCondition 35800FP can be used to specify thefee condition for a loan.

(kkkkkkkkkkkkkkkk) LoanFeeTypeCode

A GDT LoanFeeTypeCode 35800FQ is the coded representation of the type ofloan fee. An example of a GDT LoanFeeTypeCode 35800FQ is:

<LoanFeeTypeCode>1101</LoanFeeTypeCode>

The structure of GDT LoanFeeTypeCode 35800FQ is depicted in FIG. 358FQ.For the GDT LoanFeeTypeCode 35800FQ, the Object Class is Loan Fee35802FQ, the Property is Type 35804FQ, the Representation/Association isCode 35806FQ, the Type is CCT 35808FQ, the Type Name is Code 35810FQ andthe Length is from one to ten 35812FQ. The remark 35814FQ shows that GDTLoanFeeTypeCode 35800FQ may be restricted.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10355”, listAgencyID which is theID of the Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, and listAgencySchemeAgencyIDwhich is the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

Examples of types of loan fees include account management fees, fees forsubscribing to a magazine published by a building and loan association,fees for viewing the usage object, and contribution for credit lifeinsurance.

In the SAP ERP system the GDT LoanFeeTypeCode 35800FQ is based on thedata element/domain SKOART in the software component EA-FINSERV. Thevalue range for the domain is defined by entries from an underlyingCustomizing table. SAP does not supply Customizing for this table.

(llllllllllllllll) LoanInterestCondition

A GDT LoanInterestCondition 35800FR is a condition for calculating theinterest on a loan. The interest calculation represents the price forthe capital transferred. An example of a GDT LoanInterestCondition35800FR is: <LoanInterestCondition>   <CalculationRecurrence>   <Period>      <StartDate>2005-01-01</StartDate>      <EndDate>2010-01-01</EndDate>   </Period>    <Duration>P1M</Duration>     <DaysValue>31</DaysValue>  </CalculationRecurrence>   <DueDateRecurrence>   <Period>      <StartDate>2005-01-01</StartDate>      <EndDate>2010-01-01</EndDate>   </Period>    <Duration>P1M</Duration>     <OffsetDuration>P1M</OffsetDuration>  </DueDateRecurrence>  <FixedInterestRatePercent>8</FixedInterestRatePercent></LoanInterestCondition>

The interest condition is valid for the period from Jan. 1, 2005-Jan. 1,2010. The interest rate amounts to 8% per year. Interest is calculatedmonthly. The interest is calculated for the first time on Jan. 31, 2005.Interest is due for the first time on Feb. 1, 2005. It is an interestpayment in arrears.

The structure of GDT LoanInterestCondition 35800FR is depicted in FIG.358FR. For the GDT LoanInterestCondition 35800FR the Object Class isLoan Interest Condition 35802FR, and the Property is Details 35804FR.

For the Calculation Date Recurrence 35806FR, the Category is Element35808FR, the Object Class is Loan Interest Condition 35810FR, theProperty is Calculation Date 35812FR, the Representation/Association isRecurrence 35814FR, the Type is GDT 35816FR, and the Type Name is PeriodDuration Day Recurrence 35818FR. The Cardinality is one 35820FR.

For the Due Date Recurrence 35822FR, the Category is Element 35824FR,the Object Class is Loan Interest Condition 35826FR, the Property is DueDate 35828FR, the Representation/Association is Recurrence 35830FR, theType is GDT 35832FR, and the Type Name is Period Duration Day Recurrence35834FR. The Cardinality is zero or one 35836FR.

For the Fixed Interest Rate Percent 35838FR, the Category is Element35840FR, the Object Class is Loan Interest Condition 35842FR, theProperty is Fixed Interest Rate 35844FR, the Representation/Associationis Percent 35846FR, the Type is GDT 35848FR, and the Type Name isPercent 35850FR. The Cardinality is zero or one 35852FR.

For the Variable Interest Rate Percent 35854FR, the Category is Element35856FR, the Object Class is Loan Interest Condition 35858FR, theProperty is Variable Interest Rate 35860FR, theRepresentation/Association is Variable Interest Rate 35862FR, the Typeis GDT 35864FR, and the Type Name is Variable Interest Rate 35866FR. TheCardinality is zero or one 35868FR.

The GDT LoanInterestCondition 35800FR includes four elements.Calculation Date Recurrence indicates the regular recurring date forcalculating interest payments. Due Date Recurrence indicates the regularrecurring date when interest payments are due. Fixed Interest RatePercent defines a fixed interest rate. Variable Interest Rate defines avariable interest rate.

One of the following optional sub-elements needs to be stated: FixedInterest Rate Percent or Variable Interest Rate. You can use the GDTLoanInterestCondition 35800FR to specify the interest conditions for thecapital transferred, for example, a loan.

(mmmmmmmmmmmmmmmmmm) LoanKeyFigureTypeCode

A GDT LoanKeyFigureTypeCode 35800FS is the coded representation of thetype of key figures for a loan. An example of a GDTLoanKeyFigureTypeCode 35800FS is:

<LoanKeyFigureTypeCode>1</LoanKeyFigureTypeCode>

The structure of GDT LoanKeyFigureTypeCode 35800FS is depicted in FIG.358FS. For the GDT LoanKeyFigureTypeCode 35800FS, the Object Class isLoad Key FIG. 35802FS, the Property is Type 35804FS, theRepresentation/Association is Code 35806FS, the Type is CCT 35808FS, theType Name is Code 35810FS, and the Length is from one to two 35812FS.The remark 35814FS shows that GDT LoanKeyFigureTypeCode 35800FS may berestricted.

Valid code list values include the following five codes. Code one,commitment capital, describes the commitment capital for a loan. Codetwo, term, describes the term of a loan. Code three, installment,describes the installment for a loan. Code four, effective interestrate, describes the effective interest rate for a loan. Code five,payment schedule, describes the payment schedule for a loan.

Loan figures are needed to create loan offers. The GDTLoanKeyFigureTypeCode 35800FS can be used to request the calculation ofconcrete figures for a loan from a loan calculation service.

The LoanKeyFigureTypeCode is a SAP proprietary code list with predefinedvalues. If you change permitted values then you also have to makechanges to interfaces.

(nnnnnnnnnnnnnnnn) LoanPaymentPlanItem

A GDT LoanPaymentPlanItem 35800FT is a loan payment planned for a keydate. An example of a GDT LoanPaymentPlanItem 35800FT is:<LoanPaymentPlanItem>   <PaymentDate>2005-02-01</PaymentDate>  <InstalmentAmount currencyCode=”EUR”> 3101.00</   InstalmentAmount>  <InterestAmount currencyCode=”EUR”>2100.01</InterestAmount>  <RepaymentAmount currencyCode=   ”EUR”>1000.99<RepaymentAmount>  <FeeAmount currencyCode=”EUR”>0.00</FeeAmount>   <BalanceAmountcurrencyCode=   ”EUR”>122354.43 </BalanceAmount> </LoanPaymentPlanIterm>

The structure of GDT LoanPaymentPlanItem 35800FT is depicted in FIG.358FT. For the GDT LoanPaymentPlanItem 35800FT, the Property is LoanPayment Plan Item 35801FT, and the Representation/Association is Details35802FT.

For the Payment Due 35803FT, the Category is Element 35804FT, the ObjectClass is Loan Payment Plan Item 35805FT, the Property is Payment35806FT, the Representation/Association is Date 35807FT, the Type is GDT35808FT, and the Type Name is Date 35809FT. The Cardinality is one35810FT.

For the Installment Amount 35811FT, the Category is Element 35812FT, theObject Class is Loan Payment Plan Item 35813FT, the Property isInstallment 35814FT, the Representation/Association is Amount 35815FT,the Type is GDT 35816FT, and the Type Name is Amount 35817FT. TheCardinality is zero to one 35818FT.

For the Interest Amount 35819FT, the Category is Element 35820FT, theObject Class is Loan Payment Plan Item 35821FT, the Property is Interest35822FT, the Representation/Association is Amount 35823FT, the Type isGDT 35824FT, and the Type Name is Amount 35825FT. The Cardinality iszero to one 35826FT.

For the Repayment Amount 35827FT, the Category is Element 35828FT, theObject Class is Loan Payment Plan Item 35829FT, the Property isRepayment 35830FT, the Representation/Association is Amount 35831FT, theType is GDT 35832FT, and the Type Name is Amount 35833FT. TheCardinality is zero to one 35834FT.

For the Fee Amount 35835FT, the Category is Element 35836FT, the ObjectClass is Loan Payment Plan Item 35837FT, the Property is Fee 35838FT,the Representation/Association is Amount 35839FT, the Type is GDT35840FT, and the Type Name is Amount 35841FT. The Cardinality is zero toone 35842FT.

For the Balance Amount 35843FT, the Category is Element 35844FT, theObject Class is Loan Payment Plan Item 35845FT, the Property is Balance35846FT, the Representation/Association is Amount 35847FT, the Type isGDT 35848FT, and the Type Name is Amount 35849FT. The Cardinality is one35850FT.

The GDT LoanPaymentPlanItem 35800FT can include six elements. A PaymentDate represents the payment date. An Installment Amount represents theinstallment to be paid which is the total of the interest and repayment.An Interest Amount represents the interest amount to be paid. ARepayment Amount represents the repayment amount to be paid. Fee Amountrepresents the fees to be paid. A Balance Amount represents theremaining debt on the loan, which is the balance amount.

(oooooooooooooooo) LoanPurposeCode

A GDT LoanPurposeCode 35800FU is a coded representation of the purposeof a loan. An example of a GDT LoanPurposeCode 35800FU is:

<LoanPurposeCode>2</LoanPurposeCode>

The structure of GDT LoanPurposeCode 35800FU is depicted in FIG. 358FU.For the GDT LoanPurposeCode 35800FU, the Object Class is Loan 35802FU,the Property is Purpose 35804FU, the Representation/Association is Code35806FU, the Type is CCT 35808FU, the Type Name is Code 35810FU and theLength is from one to two 35812FU. The remark 35814FU shows that GDTLoanPurposeCode 35800FU may be restricted.

A customer-specific code list is assigned to the code. A customer candetermine the codes in the code list. The attributes of the code areassigned the following values: listID=“10356”, listAgencyID which is theID of the Customer (ID from DE 3055, if listed there), listVersionIDwhich is the version of the particular code list assigned and managed bythe Customer, listAgencySchemeID which is the ID of the scheme if thelistAgencyID does not come from DE 3055, and listAgencySchemeAgencyIDwhich is the ID of the organization from DE 3055 that manages thelistAgencySchemeID scheme.

Examples of loan purposes include the purchase of real estate,refinancing, home improvement and extension work. Real estate is wherethe loan can be used to purchase real estate, for example a house orcondominium. Refinancing is where the loan can be used for refinancing.Home improvement is where the loan can be used to make improvements toreal estate. Extension work is where the loan can be used to makeextensions to real estate.

In the SAP ERP system the LoanPurposeCode is based on the dataelement/domain SVZWECK from the software component EA-FINSERV.

(pppppppppppppppp) PaymentProcedureCode

A GDT PaymentProcedureCode 35800FV is the coded representation of thepayment procedure. A payment procedure is a technically orientedcharacteristic of a payment transaction, which is in turn aspecialization of the payment form. An example of a GDTPaymentProcedureCode 35800FV is:

<PaymentProcedureCode>1</PaymentProcedureCode>

The structure of GDT PaymentProcedureCode 35800FV is depicted in FIG.358FV. For the GDT PaymentProcedureCode 35800FV, the Object Class isPayment 35802FV, the Property is Procedure 35804FV, theRepresentation/Association is Code 35806FV, the Type is CCT 35808FV, theType Name is Code 35810FV, and the Length is from one to five 35812FV.The remark 35814FV shows that GDT PaymentProcedureCode 35800FV may berestricted.

The GDT PaymentProcedureCode 35800FV is an SAP code list that can beextended by the customers with the implicitly given attributeslistID=“10062”, listAgencyID=“310” and listVersionID=“tbd”.

Possible code values for the GDT PaymentProcedureCode 35800FV are onethrough eight. One describes a domestic bank transfer. The domestic banktransfer is a payment that consists of a bank transfer from one backaccount to another in the same country. Two describes a foreign banktransfer. The foreign bank transfer is a payment that consists of a banktransfer from one back account to another in different countries. Threedescribes an EU internal transfer. The EU internal transfer is a paymentthat consists of a bank transfer from one back account to another in theEuro zone. Four is a bank check. The bank check is a payment with acheck which is printed and sent by the bank. This is not to be confusedwith a check confirmed by the bank. Five is a bank check for foreignpayment. The bank check for foreign payment is a foreign payment with acheck which is printed and sent by the bank. This is not to be confusedwith a check confirmed by the bank. Six is a check printing. Checkprinting is a payment with a check where you do the printing yourself.The bank does not print the check. Seven is a bank direct debit. Thebank direct debit is a debit memo in which the payer's bank isauthorized to carry out a direct debit for the payee. Eight is a bankdirect debit. The bank direct debit is a debit memo in which the payeehas an automatic debit authorization of the payer.

The GDT PaymentProcedureCode 35800FV can be used, for example, to informa house bank about the specific formats and forms for payments.

(qqqqqqqqqqqqqqqq) PaymentTransactionReferenceID

A GDT PaymentTransactionReferenceID 35800FW is a reference number for atransaction in payment transactions. An example of a GDTPaymentTransactionReferenceID 35800FW is:  <PaymentTransactionReferenceID>0000001405</PaymentTransactionReferenceID>

The structure of GDT PaymentTransactionReferenceID 35800FW is depictedin FIG. 358FW. For the GDT PaymentTransactionReferenceID 35800FW, theObject Class is Payment Transaction 35802FW, the Property is Reference35804FW, the Representation/Association is Identifier 35806FW, the Typeis CCT 35808FW, the Type Name is Identifier 35810FW, and the Length isfrom one to thirty-five 35812FW.

The GDT PaymentTransactionReferenceID 35800FW is assigned by a bank or aparty to uniquely identify a transaction in payment transactions. It isonly unique in the context of the bank or party and is also onlyinterpreted by them. For this reason, the scheme ID and scheme Agency IDattributes are not required. The bank or party that has assigned thereference may be known in the context.

The GDT PaymentTransactionReferenceID 35800FW can be used in a bankstatement, for example, to convey a unique identification of thebusiness transaction that was assigned by the bank. This has led to aturnover on the account, for example, a payment or a debit by accountmaintenance charges. The GDT PaymentTransactionReferenceID 35800FW canbe used to identify the business transaction in the case of queries thatmay be made at the bank.

There does not have to be a business document, i.e. aBusinessTransactionDocument, for the business transaction which isreferenced with the GDT PaymentTransactionReferenceID 35800FW.

(iiiiiiiiiiiiiiii) PaymentTransactionTypeCode

A GDT PaymentTransactionTypeCode 35800FX is the coded representation ofthe type of a payment transaction. An example of a GDTPaymentTransactionTypeCode 35800FX is:  <PaymentTransactionTypeCodelistAgencyID=“310“>1</PaymentTransactionTypeCode>

The structure of GDT PaymentTransactionTypeCode 35800FX is depicted inFIG. 358FX. For the GDT PaymentTransactionTypeCode 35800FX, the ObjectClass is Payment Transaction 35802FX, the Property is Type 35803FX, theRepresentation/Association is Code 35804FX, the Type is CCT 35806FX, theType Name is Code 35808FX and the Length is from one to four 35810FX.The remark 35812FX shows that GDT PaymentTransactionTypeCode 35800FX maybe restricted.

For the list ID 35814FX, the Category is Attribute (A) 34516FX, theObject Class is Code List Agency 35818FX, the Property is Identification35820FX, the Representation/Association is Identifier 35822FX, the Typeis XSD 35824FX, the Type Name is token 35826FX, and the Length is fromone to sixty 35827FX. The Cardinality is optional 35828FX.

For the list Agency Scheme Agency ID 35830FX, the Category is Attribute(A) 34532FX, the Object Class is Code List Agency 35834FX, the Propertyis Identification 35836FX, the Representation/Association is Identifier35838FX, the Type is XSD 35840FX, the Type Name is token 35842FX, andthe Length is from one to three 35843FX. The Cardinality is optional35844FX.

For the list Agency-Scheme Agency ID 35846FX, the Category is Attribute(A) 34548FX, the Object Class is Code List Agency 35850FX, the Propertyis Scheme Agency 35852FX, the Representation/Association is Identifier35854FX, the Type is XSD 35856FX, the Type Name is token 35858FX, andthe Length is from one to three 35859FX. The Cardinality is optional35860FX.

The attributes are filled as follows to identify standard code lists:listAgencyID=Entry of the organization that the code list assigns inDE3055. The following code lists are supported at present:listAgencyID=“17” for the code list according to S.W.I.F.T. guide,listAgencyID=“131” for the code list of the central credit committee ofthe Association of German Banks, listAgencyID=“tbd” for the code list ofthe Bankers Association of America, listAgencySchemeAgencyID is notapplicable. The attributes are filled as follows to identifybank-specific code lists: listAgencyID=SWIFT Bank Identification Code(BIC) of the bank (see GDT BankStandardID),listAgencySchemeAgencyID=“17” (entry for S.W.I.F.T. in DE 3055). Theattributes are filled as follows to identify the SAP proprietary codelist: listID=“10042” (for documentation only), listAgencyID=“310” (entryfor SAP in DE 3055), listAgencySchemeAgencyID is not applicable.

Examples of code lists that may be used with the GDTPaymentTransactionTypeCode 35800FX are standard code lists,bank-specific code lists, and a proprietary code list. A code list mayconsist of seventeen codes. Code one is a bank transfer order which isan outgoing payment by transfer to another bank account, internallyinitiated. Code two is a bank transfer credit which is an incomingpayment by externally initiated bank transfer. Code three is a debitmemo, i.e. direct debit, which is an outgoing payment by externallyinitiated debit memo. Code four is a debit memo deposit which is acollection from one bank account to another bank account, i.e. directdebit, internally initiated. Code five is cashed checks which is anoutgoing payment by cashing an outgoing check, also known as checkpayment confirmation. Code six is a check encashment which is anincoming payment by cashing an incoming check. Code seven is a bill ofexchange collection which is an incoming payment by bill of exchangepresentation. Code eight is a payment by bill of exchange which is anoutgoing payment by payment by bill of exchange.<PeriodDurationDayRecurrence> <Period> <StartDate>2004-04-12</StartDate><EndDate>2004-04-06</EndDate> </Period><InteriorDuration>P7T</InteriorDuration> </ PeriodDurationDayRecurrence>Weekly recurrences between 4/12/2004 and 6/6/2004

<PeriodDurationDayRecurrence> <Period> <StartDate>2005-02-15</StartDate><EndDate>2010-02-14</EndDate> </Period><InteriorDuration>P1M</InteriorDuration><MonthDayValue>31</MonthDayValue> </ PeriodDurationDayRecurrence>

Code nine is a card payment which is an incoming payment by cardpayment. Code ten is a cash withdrawal. Code eleven is a cash deposit.Code twelve is a lockbox which is an incoming payment by lockbox. Codeninety-one is a credit interest which is an incoming payment by creditinterest. Code ninety-two is a debit interest which is an incomingpayment by debit interest. Code ninety-three is a charge which is anoutgoing payment by bank charges. Code nine hundred ninety-eight is forother incoming payments. Code nine hundred ninety-nine is for otheroutgoing payments.

The GDT PaymentTransactionTypeCode 35800FX can be used to specify thetype of turnover for a bank statement item in a bank statement withoutgoing into bank and country-specific details. To give a user as muchdetailed information as possible about a bank statement, the originalbank-specific codes for the type of a transaction are transferred.Information that could be useful for the user to understand the bankstatement would possibly be lost when mapping to the code list.

(ssssssssssssssss) PeriodDurationDayRecurrence

A GDT PeriodDurationDayRecurrence 35800FY is a representation for therepeated occurrence of an event within a time period whereby therecurrence takes place at the end of a determined duration period or ata time specified in relation to the beginning of a period. The event isnonrecurring and excludes recurring time periods.

The element Period describes the time period. The elementInteriorDuration describes the time frames, i.e. duration period, withinthis time period. Examples of a GDT PeriodDurationDayRecurrence 35800FYare:

Example 1:

Monthly recurrences at the end of each month between Feb. 15, 2005 andFeb. 14, 2010”, that is on Feb. 28, 2005, Mar. 31, 2005, and Apr. 30,2005, and so on.

Example 3: <PeriodDurationDayRecurrence>   <Period>      <StartDate>2005-01-01</StartDate>      <EndDate>2009-12-31</EndDate>   </Period>    <InteriorDuration>P1M</InteriorDuration>    <OffsetDuration>P2M</OffsetDuration>    <MonthDayValue>31</MonthDayValue> </ PeriodDurationDayRecurrence >

Event first occurs on: Mar. 31, 2005. The following events take placemonthly on: Apr. 30, 2005, May 31, 2005, and so on.

The structure of GDT PeriodDurationDayRecurrence 35800FY is depicted inFIG. 358FY. For the GDT PeriodDurationDayRecurrence 35800FY the ObjectClass is Period Duration Day Recurrence 35802FY, and theRepresentation/Association is Details 35804FY.

For the Period 35806FY, the Category is Element (E) 35808FY, the ObjectClass is Period Duration Day Recurrence 35810FY, the Property is Period35812FY, the Representation/Association is Date Period 35814FY, the Typeis GDT 35816FY, and the Type Name is Date Period 35818FY. TheCardinality is one 35820FY.

For the Interior Duration 35822FY, the Category is Element (E) 35824FY,the Object Class is Period Duration Day Recurrence 35826FY, the Propertyis Interior 35828FY, the Representation/Association is Duration 35830FY,the Type is GDT 35832FY, and the Type Name is Duration 35834FY. TheCardinality is one 35836FY.

For the Offset Duration 35838FY, the Category is Element (E) 35840FY,the Object Class is Period Duration Day Recurrence 35842FY, the Propertyis Offset 35844FY, the Representation/Association is Duration 35846FY,the Type is GDT 35848FY, and the Type Name is Duration 35850FY. TheCardinality is zero or one 35852FY.

For the Month Day Value 35854FY, the Category is Element (E) 35856FY,the Object Class is Period Duration Day Recurrence 35858FY, the Propertyis Month Day 35860FY, the Representation/Association is Value 35862FY,the Type is GDT 35864FY, and the Type Name is Integer Value 35866FY. TheCardinality is zero or one 35868FY.

The GDT PeriodDurationDayRecurrence 35800FY may include four elements. APeriod indicates the time period within which recurrences take place. AnInterior Duration indicates the time frame after which, or in relationto the beginning of which, recurrences take place. An Offset Durationindicates the time frame in which an event takes place after a specifiedperiod has begun. A Month Day Value indicates the calendar day within amonth on which the event takes place. The GDTPeriodDurationDayRecurrence 35800FY may contain the element Month DayValue where a value equal to thirty-one indicates the end of the month.The value range for the Offset Duration is limited to the period of timedefined in the GDT Duration. You cannot use time ranges.

The combinatorics for Offset Duration and Month Day Value for the GDTPeriodDurationDayRecurrence 35800FY are explained. If neither OffsetDuration nor Month Day Value can be used then the first event occurs atthe end of a period, given by element Interior Duration. If only OffsetDuration can be used then the event takes place a certain length of timeafter the start of a period and this time frame is given by elementOffset Duration. If only Month Day Value can be used then a calendarmonth is fixed by the beginning of an Interior Duration. The event takesplace on the calendar day of the fixed month that is given by theelement Month Day Value. If Offset Duration and Month Day Value are usedthen a calendar month is fixed by the beginning of an Interior Durationplus the element Offset Duration. The event takes place on the calendarday of the fixed month that is given by element Month Day Value.

Qualifiers for the GDT PeriodDurationDayRecurrence 35800FY areDeclaration Period Duration Day Recurrence and Payment Period DurationDay Recurrence.

(tttttttttttttttt) PersonDisabilityCertificateID

A GDT PersonDisabilityCertificateID 35800FZ is a unique identifier for acertificate describing a person's disability. The GDTPersonDisabilityCertificateID 35800FZ is assigned by the authority thatcreated the certificate describing a person's disability. The ID is alsocalled the reference number. An example of a GDTPersonDisabilityCertificateID 35800FZ is:

<PersonDisabilityCertificateID>20003000xyz_(—)01012005</PersonDisabilityCertificateID>

The structure of GDT PersonDisabilityCertificateID 35800FZ is depictedin FIG. 358FZ. For the GDT PersonDisabilityCertificateID 35800FZ, theObject Class is Person Disability Certificate 35802FZ, the Property isIdentification 35804FZ, the Representation/Association is Identifier35806FZ, the Type is CCT 35808FZ, the Type Name is Identifier 35810FZ,and the Length is from one to twenty 35812FZ. The remark 35814FZ showsthat GDT PersonDisabilityCertificateID 35800FZ may be restricted.

The GDT PersonDisabilityCertificateID 35800FZ may be unique within theused context. Therefore, no other attributes are necessary. This datatype can be used in Personnel Administration to identify the certificatesubmitted by an employee describing the employee's disability.

(uuuuuuuuuuuuuuuu) PersonnelEventReasonCode

A GDT PersonnelEventReasonCode 35800GA is the coded representation ofthe reason for a personnel event. A personnel event is an event in anemployee's professional or private life that needs to be documented forthe company. You can assign a reason to personnel events that relate tothe employee, the employment, or the work agreement. The reason dependson the requirements of the company and the country. For example, in thecase of the event type Notice, the reason could be Better careeropportunities. An example of a GDT PersonnelEventReasonCode 35800GA is:

<PersonnelEventReasonCode>1</PersonnelEventReasonCode>

The structure of GDT PersonnelEventReasonCode 35800GA is depicted inFIG. 358GA. For the GDT PersonnelEventReasonCode 35800GA, the ObjectClass is Personnel Event 35804GA, the Property is Reason 35806GA, theRepresentation/Association is Code 35808GA, the Type is CCT 35810GA, theType Name is Code 35812GA and the Length is from one to four 35814GA.The remark 35815CE shows that GDT PersonnelEventReasonCode 35800GA maybe restricted.

For the list Agency ID 35816GA, the Category is Attribute (A) 34518GA,the Object Class is Code List Agency 35820GA, the Property isIdentification 35822GA, the Representation/Association is Identifier35824GA, the Type is XSD 35826GA, and the Type Name is token 35828GA.The Cardinality is zero or one 35830GA.

For the list Version ID 35832GA, the Category is Attribute (A) 34534GA,the Object Class is Code List 35836GA, the Property is Version 35838GA,the Representation/Association is Identifier 35840GA, the Type is XSD35842GA, and the Type Name is token 35844GA. The Cardinality is zero orone 35846GA.

For the list Agency-Scheme ID 35848GA, the Category is Attribute (A)34550GA, the Object Class is Code List Agency 35852GA, the Property isScheme 35854GA, the Representation/Association is Identifier 35856GA,the Type is XSD 35858GA, and the Type Name is token 35860GA. TheCardinality is zero or one 35862GA.

For the list Agency-Scheme Agency ID 35864GA, the Category is Attribute(A) 34566GA, the Object Class is Code List Agency 35868GA, the Propertyis Scheme Agency 35870GA, the Representation/Association is Identifier35872GA, the Type is XSD 35874GA, and the Type Name is token 35876GA.The Cardinality is zero or one 35878GA.

A customer-specific code list is assigned to the GDTPersonnelEventReasonCode 35800GA. A customer defines the codes in thecode list. Only alternative code lists exist that are differentiated atconfiguration and/or runtime. The attributes of PersonnelEventReasonCodecan be assigned the following values: listID=“10104”, listAgencyID whichis the ID of the Customer (ID from DE 3055 if listed there),listVersionID which is assigned and managed by the Customer,listAgencySchemeID which is the ID of the scheme if the listAgencyID isnot taken from DE 3055, and listAgencySchemeAgencyID which is the ID ofthe organization (taken from DE 3055) that manages the scheme of thelistAgencySchemeID.

The GDT PersonnelEventReasonCode 35800GA distinguishes between differentreasons for personnel events. Examples of the possible codes used forthese events may include better career opportunities, health reasons,lacking qualifications, and reorganization. Better career opportunitiescan occur when the employee resigns because of better careeropportunities elsewhere. Health reasons can occur when the employeeresigns for health reasons. Lacking qualifications can occur when theemployer dismisses the employee due to a lack of qualification.Reorganization can occur when the employer dismisses the employee due toa reorganization within the company.

(vvvvvvvvvvvvvvvv) StockLevelControlRequirementTypeCode

A GDT StockLevelControlRequirementTypeCode 35800GB is a codedrepresentation of a requirement type for examining stock quantities andcontrolling stock shortages and surpluses. For example, aStockLevelControlRequirementType may describe the essential nature of astock level control requirement according to the processes that have tobe initiated to meet the requirement. An example of GDTStockLevelControlRequirementTypeCode 35800 GB is:

<StockLevelControlRequirementTypeCode>1</StockLevelControlRequirementTypeCode>

The structure of GDT StockLevelControlRequirementTypeCode 35800GB isdepicted in FIG. 358GB. For the GDT StockLevelControlRequirementTypeCode35800GB, the Object Class is Stock Level Control Requirement 35804GB,the Property is Type 35806GB, the Representation/Association is Code35808GB, the Type is CCT 35810GB, the Type Name is Code 35812GB, and theLength is one 35814GB. The remark 35818GB shows that the GDTStockLevelControlRequirementTypeCode 35800GB may be restricted.

The data type GDT StockLevelControlRequirementTypeCode 35800GB may usethe following codes: 1 (i.e., a requirement for initiation of areplenishment process in order to avoid stock shortage by verifying thatthe stock quantity is above a predefined stock level), 2 (i.e., arequirement for initiation of a cleanup process in order to avoid stocksurplus by verifying that the stock quantity is below a predefined stocklevel), 3 (i.e., a general requirement for initiation of a cleanup orreplenishment process in order to adjust the stock quantity to apredefined stock level).

One fixed SAP code list is typically assigned to theStockLevelControlRequirementTypeCode. The attributes can be assignedvalues as follows: listID=“10168,” listAgencyID=“310,” andlistVersionID=ID of the particular code list. Assigned and man-aged bySAP AG.

(wwwwwwwwwwwwwwwwww) SubledgerAccountGranularityCode

A GDT SubledgerAccountGranularityCode 35800GC is a coded representationof a granularity of a subledger account. For example, a granularity of asubledger account may establish criteria in addition to the company thatserve to differentiate the SubledgerAccounts (such as material and batchfor a MaterialSubledgerAccount). An example of GDTSubledgerAccountGranularityCode 35800GC is:

<SubledgerAccountGranularityCode>1</SubledgerAccountGranularityCode>

The structure of GDT SubledgerAccountGranularityCode 35800GC is depictedin FIG. 358GC. For the GDT SubledgerAccountGranularityCode 35800GC, theObject Class is SubledgerAccountGranularity 35804GC, theRepresentation/Association is Code 35808GC, the Type is CCT 35810GC, theType Name is Code 35812GC, and the Length is from one to three 35814GC.

The data type GDT SubledgerAccountGranularityCode 35800GC may use thefollowing code: 1 (i.e., the subledger granularityMaterial/LogisticsDivision establishes the criteria Company, Material,and Logis-ticsDivision to differentiate SubledgerAccounts). Theattributes of the CCT identifier are defined implicitly as follows:listID=“10068,” listAgencyID=“310,” and listVersionID—Version of thecode list.

(xxxxxxxxxxxxxxxx) WithholdingTax

A GDT WithholdingTax 35800GD is a tax that a paying party pays directlyinstead of the payee. For example, withholding taxes may be withheld bythe payer of remuneration and paid directly to the responsible taxauthority. They may be advance payments on taxes owed by the payee orsatisfy a tax liability of the payee. An example of GDT WithholdingTax35800GD is: <WithholdingTax> <CountryCode>DE</CountryCode> <TypeCodelistID=“20301”>002</TypeCode> <BaseAmountcurrencyCode=“EUR”>100</BaseAmount> <Rate>15</Rate> <AmountcurrencyCode=“EUR”>15</Amount> </WithholdingTax>

The structure of GDT WithholdingTax 35800GD is depicted in FIG. 358GD.For the GDT WithholdingTax 35800GD the Representation/Association isDetails 35804GD.

For the CountryCode 35810GD, the Category is Element (E) 35811GD, theObject Class is WithholdingTax 35812GD, the Property is Country 35813GD,the Representation/Association is Code 35814GD, the Type is GDT 35815GD,the Type Name is CountryCode 35816GD, and the Cardinality is zero or one35818GD.

For the TypeCode 35820GD, the Category is Element (E) 35821GD, theObject Class is WithholdingTax 35822GD, the Property is Type 35823GD,the Representation/Association is Code 35824GD, the Type is GDT 35825GD,the Type Name is TaxTypeCode 35826GD, and the Cardinality is zero or one35828GD.

For the BaseAmount 35830GD, the Category is Element (E) 35831GD, theObject Class is WithholdingTax 35832GD, the Representation/Associationis Amount 35834GD, the Type is GDT 35835GD, the Type Name is Amount35836GD, and the Cardinality is one 35838GD.

For the Percent 35840GD, the Category is Element (E) 35841GD, the ObjectClass is WithholdingTax 35842GD, the Representation/Association isPercent 35844GD, the Type is GDT 35845GD, the Type Name is Percent35846GD, and the Cardinality is zero or one 35848GD.

For the Amount 35850GD, the Category is Element (E) 35851GD, the ObjectClass is WithholdingTax 35852GD, the Representation/Association isAmount 35854GD, the Type is GDT 35855GD, the Type Name is Amount35856GD, and the Cardinality is zero or one 35858GD.

In some implementations, the CountryCode 35810GD and the TypeCode35820GD do not have to be specified on the item level of a businessdocument or message if they can be derived from the Withholding-Tax on asuper-ordinate level. There may be rules as to which withholding taxescan be shown as totals and which have to be itemized are determined on acounty-by-country basis in accordance with the applicable laws. In someimplementations, if the tax rate or tax amount is shown, the tax type(TypeCode 35820GD) must also be specified. The GDT WithholdingTax35800GD can be used to show the different withholding taxes in thepayment of remunerations or to initiate tax returns or tax payments by acompany to the relevant tax authorities.

(yyyyyyyyyyyyyyyy) TaxTypeCode

A GDT TaxTypeCode 35800GE is a coded representation of the type of atax. An example of GDT TaxTypeCode 35800GE is:

<TaxTypeCode listID=“20301” listAgencyID=“310”>001</TaxTypeCode>

The structure of GDT TaxTypeCode 35800GE is depicted in FIG. 358GE. Forthe GDT TaxTypeCode 35800GE, the Object Class is Tax 35801GE, theProperty is Type Code 35803GE, the Representation/Association is Code35804GE, the Type is CCT 35805GE, the Type Name is Code 35806GE, and theLength is three 35807GE. The remark 35809GE shows that the GDTTaxTypeCode 35800GE may be restricted.

For the ListID 35810GE, the Category is Attribute (A) 35811GE, theObject Class is CodeList 35812GE, the Property is Identification35813GE, the Representation/Association is Identifier 35814GE, the Typeis XSD 35815GE, the Type Name is Token 35816GE, the Length is from oneto forty 35817GE, and the Cardinality is one 35818GE.

For the ListAgencyID 35820GE, the Category is Attribute (A) 35821GE, theObject Class is CodeListAgency 35822GE, the Property is Identification35823GE, the Representation/Association is Identifier 35824GE, the Typeis XSD 35825GE, the Type Name is Token 35826GE, the Length is from oneto three 35827GE, and the Cardinality is zero or one 35828GE.

The data type GDT TaxTypeCode 35800GE may use the following codes forListID 20301 (DE): 001 (i.e., VAT levied in Germany), 002 (i.e.,withholding tax for construction work as per paragraph 48 of the GermanIncome Tax Act). The data type GDT TaxTypeCode 35800GE may use thefollowing codes for ListID 20302 (US): 001 (i.e., sales tax levied bystates in the USA), 002 (i.e., sales tax levied by local governments inUS states, such as, a county sales tax or a city sales tax). For SAPcode lists for the TaxTypeCode, specify the listAgencyID=“310”(according to DE 3055).

(zzzzzzzzzzzzzzzz) TransshipmentMethodCode

A GDT TransshipmentMethodCode 35800GF is a coded representation of thelogistics procedure for goods transfer. For example, in this context,“goods transfer” may cover goods receipt, intermediate storage, andmerchandise distribution. An example of GDT TransshipmentMethodCode35800GF is:

<TransshipmentMethodCode>1</TransshipmentMethodCode>

The structure of GDT TransshipmentMethodCode 35800GF is depicted in FIG.358GF. For the GDT TransshipmentMethodCode 35800GF, the Object Class isTransshipment Method 35804GF, the Representation/Association is Code35808GF, the Type is CCT 35810GF, the Type Name is Code 35812GF, and theLength is from one to two 35814GF.

The data type GDT TransshipmentMethodCode 35800GF may use the followingcodes: 1 (i.e., The goods are put away and transferred later to anothercustomer or warehouse.), 2 (i.e., The goods arrive in the distributioncenter or warehouse in the recipient-related (store or customer)combination defined in logistics planning. From the point of goodsreceipt until they reach the final warehouse or customer, the goods aremoved through one or more warehouses without being put away), 3 (i.e.,The goods arrive in the distribution center or warehouse in therecipient-related (store or customer) combination defined in logisticsplanning. From the point of goods receipt until they reach the finalwarehouse or customer, the goods are moved through one or morewarehouses without being put away. However, the goods recipient here isnot the one originally specified in logistics planning. The decision forthis unplanned recipient change could be based, for example, on one ormore backordered orders.), 4 (i.e., Goods are sent without put-awaytaking place. The quantity defined in logistics planning is first movedto a storage type used for cross-docking, where it is split up intorecipient-specific amounts and then sent.).

For example, if intermediate storage of goods in a storage location ordistribution center is very costly or if goods have a very short shelflife, put-away is not performed. Instead, the goods are prepared fordistribution immediately and then sent to the final point of sale.

(aaaaaaaaaaaaaaaaa) TaxRateTypeCode

A GDT TaxRateTypeCode 35800GG is a code that represents the type of taxrate as defined by the law for the classification of tax rates. Anexample of GDT TaxRateTypeCode 35800GG is: <TaxRateTypeCode listID=20201listAgencyID=310> 001</TaxRateTypeCode>

The structure of GDT TaxRateTypeCode 35800GG is depicted in FIG. 358GG.For the GDT TaxRateTypeCode 35800GG, the Object Class is Tax Rate35801GG, the Property is Type 35803GG, the Representation/Association isCode 35804GG, the Type is CCT 35805GG, the Type Name is Code 35806GG,and the Length is five 35807GG. The remark 35809GG shows that the GDTTaxRateTypeCode 35800GG may be restricted.

For the ListID 35810GG, the Category is Attribute (A) 35811GG, theObject Class is CodeList 35812GG, the Property is Identification35813GG, the Representation/Association is Identifier 35814GG, the Typeis XSD 35815GG, the Type Name is Token 35816GG, the Length is from oneto forty 35817GG, and the Cardinality is one 35818GG.

For the ListAgencyID 35820GG, the Category is Attribute (A) 35821GG, theObject Class is CodeListAgency 35822GG, the Property is Identification35823GG, the Representation/Association is Identifier 35824GG, the Typeis XSD 35825GG, the Type Name is Token 35826GG, the Length is from oneto three 35817GG, and the Cardinality is zero or one 35828GG.

The data type GDT TaxRateTypeCode 35800GG may use the following codesfor ListID 20201 (DE): 001 (i.e., full sales tax rate), 002 (i.e.,reduced sales tax rate), 003 (i.e., tax-exempt). The data type GDTTaxRateTypeCode 35800GG may use the following codes for ListID 20202(US): 001 (i.e., full sales tax rate), 002 (i.e., tax-exempt).

For certain taxes, such as VAT, there are one or more tax rates withinits spatial and temporal scope of application. A concrete tax rate isderived from the TaxRateTypeCode 35800GG in connection with a scope ofapplication. The TaxRateTypeCode 35800GG code list may be determined bynational tax legislation. The typing of tax rates makes it possible toformulate the texts of laws and regulations pertaining to taxesindependently of the concrete tax rates, which can change over time. Inother words: If a tax rate is raised or lowered at some point in time,the corresponding TaxRateTypeCode 35800GG does not change. If additionalnew tax rates are introduced, new TaxRateTypeCodes 35800GG may also beintroduced.

(bbbbbbbbbbbbbbbbb) TripServiceProviderCode

A GDT TripServiceProviderCode 35800GH is a coded representation of theprovider of a service associated with a trip. An example of GDTTripServiceProviderCode 35800GH is:

<TripServiceProviderCode>MC</TripServiceProviderCode>

The structure of GDT TripServiceProviderCode 35800GH is depicted in FIG.358GH. For the GDT TripServiceProviderCode 35800GH, the Object Class isTripServiceProvider 35804GH, the Representation/Association is Code35808GH, the Type is CCT 35810GH, the Type Name is Code 35812GH, and theLength is from one to two 35814GH. The remark 35818GH shows that the GDTTripServiceProviderCode 35800GH may be restricted.

The data type GDT TripServiceProviderCode 35800GH may use the followingcodes: 1 (i.e., car rental industry: Alamo), 2 (i.e., hotel industry:Marriot).

(ccccccccccccccccc) Text

A GDT Text 35800GI is a character string with an optional languagespecification. An example of GDT Text 35800GI is:   <TextlanguageCode=“DE“>Text is a character string with optional languagespecification.</Text>

The structure of GDT Text 35800GI is depicted in FIG. 358GI. For the GDTText 35800GI, the Category is complexType 35801GI, the Object Class isText 35802GI, the Representation/Association is Content 35804GI, theType is XSD 35805GI, the Type Name is String 35806GI, and the Length isunlimited 35807GI.

For the language-Code 35810GI, the Category is Attribute (A) 35811GI,the Object Class is Text 35812GI, the Property is Language 35813GI, theRepresentation/Association is Code 35814GI, the Type is XSD 35815GI, theType Name is language 35816GI, the Length id from two to nine 35817GI,and the Cardinality is zero or one 35818GI. The remark 35819GI showsthat the language-Code 35810GI may be optional.

Text 35800GI comprises the following attributes: languageCode 35810GI.For example, if the attachment is a document or text, this can be usedto show the language of the attachment in accordance with IETF RFC 1766or IETF RFC 3066.

(ddddddddddddddddd) UUID

A GDT UUID 35800GJ is a globally unique identifier for an object. Forexample, “globally unique” may mean that no two objects have the sameidentifier in all probability. An example of GDT UUID 35800GJ is:

<ProductUUID>f81d4fae-7dec-1d0-a765-00a0c91e6bf6</ProductUUID>

The structure of GDT UUID 35800GJ is depicted in FIG. 358GJ. For the GDTUUID 35800GJ, the Property Qualifier is Universally Unique 35804GJ, theProperty is Identification 35806GJ, the Representation/Association isIdentifier 35808GJ, the Type is CCT 35810GJ, the Type Name is Identifier35812GJ, and the Length is thirty-six 35814GJ. The remark 35818GJ showsthat the GDT UUID 35800GJ may be restricted.

In some implementations, the UUID 35800GJ is a number in hexadecimalnotation, which is “mathematically guaranteed” unique due to itsgeneration algorithm. The UUID 35800GJ may be represented according tothe following schema: groups of 8, 4, 4, 4, and 12 characters (0-9, a-f)with hyphens between the groups:

dddddddd-dddd-dddd-dddd-dddddddddddd.

The representation may, for example, correspond to ISO 11578:1996 andIETF RFC 4122.

(eeeeeeeeeeeeeeeee) VariableInterestRate

A GDT VariableInterestRate 35800GK is an interest rate that changes.Unlike a fixed interest rate, a variable interest rate may be based on areference interest rate that continually changes over time. For example,variable interest rates may be agreed for loans. Variable may mean thatthe concrete interest rate is determined depending on a referenceinterest rate curve. Upper and lower levels of interest rates (caps andfloors) may also be agreed. An example of GDT VariableInterestRate35800GK is: <VariableInterestRate> <ReferenceInterestCurveCodelistID=”221” listAgencyID=”17”> LIBO</ ReferenceInterestCurveCode><AdjustmentRecurrence> <Period> <StartDate>2005-01-01</StartDate><EndDate>2010-01-01</EndDate> </Period> <Duration>P1M</Duration></AdjustmentRecurrence> <MarginPercent>0.1</ MarginPercent><FluctuationMarginPercent>0.2</ FluctuationMarginPercent><CapPercent>8.75</CapPercent> <FloorPercent>6.35</FloorPercent></VariableInterestRate>

The structure of GDT VariableInterestRate 35800GK is depicted in FIG.358GK. For the GDT VariableInterestRate 35800GK, the Object Class isVariable Interest Rate 35801GK, and the Property is Details 35803GK.

For the ReferenceInterestCurveCode 35810GK, the Category is Element (E)35811GK, the Object Class is Variable Interest Rate 35812GK, theProperty is Reference Interest Curve 35813GK, theRepresentation/Association is Code 35814GK, the Type is GDT 35815GK, theType Name is ReferenceInterestCurveCode 35816GK, and the Cardinality isone 35818GK.

For the AdjustmentRecurrence 35820GK, the Category is Element (E)35821GK, the Object Class is Variable Interest Rate 35822GK, theProperty is Adjustment 35823GK, the Representation/Association isRecurrence 35824GK, the Type is GDT 35825GK, the Type Name isPeriodDurationDayRecurrence 35826GK, and the Cardinality is zero or one35828GK.

For the BeforeAdjustmentIDaysValue 35830GK, the Category is Element (E)35831GK, the Object Class is Variable Interest Rate 35832GK, theProperty is Before Adjustment 35833GK, the Representation/AssociationQualifier is Days 35837GK, the Representation/Association is Value35834GK, the Type is GDT 35835GK, the Type Name is IntegerValue 35836GK,and the Cardinality is zero or one 35838GK.

For the InitialRatePercent 35840GK, the Category is Element (E) 35841GK,the Object Class is Variable Interest Rate 35842GK, the Property isInitial Rate 35843GK, the Representation/Association is Percent 35844GK,the Type is GDT 35845GK, the Type Name is Percent 35846GK, and theCardinality is zero or one 35848GK.

For the MarginPercent 35850GK, the Category is Element (E) 35851GK, theObject Class is Variable Interest Rate 35852GK, the Property is Margin35853GK, the Representation/Association is Percent 35854GK, the Type isGDT 35855GK, the Type Name is Percent 35856GK, and the Cardinality iszero or one 35858GK.

For the FluctuationMarginPercent 35860GK, the Category is Element (E)35861GK, the Object Class is Variable Interest Rate 35862GK, theProperty is Fluctuation Margin 35863GK, the Representation/Associationis Percent 35864GK, the Type is GDT 35865GK, the Type Name is Percent35866GK, and the Cardinality is one 35868GK.

For the CapPercent 35870GK, the Category is Element (E) 35871GK, theObject Class is Variable Interest Rate 35872GK, the Property is Cap35873GK, the Representation/Association is Percent 35874GK, the Type isGDT 35875GK, the Type Name is Percent 35876GK, and the Cardinality iszero or one 35878GK.

For the FloorPercent 35880GK, the Category is Element (E) 35881GK, theObject Class is Variable Interest Rate 35882GK, the Property is Floor35883GK, the Representation/Association is Percent 35884GK, the Type isGDT 35885GK, the Type Name is Percent 35886GK, and the Cardinality iszero or one 35888GK.

The ReferenceInterestCurveCode 35810GK is a coded representation of thereference interest rate. The AdjustmentRecurrence 35820GK defines therecurring date for adjusting a variable interest rate. TheBeforeAdjustmentDaysValue 35830GK defines how many days before thedetermination you have to ascertain the new interest rate. TheInitialRatePercent 35840GK describes the initial interest rate. TheMarginPercent 35850GK describes the reduction or increase compared tothe market interest rate as a percentage. The FluctuationMarginPercent35860GK the FluctuationMargin determines the maximum amount by which therate can differ from the current rate as a percentage. The CapPercent35870GK represents the upper level of interest rate that is permitted.The FloorPercent 35880GK represents the lower level of interest ratethat is permitted. Loans with a variable interest rate may use areference interest rate (LIBOR, for example) to determine their rate ofinterest. They may be adjusted periodically within the upper and lowerlevels of interest rate. The development of the underlying referenceinterest rate may be a factor when making this adjustment.

(ffffffffffffffffff) VIPReasonCode

A GDT VIPReasonCode 35800GL is an explanation of the VIP (Very ImportantPerson) characteristics of a person. The explanation is represented by acode. An example of GDT VIPReasonCode 35800GL is:

<VIPReasonCode>1</VIPReasonCode>

The structure of GDT VIPReasonCode 35800GL is depicted in FIG. 358GL.For the GDT VIPReasonCode 35800GL, the Property is VIP Reason 35803GL,the Representation/Association is Code 35804GL, the Type is CCT 35805GL,the Type Name is Code 35806GL, and the Length is one 35807GL. The remark35809GL shows that the GDT VIPReasonCode 35800GL may be restricted.

For the ListID 35810GL, the Category is Attribute (A) 35811GL, theObject Class is CodeList 35812GL, the Property is Identification35813GL, the Representation/Association is Identifier 35814GL, the Typeis XSD 35815GL, the Type Name is Token 35816GL, and the Cardinality iszero or one 35818GL.

For the ListAgencyID 35820GL, the Category is Attribute (A) 35821GL, theObject Class is CodeListAgency 35822GL, the Property is Identification35823GL, the Representation/Association is Identifier 35824GL, the Typeis XSD 35825GL, the Type Name is Token 35826GL, and the Cardinality iszero or one 35828GL.

For the ListVersionID 35830GL, the Category is Attribute (A) 35831GL,the Object Class is CodeList 35832GL, the Property is Version 35833GL,the Representation/Association is Identifier 35834GL, the Type is XSD35835GL, the Type Name is Token 35836GL, and the Cardinality is zero orone 35838GL.

For the ListAgency-SchemeID 35840GL, the Category is Attribute (A)35841GL, the Object Class is CodeListAgency 35842GL, the Property isScheme 35843GL, the Representation/Association is Identifier 35844GL,the Type is XSD 35845GL, the Type Name is Token 35846GL, and theCardinality is zero or one 35848GL.

For the ListAgency-SchemeAgencyID 35850GL, the Category is Attribute (A)35851GL, the Object Class is CodeListAgency 35852GL, the Property isSchemeAgency 35853GL, the Representation/Association is Identifier35854GL, the Type is XSD 35855GL, the Type Name is Token 35856GL, andthe Cardinality is zero or one 35858GL.

The data type GDT VIPReasonCode 35800GL may use the following codes:managing director (i.e., this person is indicated as a VIP because he orshe is the managing director), company partner (i.e., this person isindicated as a VIP because he or she is a partner in the company).

(gggggggggggggggggg) WithholdingTaxEventTypeCode

A GDT WithholdingTaxEventTypeCode 35800GM is a coded representation ofthe type of taxable income which is connected with the withholding taxin the payment of remunerations. For example, taxable income may referto an event in which a combination of properties is the basis for a taxliability, tax reduction or tax exemption of a particular type andamount according to the tax laws of a particular country. An example ofGDT WithholdingTaxEventTypeCode 35800GM is:

<WithholdingTaxEventTypeCodelistID=21001>100</WithholdingTaxEventTypeCode>

The structure of GDT WithholdingTaxEventTypeCode 35800GM is depicted inFIG. 358GM. For the GDT WithholdingTaxEventTypeCode 35800GM, the ObjectClass is Withholding Tax Event 35801GM, the Property is Type 35803GM,the Representation/Association is Code 35804GM, the Type is CCT 35805GM,the Type Name is Code 35806GM, and the Length is from one to three35807GM. The remark 35809GM shows that the GDTWithholdingTaxEventTypeCode 35800GM may be restricted.

For the ListID 35810GM, the Category is Attribute (A) 35811GM, theObject Class is CodeList 35812GM, the Property is Identification35813GM, the Representation/Association is Identifier 35814GM, the Typeis XSD 35815GM, the Type Name is Token 35816GM, the Length is from oneto forty 35817GM, and the Cardinality is one 35818GM.

The data type GDT WithholdingTaxEventTypeCode 35800GM may use thefollowing codes: 1 (i.e., withholding tax-liable construction work asper paragraph 48 of the German Income Tax Act), 2 (i.e., constructionwork with certificate of exemption as per paragraph 48 of the GermanIncome Tax Act).

Taxable income properties in the sense of tax law is the taxable unit(legal entity liable to pay the tax) and the taxable object (object,activity or status on which a tax is levied). The type and number ofproperties to be considered for particular business transactions aredetermined by the tax laws of a country. These laws or their enforcementprovisions generally do not prescribe specific codes. The codes aretherefore set by the respective software manufacturers.WithholdingTaxTypeCode is assigned multiple fixed country-specific codelists; these are distinguished at runtime. TheWithholdingTaxEventTypeCode 35800GM can be used in the calculation oftaxes for the determination of type and rate of the respective tax.Furthermore, the tax registry decides on the basis of theWithholdingTaxEventTypeCodes 35800GM how and when taxes are to bereported and paid to the tax authorities.

(hhhhhhhhhhhhhhhhh) StartendCode

A GDT StartendCode 35800GN is the coded representation for the start orthe end of something. In logistics, for example, “something” typicallystands for a process segment. An example (instance) of the GDTStartendCode 35800GN is:

<StartEndCode>1</StartEndCode>

The structure of GDT StartendCode 35800GN is depicted in FIG. 358GN. Forthe GDT StartendCode 35800GN, the Object Class term is Start End35802GN, the Representation/Association term is Code 35804GN, the Typeterm is CCT 35806GN, the Type Name term is Code 35808GN, and the Lengthis either one or two 35810GN. The GDT StartendCode 35800GN may berestricted 35812GN.

The GDT StartendCode 35800GN may be used, for example, in the bill ofoperations to indicate the start and the end of a processing path.

(iiiiiiiiiiiiiiiii) PersonnelEventTypeCode

A GDT PersonnelEventTypeCode 35800GO is a coded representation of thetype of a personnel event. A personnel event is an event in anemployee's professional or private life that needs to be documented forthe company. The GDT PersonnelEventType 35800GO is the classification ofpersonnel events according to the type of change to the workrelationship, the work agreement, or the employee-related data. Anexample of GDT PersonnelEventTypeCode 35800GO is:

<PersonnelEventTypeCodelistAgencyID=‘310’listVersionID=‘1.0’>1</PersonnelEventTypeCode>

The structure of GDT PersonnelEventTypeCode 35800GO is depicted in FIG.358GO. The GDT PersonnelEventTypeCode 35800GO includes attributeslistAgencyID 35814GO, listVersionID 35830GO, listAgencySchemeID 35846GO,and listAgencySchemeAgencyID 35862GO. For the GDT PersonnelEventTypeCode35800GO, the Object Class term is Personnel Administration 35802GO, theRepresentation/Association term is Code 35804GO, the Type term is CCT35806GO, the Type Name term is Code 35808GO, and the Length is from oneto four 35810GO. The PersonnelEventTypeCode 35800GO may be restricted35812GO.

For the listAgencyID 35814GO, the Category is Attribute 35816GO, theObject Class term is CodeListAgency 35818GO, the Property term isIdentification 35820GO, the Representation/Association term isIdentifier 35822GO, the Type term is XSD 35824GO, and the Type Name termis token 35826GO. The Cardinality between the listAgencyID 35830GO andthe GDT PersonnelEventTypeCode 35800GO is either zero or one 35832GO.

For the listVersionID 35830GO, the Category is Attribute 35832GO, theObject Class term is CodeList 35834GO, the Property term is Version35836GO, the Representation/Association term is Identifier 35838GO, theType term is XSD 35840GO, and the Type Name term is token 35842GO. Thecardinality between the listVersionID 35830GO and the GDTPersonnelEventTypeCode 35800GO is either zero or one 35844GO.

For the listAgencySchemeID 35846GO, the Category is Attribute 35848GO,the Object Class term is CodeListAgency 35850GO, the Property term isScheme 35852GO, the Representation/Association term is Identifier35854GO, the Type term is XSD 35856GO, and the Type Name term is token35858GO. The cardinality between the listAgencySchemeID 35846GO and theGDT PersonnelEventTypeCode 35800GO is either zero or one 35860GO.

For the listAgencySchemeAgencyID 35862GO, the Category is Attribute35864GO, the Object Class term is CodeListAgency 35866GO, the Propertyterm is SchemeAgency 35868GO, the Representation/Association term isIdentifier 35870GO, the Type term is XSD 35872GO, and the Type Name termis token 35874GO. The cardinality between the listAgencySchemeAgencyID35862GO and the GDT PowerOfAttorneyTypeCode 35800GO is either zero orone 35876GO.

In some implementations, several country-specific code lists may bepredefined to the GDT PersonnelEventTypeCode 35800GO. If a customermakes changes to the predefined code lists, for example, the values ofthe attributes may be changed as follows:

listAgencyID—ID of the Customer (ID from DE 3055 if listed there)

listVersionID—Assigned and managed by the Customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of the organization (taken from DE 3055)that manages the scheme of the listAgencySchemeID

A customer can use the GDT PersonnelEventTypeCode 35800GO to distinguishbetween different event types in personnel administration. In someimplementations, the GDT PersonnelEventTypeCode 35800GO may include acode list with international event types. Additionally, customers andcountries can modify the list.

Some examples of the possible semantics of the codes are:

Hiring—This type contains the information that the event is an “EmployeeHiring”.

Resignation—This type contains the information that the event is an“Employee Resignation”.

Maternity Protection—This type contains the information that the eventis an “Employee Maternity Protection”.

(jjjjjjjjjjjjjjjjjjj) PersonRaceEthnicityCode

A GDT PersonRaceEthnicityCode 35800GP is a code indicating the racial orethnic background of a person. For example, the code may be definedaccording to the U.S. Office of Management and Budget and U.S. Bureau ofConsensus. An example (instance) of the GDT PersonRaceEthnicityCode35800GP is:

<PersonRaceEthnicityCode listID=“1109” listAgencyID=“116”listVersionID=“X12.3”>C</PersonRaceEthnicityCode>

In the United States, this is the code identifying the racial backgroundof the person as Caucasian, according to ANSI X12.3.

The structure of GDT PersonRaceEthnicityCode 35800GP is depicted in FIG.358GP. The GDT PersonRaceEthnicityCode 35800GP includes attributeslistID 35814IF, listAgencyID 35830IF, and listVersionID 35846IF. For theGDT PersonRaceEthnicityCode 35800GP, the Object Class term is Person35802GP, the Property term is Race Ethnicity 35804GP, theRepresentation/Association term is Code 35806GP, the Type term is CCT35808GP, the Type Name term is Code 35810GP, and the Length is eitherone or two 35812GP. The PersonRaceEthnicityCode 35800GP may berestricted 35814GP.

For the listID 35816GP, the Category is Attribute 35818GP, the ObjectClass term is CodeList 35820GP, the Property term is Identification35822GP, the Representation/Association term is Identifier 35822GP, theType term is XSD 35826GP, and the Type Name term is token 35828GP. Thecardinality between the listID 35816GP and the GDT ProductUsageCode35800GP is either zero or one 35830GP.

For the listAgencyID 35832GP, the Category is Attribute 35834GP, theObject Class term is CodeListAgency 35836GP, the Property term isIdentification 35838GP, the Representation/Association term isIdentifier 35840GP, the Type term is XSD 35842GP, and the Type Name termis token 35844GP. The Cardinality between the listAgencyID 35832GP andthe GDT ProductUsageCode 35800GP is either zero or one 35846GP.

For the listVersionID 35848GP, the Category is Attribute 35850GP, theObject Class term is CodeList 35852GP, the Property term is Version35854GP, the Representation/Association term is Identifier 35856GP, theType term is XSD 35858GP, and the Type Name term is token 35860GP. Thecardinality between the listVersionID 35848GP and the GDTProductUsageCode 35800GP is either zero or one 35862GP.

In some implementations, several fixed, country-specific code lists,which are different at runtime, may be assigned to the code.

An employer may use the GDT ProductUsageCode 35800GP to ensure that anemployee is not discriminated against on the basis of his or her racialor ethnic background. In some location, such as the United States, thereis a legal regulation stipulating that the racial background informationmay be entered separately from the ethnic background information. Forexample, the GDT PersonRaceEthnicityCode 35800GP for the country USaccording to ANSI X12.3-1109 may have attributes as follows:

listID=“1109” (Race or Ethnicity Code)

listAgencyID=“116” (US ANSI X12)

listVersionID=“X12.3”

The GDT PersonRaceEthnicityCode 35800GP is displayed in accordance withthe ANSI X12.3-1109. The following table includes some of the possiblecode in the ANSI X12.3-1109 code list. Code Name Description 7 NotProvided The code is not provided. 8 Not Applicable The code is notapplicable. A Asian or Pacific Islander The person is Asian or PacificIslander. B Black The person is Black. C Caucasian The person isCaucasian. D Subcontinent Asian American The person is SubcontinentAsian American. E Other Race or Ethnicity The person is of another raceor ethnicity. F Asian Pacific American The person is Asian PacificAmerican. G Native American The person is native American. H HispanicThe person is Hispanic. I American Indian or Alaskan Native The personis American Indian or Alaskan Native. J Native Hawaiian The person isnative Hawaiian. N Black (Non-Hispanic) The person is Black(Non-Hispanic). O White (Non-Hispanic) The person is White(Non-Hispanic). P Pacific Islander The person is Pacific Islander. QBlack or African American The person is Black or African American. RHispanic or Latino The person is Hispanic or Latino. S White The personis White. T American Indian or Alaska Native The person is AmericanIndian or Alaska Native. U Asian The person is Asian. V Native Hawaiianor Other Pacific The person is native Hawaiian or other Islander PacificIslander. W Not Hispanic or Latino The person is not Hispanic or Latino.Z Mutually Defined The code is mutually defined.

As another example, the GDT PersonRaceEthnicityCode 35800GPPersonRaceEthnicityCode according to GB/T 3304-1991 may have attributesas follows:

listID=“GB/T 3304” (Race or Ethnicity Code)

listAgencyID=“CN”

listVersionID=“1991”

listAgencySchemeID=ISO 3166-1.

listAgencySchemeAgencyID=“5” (ISO)

(kkkkkkkkkkkkkkkkk) PriorityValue

A GDT PriorityValue 35800GQ is the value-based specification of apriority. An example (instance) of the GDT PriorityValue 35800GQ is:

<PriorityValue>1</PriorityValue>

The structure of GDT PriorityValue 35800GQ is depicted in FIG. 358GQ.For the GDT PriorityValue 35800GQ, the Property term is Priority35802GQ, the Representation/Association term is Code 35804GQ, the Typeterm is CCT 35806GQ, the Type Name term is Numeric 35808GQ, and theLength is maximum thirteen digits with two places after the decimalpoint 35810GQ. The PriorityValue 35800GQ may be restricted 35812GQ.

In some variations, the GDT PriorityValue 35800GQ may only be used ifvariable priorities have to be used. For example, in the businessobject, integrated Production Process Model, the GDT PriorityValue35800GQ can be used to define the priority with which a source ofsupply, created based on an integrated Production Process Model, is tobe taken into account in procurement planning.

(lllllllllllllllll) ProcessBranchingTypeCode

A GDT ProcessBranchingTypeCode 35800GR is the coded representation ofthe type of a process branching. A branching is a way of structuring aprocess description that splits a process into several process paths. Inaddition to a common starting point, the branched processing paths alsohave a common end point where the different paths join again. An example(instance) of the GDT ProcessBranchingTypeCode 35800GR is:

<ProcessBranchingTypeCode>1</ProcessBranchingTypeCode>

The structure of GDT ProcessBranchingTypeCode 35800GR is depicted inFIG. 358GR. For the GDT ProcessBranchingTypeCode 35800GR, the ObjectClass term is Process Branching 35802GR, the Property term is Type35804GR, the Representation/Association term is Code 35806GR, the Typeterm is CCT 35808GR, the Type Name term is Code 35810GR, and the Lengthis from one to two 35812GR. The GDT ProcessBranchingTypeCode 35800GR maybe restricted 35814GR.

In some implementations, one fixed code list may be predefined to theGDT ProcessBranchingTypeCode 35800GR. For example, the GDTProcessBranchingTypeCode 35800GR may include attributes as follows:

listID is “10131”

listAgencyID is “310”

listVersionID may be a version of the relevant code list.

In some examples, the GDT ProcessBranchingTypeCode 35800GR can be usedto control how the quantity to be processed flows through the processingpaths of the branching. In a production process, the processed quantityis a production lot and in an authorization process, it is the quantityof the requests to be authorized. An exemplary code list is depicted asfollows: Code Name Description 1 Alternative Indicates a branching inprocessing paths at which the processing quantity can be split. 2Exclusive Indicates a branching in processing paths whereby Alternativethe complete process may be completed on one path only. 3 ParallelIndicates a branching in processing paths whereby the complete processcan be completed on all available paths.

(mmmmmmmmmmmmmmmmm) RegistrantRoleCode

A GDT RegistrantRoleCode 35800GS is the coded representation of the roleof a person, device, or system that is registered for something. Anexample (instance) of the GDT RegistrantRoleCode 35800GS is:

<RegistrantRoleCode>1</RegistrantRoleCode>

The structure of GDT RegistrantRoleCode 35800GS is depicted in FIG.358GS. For the GDT RegistrantRoleCode 35800GS, the Object Class term isRegistrant 35802GS, the Property term is Role 35804GS, theRepresentation/Association term is Code 35806GS, the Type term is CCT35808GS, the Type Name term is Code 35810GS, and the Length is from oneto two 35812GS. The GDT RegistrantRoleCode 35800GS may be restricted35814GS.

In some implementations, one fixed code list may be predefined to theGDT RegistrantRoleCode 35800GS. For example, the GDT RegistrantRoleCode35800GS may include attributes as follows:

listID is 10156

listAgencyID is 310

listVersionID may be a version of the relevant code list.

As an example, the GDT RegistrantRoleCode 35800GS may define a code listthat the code 1 represents that a registrant is responsible, and thecode 2 represents that a registrant is interested.

(nnnnnnnnnnnnnnnnn) ReportingPointID

A GDT ReportingPointID 35800GT is a unique identifier of a reportingpoint in a process description. A reporting point is a point in aprocess description at which data is recorded that documents theprogress of production. An example (instance) of the GDTReportingPointID 35800GT is:

<ReportingPointID>RP4711</ReportingPointID>

The structure of GDT ReportingPointID 35800GT is depicted in FIG. 358GT.For the GDT ReportingPointID 35800GT, the Object Class term is ReportingPoint 35802GT, the Property term is Identification 35804GT, theRepresentation/Association term is Identifier 35806GT, the Type term isCCT 35808GT, the Type Name term is Identifier 35810GT, and the Length isfrom one to forty 35812GT. The GDT ReportingPointID 35800GT may berestricted 35814GT. In some implementations, the GDT ReportingPointID35800GT may be unique in the usage context.

(ooooooooooooooooo) SalesCycleCode

A GDT SalesCycleCode 35800GU is the coded representation of the salescycle. The sales cycle of a product or a service starts with therecognition of an opportunity, that is with a potential salesopportunity, and ends with a customer's order or cancellation. The salescycle for an opportunity is made up of various phases, for example,project identification, qualification, quote, and so on. The duration ofa sales cycle is determined by the start and expected end date of anopportunity. An example (instance) of the GDT SalesCycleCode 35800GU is:

<SalesCycleCode listAgencyID=310>2</SalesCycleCode>

The structure of GDT SalesCycleCode 35800GU is depicted in FIG. 358GU.The GDT SalesCycleCode 35800GU includes attributes listID 35812GU,listAgencyID 35828GU, listVersionID 35846GU, listAgencySchemeID 35864GU,and listAgencySchemeAgencyID 35880GU. For the GDT SalesCycleCode35800GU, the Object Class term is Sales Cycle 35802GU, theRepresentation/Association term is Code 35804GU, the Type term is CCT35806GU, the Type Name term is Code 35808GU, and the Length is from oneto five 35810GU.

For the listID 35812GU, the Category is Attribute 35814GU, the ObjectClass term is CodeList 35816GU, the Property term is Identification35817GU, the Representation/Association term is Identifier 35818GU, theType term is XSD 35820GU, and the Type Name term is token 35822GU. Thecardinality between the listID 35812GU and the GDT SalesCycleCode35800GU is either zero or one 35824GU. The listID 35812GU may be atleast document 35826GU.

For the listAgencyID 35828GU, the Category is Attribute 35830GU, theObject Class term is CodeListAgency 35832GU, the Property term isIdentification 35834GU, the Representation/Association term isIdentifier 35836GU, the Type term is XSD 35838GU, and the Type Name termis token 35840GU. The Cardinality between the listAgencyID 35828GU andthe GDT SalesCycleCode 35800GU is either zero or one 35842GU. ThelistAgencyID 35812GU may be at least document 35844GU.

For the listVersionID 35846GU, the Category is Attribute 35848GU, theObject Class term is CodeList 35850GU, the Property term is Version35852GU, the Representation/Association term is Identifier 35854GU, theType term is XSD 35856GU, and the Type Name term is token 35858GU. Thecardinality between the listVersionID 35846GU and the GDT SalesCycleCode35800GU is either zero or one 35860GU. The listVersionID 35812GU may beat least document 35862GU.

For the listAgencySchemeID 35864GU, the Category is Attribute 35866GU,the Object Class term is CodeListAgency 35868GU, the Property term isScheme 35870GU, the Representation/Association term is Identifier35872GU, the Type term is XSD 35874GU, and the Type Name term is token35876GU. The cardinality between the listAgencySchemeID 35864GU and theGDT SalesCycleCode 35800GU is either zero or one 35878GU.

For the listAgencySchemeAgencyID 35880GU, the Category is Attribute35882GU, the Object Class term is CodeListAgency 35884GU, the Propertyterm is SchemeAgency 35886GU, the Representation/Association term isIdentifier 35888GU, the Type term is XSD 35890GU, and the Type Name termis token 35892GU. The cardinality between the listAgencySchemeAgencyID35880GU and the GDT SalesCycleCode 35800GU is either zero or one35894GU.

In some implementations, several codes lists may be defined for the GDTSalesCycleCode 35800GU. In some implementations, a default code list maybe predefined in the GDT SalesCycleCode 35800GU. Additionally, in someimplementations, customers can add additional code lists. For example,attributes may be allocated as follows:

listID may be an ID of the respective code list.

listAgencyID is 310

listVersionID may be a version of the respective code list.

For example, a set of possible characteristic values may be selectedthat a code of 1 represents a customer care sales cycle and a code of 2represents a new business sales cycle. The customer sales cycle maydescribe the phases required for existing customers, in order that anopportunity can be completed successfully. The new business sales cyclemay describe the phases required for new customers, in order that anopportunity be completed successfully. In some implementations, the newbusiness sales cycle may be considered to be more complex than thecustomer sales cycle. For example, important contact persons anddecision makers within the new business may need to be identified.

As an example, the attributes can be used as follows:

listID—ID of the respective code list. Provided and administered by theresponsible organization of the code list, that is not included in DE3055. The exact ID has to be obtained by the GDT Owner at theresponsible organization. If a unique ID is not available, the name ofthe respective code list or code type has to be entered that can be usedin the corresponding standard, specification or scheme of theresponsible organization.

listAgencyID—ID of the administering organization of the code list. Thisidentifier is assigned by the organization from DE 3055, (for example,DUNS number or EAN number of an enterprise). The relevant ID has to beobtained by the GDT Owner of the responsible organization.

listVersionID—Version of the respective code list. Provided andadministered by the organization that is listed in the listAgencyID. Therelevant version ID may be obtained by the GDT Owner of the responsibleorganization. If a version has not been provided for the code list, theversion of the standard, scheme or procedure should be used.

listAgencySchemeID—The identification of the scheme, according to which,the organization that is listed in the listAgencyID has been identified.This is an example of a specific identification scheme of partners,enterprises, corporations, members, and so on, (for example, DUNS+4), ofthe administering organization listed in the “listAgencySchemeAgencyID”.(e.g., EAN, DUNS, SWIFT, and so on).

listAgencySchemeAgencyID—The identification of the administeringorganization, (for example, DUNS, EAN, SWIFT), that is responsible forthe identification of the organization that is listed in thelistAgencyID. This has to be included in DE 3055.

As an example, the GDT SalesCycleCode 35800GU is mainly used formodeling business objects. It defines its own view of a sales process,and, for this reason, may not be used in an electronic message exchangewith external parties.

In some implementations, the GDT SalesCycleCode 35800GU is mainly usedin Presales in order to assign an opportunity to the sales cycle. Theindividual phases of the cycle are determined depending on the salescycle.

(ppppppppppppppppp) SalesCyclePhaseCode

A GDT SalesCyclePhaseCode 35800GV is the coded representation of a salescycle phase. A sales cycle phase is a section of the sales cycle inwhich specific activities are carried out, for example, pre-selection,initial contact, presentation, drawing up a quotation. The GDTSalesCyclePhaseCode 35800GV is:

<SalesCyclePhaseCode listAgencyID=310>1</SalesCyclePhaseCode>

The structure of GDT SalesCyclePhaseCode 35800GV is depicted in FIG.358GV. The GDT SalesCyclePhaseCode 35800GV includes attributes listID35814GV, listAgencyID 35832GV, listVersionID 35850GV, listAgencySchemeID35868GV, and listAgencySchemeAgencyID 35886GV. For the GDTSalesCyclePhaseCode 35800GV, the Object Class term is Sales Cycle35802GV, the Property term is Phase 35804GT, theRepresentation/Association term is Code 35806GV, the Type term is CCT35808GV, the Type Name term is Code 35810GV, and the Length is from oneto three 35812GV.

For the listID 35814GV, the Category is Attribute 35816GV, the ObjectClass term is CodeList 35818GV, the Property term is Identification35820GV, the Representation/Association term is Identifier 35822GV, theType term is XSD 35824GV, and the Type Name term is token 35826GV. Thecardinality between the listID 35814GV and the GDT SalesCyclePhaseCode35800GV is either zero or one 35828GV. The listID 35814GV may be arecord at least 35831GV.

For the listAgencyID 35832GV, the Category is Attribute 35834GV, theObject Class term is CodeListAgency 35836GV, the Property term isIdentification 35838GV, the Representation/Association term isIdentifier 35840GV, the Type term is XSD 35842GV, and the Type Name termis token 35844GV. The Cardinality between the listAgencyID 35832GV andthe GDT SalesCyclePhaseCode 35800GV is either zero or one 35848GV. ThelistAgencyID 35812GV may be a record at least 35849GV.

For the listVersionID 35850GV, the Category is Attribute 35852GV, theObject Class term is CodeList 35854GV, the Property term is Version35856GV, the Representation/Association term is Identifier 35858GV, theType term is XSD 35860GV, and the Type Name term is token 35862GV. Thecardinality between the listVersionID 35846GV and the GDTSalesCyclePhaseCode 35800GV is either zero or one 358666GV. ThelistVersionID 35812GV may be a record at least 35867GV.

For the listAgencySchemeID 35868GV, the Category is Attribute 35870GV,the Object Class term is CodeListAgency 35872GV, the Property term isScheme 35874GV, the Representation/Association term is Identifier35876GV, the Type term is XSD 35878GV, and the Type Name term is token35880GV. The cardinality between the listAgencySchemeID 35864GV and theGDT SalesCyclePhaseCode 35800GV is either zero or one 35884GV.

For the listAgencySchemeAgencyID 35886GV, the Category is Attribute35888GV, the Object Class term is CodeListAgency 35890GV, the Propertyterm is SchemeAgency 35892GV, the Representation/Association term isIdentifier 35894GV, the Type term is XSD 35896GV, and the Type Name termis token 35897GV. The cardinality between the listAgencySchemeAgencyID35886GV and the GDT SalesCyclePhaseCode 35800GV is either zero or one35899GV.

Several code lists may be used for the GDT SalesCyclePhaseCode 35800GV.Additionally, a predefined code list may be delivered. In someimplementations, other code lists can be added by the customer. Anexample of attributes in the GDT SalesCyclePhaseCode 35800GV are definedas follows:

listID—ID of corresponding code list.

listAgencyID=310

listID—Version of corresponding code list.

Some possible values are: Code Name Description 1 Project In this phase,general information is collected on the customer, identificationcontacts are determined, and a requirements catalog is compiled. 2Qualification In this phase, the feasibility is determined. A decisionis made on whether to terminate the opportunity, or pursue it further. 3Value selling In this phase, a customer-specific use analysis and acompetitor strategy is drawn up. 4 Quotation In this phase, acustomer-specific quotation is drawn up and presented to the customer. 5Decision In this phase, feedback is obtained on the quotation, andunresolved items are clarified, the goal being to obtain non-bindingconfirmation from the customer that a contract will be concluded. 6Conclusion In this phase, either a contract is negotiated with thecustomer, or the reasons for failure are analyzed, depending on theoutcome.

A customer may define a code list using the attributes as follows:

listID—ID of corresponding code list. Assigned and managed by theorganization responsible for the code list, which is not listed in DE3055. If no unique ID is available, enter the name of the correspondingcode list or code type that can be used in the corresponding standard,specification, or scheme of the responsible organization.

listAgencyID—ID of the organization managing the code list. This ID isassigned by the organization based on DE 3055 (for example, a company'sDUNS or EAN number).

listID—Version of corresponding code list. Assigned and managed by theorganization specified in the listAgencyID. The relevant version ID maybe obtained by the GDT owner from the responsible organization. If noversion was assigned for the code list, use the version outlined in thecorresponding standard, specification, or scheme.

listAgencySchemeID—The scheme ID used to identify the organizationspecified in the listAgencyID. This is a specific identification schemefor partners, companies, members, and so on—for example DUNS+4—of themanaging organization specified in the listAgencySchemeAgencyID—forexample EAN, DUNS, SWIFT.

listAgencySchemeAgencyID—The ID of the managing organization—forexample, DUNS, EAN, SWIFT—that is responsible for identifying theorganization specified in the listAgencyID.

In some implementations, the GDT SalesCyclePhaseCode 35800GV isprimarily used to model business objects. It defines a separate view ofa sales process, and may not be used in electronic message exchange withexternal parties.

The GDT SalesCyclePhaseCode 35800GV is primarily used in Presales, todescribe the phases in a sales cycle used in a business transaction.

An example of customer-specific code is a business alignment code thatis a coordination of strategy together with the quotation partners. Inanother example of customer-specific code is a competitor analysis codethat is a determination of the strengths and weaknesses of competitorproducts.

(qqqqqqqqqqqqqqqqq) SalutationText

A GDT SalutationText 35800GW is a salutation. A salutation is thecourteous greeting on meeting another person. Here, meeting representspersonal or non-personal (phone call, letter, telegram) contact. Withthis greeting the person offering the greeting demonstrates his view ofthe relation-ship with the greeted person. The salutations depend onculture, time and fashion. Using the GDT SalutationText 35800GW, a usercan store, for example, an individual salutation that can be usedinstead of a generated salutation, if required. An example (instance) ofthe GDT SalutationText 35800GW is:

<SalutationText>Dear Friends</SalutationText>

The structure of the GDT SalutationText 35800GW is depicted in FIG.358GW. The GDT SalutationText 35800GW includes an attribute LanguageCode35816GW. For the GDT SalutationText 35800GW, the Property term isSalutation 35802GW, the Representation/Association term is Text 35804GW,the Type term is GDT 35806GW, the Type Name term is Text 35808GW, andthe Length is from zero to fifty 35810GW. The Cardinality of theSalutationText 35800GW is one 35812GW. The GDT SalutationText 35800GWmay be restricted 35814GW.

For the LanguageCode 35816GW, the Category is Attribute 35818GW, theProperty term is Language 38020GW, the Representation/Association termis Code 35822GW, the Type term is XSD 35824GW, the Type Name term isLanguage 35826GW, the Length is from two to nine 35828GW. TheCardinality between the LanguageCode 35816GW and the GDT SalutationText35800GW is either zero or one 38530GW. The LanguageCode 35816GW may beoptional.

(rrrrrrrrrrrrrrrrr) SampleDrawingTypeCode

A GDT SampleDrawingTypeCode 35800GX is the coded representation of asample-drawing type. The sample-drawing type defines how samples are tobe drawn. They can be drawn based on a time interval or quantityinterval, depending on the container used, or based on customer-specificrules. An example (instance) of the GDT SampleDrawingTypeCode 35800GXis:

<SampleDrawingType>2</SampleDrawingTypeCode>

The structure of GDT SampleDrawingTypeCode 35800GX is depicted in FIG.358GX. For the GDT SampleDrawingTypeCode 35800GX, the Object Class termis Sample Drawing 35802GX, the Property term is Type 35804GX, theRepresentation/Association term is Code 35806GX, the Type term is CCT35808GX, the Type Name term is Code 35810GX, and the Length is one35812GX. The GDT SampleDrawingTypeCode 35800GX may be restricted35814GX.

The GDT SampleDrawingTypeCode 35800GX may include a fixed code list. Anexample of the attributes include the following values:

listID=“10111”

listAgencyID=“310”

listVersionID—Version of the relevant code list.

The GDT SampleDrawingTypeCode 35800GX can be used to define whethersamples are taken from a material based on time (for example, every twohours), based on quantity (for example, every 3rd unit), based on thecontainer (for example, every tank of a tanker), or based oncustomer-specific rules. For example, a code list may be defined as:Code Name Description 1 Time Time-based sample-drawing 2 QuantityQuantity-based sample drawing 3 Container Container-based sample drawing4 Individual Individual sample-drawing - specified by the user

(sssssssssssssssss) ShiftCalendarDeterminationRuleCode

A GDT ShiftCalendarDeterminationRuleCode 35800GY is the codedrepresentation of a rule based on which a shift calendar is determined.A shift calendar contains information on machine runtimes,non-production times, and shift durations. An example (instance) of theShiftCalendarDeterminationRuleCode 35800GY is:

<ShiftCalendarDeterminationRuleCode>1</ShiftCalendarDeterminationRuleCode>

The structure of GDT ShiftCalendarDeterminationRuleCode 35800GY isdepicted in FIG. 358GY. For the GDT ShiftCalendarDeterminationRuleCode35800GY, the Object Class term is Shift Calendar 35802GY, the Propertyterm is Determination Rule 35804GY, the Representation/Association termis Code 35806GY, the Type term is CCT 35808GY, the Type Name term isCode 35810GY, and the Length is one 35812GY. The GDTShiftCalendarDeterminationRuleCode 35800GY may be restricted 35814GY.

The GDT ShiftCalendarDeterminationRuleCode 35800GY can be used inproduction to define how the relevant shift calendar is found. Forexample, a code list may be defined that a code of 1 represents that aUseNoShiftCalendar can be used, and a code of 2 represents that aUseLogisticsDivisionShiftCalendar can be used. When theUseNoShiftCalendar is selected, then no shift calendar can be used,meaning machine runtimes, non-production times, or shift durations arenot taken into account. When the UseLogisticsDivisionShiftCalendar isselected, then the shift calendar that is assigned to the logisticsdivision can be used.

(ttttttttttttttttt) PowerOfAttorneyTypeCode

A GDT PowerOfAttorneyTypeCode 35800GZ is a coded representation of thetype of rights or power of attorney that someone has. An example of GDTPowerOfAttorneyTypeCode 35800GZ is:

<PowerOfAttorneyTypeCode>1</PowerOfAttorneyTypeCode>

The structure of GDT PowerOfAttorneyTypeCode 35800GZ is depicted in FIG.358GZ. The GDT PowerOfAttorneyTypeCode 35800GZ includes attributeslistID 35814GZ, listAgencyID 35830GZ, listVersionID 35846GZ,listAgencySchemeID 35862GZ, and listAgencySchemeAgencyID 35878GZ. Forthe GDT PowerOfAttorneyTypeCode 35800GZ, the Property term is Power ofAttorney Type 35802GZ, the Representation/Association term is Code35804GZ, the Type term is CCT 35806GZ, the Type Name term is Code35808GZ, and the Length is one 35810GZ. The PowerOfAttorneyTypeCode35800GZ may be restricted.

For the listID 35814GZ, the Category is Attribute 35816GZ, the ObjectClass term is CodeList 35818GZ, the Property term is Identification35820GZ, the Representation/Association term is Identifier 35822GZ, theType term is XSD 35824GZ, and the Type Name term is token 35826GZ. Thecardinality between the listID 35814GZ and the GDTPowerOfAttorneyTypeCode 35800GZ is either zero or one 35828GZ.

For the listAgencyID 35830GZ, the Category is Attribute 35832GZ, theObject Class term is CodeListAgency 35834GZ, the Property term isIdentification 35836GZ, the Representation/Association term isIdentifier 35838GZ, the Type term is XSD 35840GZ, and the Type Name termis token 35842GZ. The Cardinality between the listAgencyID 35830GZ andthe GDT PowerOfAttorneyTypeCode 35800GZ is either zero or one 35844GZ.

For the listVersionID 35846GZ, the Category is Attribute 35848GZ, theObject Class term is CodeList 35850GZ, the Property term is Version35852GZ, the Representation/Association term is Identifier 35854GZ, theType term is XSD 35856GZ, and the Type Name term is token 35858GZ. Thecardinality between the listVersionID 35846GZ and the GDTPowerOfAttorneyTypeCode 35800GZ is either zero or one 35860GZ.

For the listAgencySchemeID 35862GZ, the Category is Attribute 35864GZ,the Object Class term is CodeListAgency 35866GZ, the Property term isScheme 35868GZ, the Representation/Association term is Identifier35870GZ, the Type term is XSD 35872GZ, and the Type Name term is token35874GZ. The cardinality between the listAgencySchemeID 35862GZ and theGDT PowerOfAttorneyTypeCode 35800GZ is either zero or one 35876GZ.

For the listAgencySchemeAgencyID 35878GZ, the Category is Attribute35880GZ, the Object Class term is CodeListAgency 35882GZ, the Propertyterm is SchemeAgency 35884GZ, the Representation/Association term is.Identifier 35886GZ, the Type term is XSD 35888GZ, and the Type Name termis token 35890GZ. The cardinality between the listAgencySchemeAgencyID35878GZ and the GDT PowerOfAttorneyTypeCode 35800GZ is either zero orone 35892GZ.

The ListID 35814GZ of the relevant code list is assigned andadministered by a customer. The customer is responsible for the valuesof the ListID 35814GZ in question. The ListAgencyID 35830GZ is the ID ofthe customer. The ListVersionID 35846GZ is a version of the relevantcode list that is assigned and administered by the customer listed inthe ListAgencyID 35830GZ. The ListAgencySchemeID 35862GZ is the ID ofthe scheme by which the customer listed in the ListAgencyID isidentified. The ListAgencySchemeID 35862GZ is a particularidentification scheme for partners, businesses, and members and so on,of an administering organization that is listed in theListAgencySchemeAgency ID. The ListAgencySchemeAgencyID 35878GZ is theID of the administering organization that is responsible for identifyingthe organization listed in the ListAgencyID 35830GZ.

The GDT PowerOfAttorneyTypeCode 35800GZ can be used to express whichpower of attorney a person has in a company, for example, a generalpower of attorney and a general commercial power of attorney.

(uuuuuuuuuuuuuuuuu) PriceComponentInactivityReasonCode

The GDT PriceComponentInactivityReasonCode 35800HA is a codedrepresentation of the reason why a pricing element is inactive. Apricing element is inactive if it is not used to calculate subsequentpricing elements in a pricing rule in the context of price calculation.An example (instance) of the GDT PriceComponentInactivityReasonCode35800HA is:

<PriceComponentInactivityReasonCode>02</PriceComponentInactivityReasonCode>

The GDT PriceComponentInactivityReasonCode 35800HA is depicted in FIG.358HA. For the GDT PriceComponentInactivityReasonCode 35800HA, theObject Class term is Price Component 35802HA, the Property term isInactivity Reason 35804HA, the Representation/Association term is Code35806HA, the Type term is CCT 35808HA, the Type Name term is Code35810HA, and the Length is from one to two 35812HA. The GDTSupplyChainExceptionStatusCode 35800HA may be a restricted GDT 35814HA.

There is one code list and the GDT PriceComponentInactivityReasonCode35800HA is a fixed code list. The attributes ofPriceComponentInactivityReasonCode have the following values: listID is10125, listAgencyID is 310, and listVersionID is the version of therelevant code list, which is assigned and managed by SAP AG.

(vvvvvvvvvvvvvvvvv) PriceDetailLevelCode

The GDT PriceDetailLevelCode 35800HB is a coded representation of thelevel of detail of a price. An example (instance) of the GDTPriceDetailLevelCode 35800HB is:

<PriceDetailLevelCode>1</PriceDetailLevelCode>

The GDT PriceDetailLevelCode 35800HB is depicted in FIG. 358HB. For theGDT PriceDetailLevelCode 35800HB include a listVersionID 35816HBattribute. For the GDT PriceDetailLevelCode 35800HB, the object classterm is Price 35802HB, the Property Term is Detail Level 35804HB, theRepresentation/Association term is Code 35806HB, the Type term is CCT35808HB, the Type Name term is Code 35810HB, and the Length is from oneto two 35812HB. The GDT PriceDetailLevelCode 35800HB may be a restrictedGDT 35814HB.

For the listVersionID 35816HB, the Category is Attribute 35818HB, theObject Class term is CodeList 35820HB, the Property term is Version35822HB, the Representation/Association term is Identifier 35824HB, theType term is XSD 35826HB, and the Type Name term is token 35828HB. Thecardinality between the listVersionID 35816HB and the GDTPriceDetailLevelCode 35800HB is either zero or one 35830HB.

The GDT PriceDetailLevelCode 35800HB is a SAP code list with fixedpredefined values. Changes to the permitted values involve changes tothe interface. The attributes of the GDT PriceDetailLevelCode 35800HBhave the following values: listID is “10102”, listAgencyID is “310”, andlistVersionID is an ID of the particular code list that is assigned andmanaged by SAP AG.

The GDT GDT PriceDetailLevelCode 35800HB is, for example, used in abidding process to show business partners which level of detail isexpected regarding the price information. In some implementations, acode list may include values as follows: Code Name Description 1 SimplePrice A price defined by an amount and a base quantity. 2 Complex Aprice defined using DO PriceSpecification. It Price can define validitydates, scales or discounts. 3 No Price No price is defined.

(wwwwwwwwwwwwwwwww) PriceSpecificationBaseCode

The GDT PriceSpecificationBaseCode 35800HC is the coded representationof the measurement on which the amount component of a price, discount,or surcharge specification is based. Examples of measurementcharacteristics are gross weight, net weight, or volume. An example(instance) of the GDT PriceSpecificationBaseCode 35800HC is:

<Price SpecificationBaseCode>1</PriceSpecificationBaseCode>

The structure of GDT PriceSpecificationBaseCode 35800HC is depicted inFIG. 358HC. For the GDT PriceSpecificationBaseCode 35800HC, the ObjectClass term is Price Specification 35802HC, the Property term is Base35804HC, the Representation/Association term is Code 35806HC, the Typeterm is CCT 35808HC, the Type Name term is Code 35810HC, and the Lengthis from one to two 35812HB. The PriceSpecificationBaseCode 35800HC maybe restricted.

In some implementations, there is exactly one code list. The GDTPriceSpecificationBaseCode 35800HC is a fixed code list. An exemplarydescription of the attributes are a listID that is “10082,” or alistAgencyID that is “310,” a listID

The GDT PriceSpecificationBaseCode 35800HC can be used for maintainingsales or purchasing price specifications. The PriceSpecificationBaseCode35800HC influences the method of price calculation in a businesstransaction. The calculation of the price, discount, or surcharge isdone on the basis of the specification of the price, discount, orsurcharge by means of the GDT PriceSpecificationBaseCode 35800HC, and onthe basis of the document data provided by the calling system.

In some implementations, the GDT PriceSpecificationBaseCode 35800HC maycorrespond to the SAP R/3 and SAP CRM fields KRECH. For example, the GDTPriceSpecificationBaseCode 35800HC may be an SAP code list with fixedpredefined values. Changes to the valid characteristics necessitatechanges to the interfaces. An example of the code list is shown asfollows: Code Name Description 1 Percentage (of one The discount orsurcharge (general) is provided as a part of hundred) the basic amountin percent, that is, as a percentage. The basic amount is the amountthat is determined until now in the price calculation. 2 Fixed AmountThe price, discount, or surcharge is not based on a measurement, but isjust an amount. 3 Quantity The price, discount, or surcharge is based ona quantity (for example, the sales quantity of the product in a salesorder item). 4 Gross Weight The price, discount, or surcharge is basedon a gross weight (for example, the gross weight of the product in asales order item). 5 Net Weight The price, discount, or surcharge isbased on a net weight (for example, the net weight of the product in asales order item).

(xxxxxxxxxxxxxxxxx) PriceSpecificationCustomerGroupCode

The GDT PriceSpecificationCustomerGroupCode 35800HD is the codedrepresentation of a group of customers for whom the same pricedetermination applies. An example (instance) of the GDTPriceSpecificationCustomerGroupCode 35800HD is:

<PriceSpecificationCustomerGroupCode>1</PriceSpecificationCustomerGroupCode>

The structure of GDT PriceSpecificationCustomerGroupCode 35800HD isdepicted in FIG. 358HD. The GDT PriceSpecificationCustomerGroupCode35800HD includes attributes listID 35814HD, listAgencyID 35830HD,listVersionID 35846HD, listAgencySchemeID 35862HD, andlistAgencySchemeAgencyID 35878HD. For the GDTPriceSpecificationCustomerGroupCode 35800HD, the Object Class Qualifierterm is Price Specification 35802HD, the Object Class term is CustomerGroup 35804HD, the Representation/Association Term is Code 35806HD, theType term is CCT 35808GZ, the Type Name term is Code 35810HD, and theLength is either one or two 35812HD.

For the listID 35814HD, the Category is Attribute 35816HD, the ObjectClass term is CodeList 35818HD, the Property term is Identification35820HD, the Representation/Association term is Identifier 35822HD, theType term is XSD 35824HD, and the Type Name term is token 35826HD. Thecardinality between the listID 35814HD and the GDTPriceSpecificationCustomerGroupCode 35800HD is either zero or one35828HD.

For the listAgencyID 35830HD, the Category is Attribute 35832HD, theObject Class term is CodeListAgency 35834HD, the Property term isIdentification 35836HD, the Representation/Association term isIdentifier 35838HD, the Type term is XSD 35840HD, and the Type Name termis token 35842HD. The cardinality between the listAgencyID 35830HD andthe GDT PriceSpecificationCustomerGroupCode 35800HD is either zero orone 35844HD.

For the listVersionID 35846HD, the Category is Attribute 35848HD, theObject Class term is CodeList 35850HD, the Property term is Version35852HD, the Representation/Association term is Identifier 35854HD, theType term is XSD 35856HD, and the Type Name term is token 35858HD. Thecardinality between the listVersionID 35846HD and the GDTPriceSpecificationCustomerGroupCode 35800HD is either zero or one35860HD.

For the listAgencySchemeID 35862HD, the Category is Attribute 35864HD,the Object Class term is CodeListAgency 35866HD, the Property term isScheme 35868HD, the Representation/Association term is Identifier35870HD, the Type term is XSD 35872HD, and the Type Name term is token35874HD. The cardinality between the listAgencySchemeID 35862HD and theGDT PriceSpecificafionCustomerGroupCode 35800HD is either zero or one35876HD.

For the listAgencySchemeAgencyID 35878HD, the Category is Attribute35880HD, the Object Class term is CodeListAgency 35882HD, the Propertyterm is SchemeAgency 35884HD, the Representation/Association term isIdentifier 35886HD, the Type term is XSD 35888HD, and the Type Name termis token 35890HD. The cardinality between the listAgencySchemeAgencyID35878HD and the GDT PriceSpecificationCustomerGroupCode 35800HD iseither zero or one 35892HD.

The GDT PriceSpecificationCustomerGroupCode 35800HD is acustomer-specific code. For each administering organization (agency)only one code list is allowed. The attribute listID 35814HD is an ID ofthe relevant code list that is assigned and administered by a customer.The customer is responsible for the values of the ID in question. Theattribute listAgencyID 35830HD is an ID of the customer. The attributelistVersionID 35846HD is a version of the relevant code list that isassigned and administered by the customer listed in the attributelistAgencyID 35846HD. The attribute listAgencySchemeID 35862HD is the IDof the scheme by which the customer listed in the listAgencyID isidentified. The attribute listAgencyID 35862HD is a particularidentification scheme for partners, businesses, and members (such asDUNS+4), and so on, of an administering organization (such as EAN, DUNS,and SWGZT) that is listed in the listAgencySchemeAgencyID. The attributelistAgencySchemeAgencyID 35878HD is an ID of the administeringorganization (such as DUNS, EAN, or SWGZT) that is responsible foridentifying the organization listed in the listAgencyID. It has to belisted in DE 3055.

The GDT PriceSpecificationCustomerGroupCode 35800HD may currently beused only in business objects and A2A messages. The GDTPriceSpecificationCustomerGroupCode 35800HD can be used, for example,for price determination in sales orders, in order to determine pricesthat apply to the customer. In one example, a possible semantic of thecodes is Bulk buyers, meaning customers who are granted a price for bulkbuyers. In another example, a possible semantic of the codes isOccasional buyers, meaning customers who are not granted a discount. Inyet another example, a possible semantic of the codes is New customers,meaning customers who are granted a discount for new customers.

(yyyyyyyyyyyyyyyyy) PriceSpecificationElementPropertyID

The GDT PricingPriceSpecificationElementPropertyID 35800HE is a uniqueidentifier of a property for the specification of a price, discount orsurcharge. Properties are determining elements on the agreement ofprice, discount or surcharge. An example (instance) of the GDTPricingPriceSpecificationElementPropertyID 35800HE is:<PriceSpecificationElementPropertyID>   PRODUCT_ID</PriceSpecificationElementPropertyID>

The structure of GDT PricingPriceSpecificationElementPropertyID 35800HEis depicted in FIG. 358HE. For the GDTPricingPriceSpecificationElementPropertyID 35800HE, the Object Classterm is PriceSpecificationElementProperty 35802HE, the Property term isIdentification 35804HE, the Representation/Association term isIdentifier 35806HE, the Type term is CCT 35808HE, the Type Name term isIdentifier 35810HE, and the Length is from one to thirty 35812HE. TheGDT PricingPriceSpecificationElementPropertyID 35800HE may be restricted35814HE.

A property that is described by the GDTPricingPriceSpecificationElementPropertyID 35800HE may be unique withinthe PriceSpecificationElementPropertyDefinitionClass property definitionclass. The property can be assigned to several property definitionclasses.

(zzzzzzzzzzzzzzzzz) PriceSpecificationElementScaleLine

A GDT PriceSpecificationElementScaleLine 35800HF is a scale line for thespecification of a price, discount or surcharge. To define a price,discount, or surcharge specification, you can use a one ortwo-dimensional scale. This scale consists of scale lines, which definea price, discount, or surcharge as a scale value for each scale level.An example (instance) of the GDT PriceSpecificationElementScaleLine35800HF is: <PriceSpecificationElementScaleLine>   <ScaleAxisStep>  <ScaleAxisBaseCode>1</ScaleAxisBaseCode>  <IntervalBoundaryTypeCode>1</IntervalBoundaryTypeCode>   <QuantityunitCode=“C62”>10</Quantity>   </ScaleAxisStep>   <Rate>    <Value>29.99</Value>     <CurrencyCode>EUR</CurrencyCode>    <BaseMeasureUnitCode>C62</BaseMeasureUnitCode>   </Rate>  </PriceSpecificationElementScaleLine>

In this example, the scale may be a scale line for a price specificationthat scale is a one-dimensional ‘from’ price scale. For example, theprice is EUR 29.99 EUR per piece from 10 pieces. A ScaleAxisBaseCode 1represents a quantity according to GDT: ScaleAxisBaseCode. AnIntervalBoundaryTypeCode 1 represents a ‘from’ price scale according toGDT: ScaleAxisStepIntervalBoundaryTypeCode. A unitCode C62 is a pieceaccording to UN/ECE Recommendation #20.

The structure of GDT PriceSpecificationElementScaleLine 35800HF isdepicted in FIG. 358HF. The GDT PriceSpecificationElementScaleLine35800HF includes elements ScaleAxisStep 35806HF, Rate 35822HF, Percent35838HF, and Fixed Amount 35854HF. For the GDTPriceSpecificationElementScaleLine 35800HF, the Object Class term isPrice Specification Element Scale Line 35802HF. TheRepresentation/Association term is Details 35804HF.

For the ScaleAxisStep 35806HF, the Category is Element 35808HF. TheObject Class term is Price Specification Element Scale Line 35810HF. TheProperty term is ScaleAsixStep 35812HF. The Representation/Associationterm is ScaleAxisStep 35814HF. The Type term is GDT 35816HF. The TypeName term is ScaleAxisStep 35818HF. The Cardinality between theScaleAxisStep 35814HF and the GDT PriceSpecificationElementScaleLine35800HF is either one or two 35820HF.

For the Rate 35822HF, the Category is Element 35824HF. The Object Classterm is Price Specification Element Scale Line 35826HF. The Propertyterm is Rate 35828HF. The Representation/Association term is Rate35830HF. The Type term is GDT 35832HF. The Type Name term is Rate35834HF. The Cardinality between the Rate 35822HF and the GDTPriceSpecificationElementScaleLine 35800IF is either zero or one35836HF.

For the Percent 35838HF, the Category is Element 35840HF. The ObjectClass term is Price Specification Element Scale Line 35842HF. TheProperty term is Percent 35844HF. The Representation/Association term isPercent 35846HF. The Type term is GDT 35848HF. The Type Name term isPercent 35850HF. The Cardinality between the Percent 35838HF and the GDTPriceSpecificationElementScaleLine 35800HF is either zero or one35852HF.

For the FixedAmount 35854HF, the Category is Element 35856HF. The ObjectClass term is Price Specification Element Scale Line 35858HF. TheProperty term is FixedAmount 35860HF. The Representation/Associationterm is Amount 35862HF. The Type term is GDT 35864HF. The Type Name termis Amount 35866HF. The Cardinality between the FixedAmount 35854HF andthe GDT PriceSpecificationElementScaleLine 35800HF is either zero or one35868HF.

The GDT PriceSpecificationElementScaleLine 35800HF has the followingelements:

ScaleAxisStep—Axis Step (scale dimension value) of a dimension of thescale level for which the scale line is defined for the price, discountor surcharge specification.

Rate—Scale value as a monetary rate for prices, discounts or surcharges.In principle, the rate can also be a percentage or a fixed amount.

Percent—Scale value as a percentage for discounts or surcharges.

FixedAmount—Scale value as a fixed amount for discounts or surcharges.

In some implementations, in the GDT PriceSpecificationElementScaleLine35800HF, the same ScaleAxisStep/ScaleAxisBaseCode may not be specifiedfor different ScaleAxisStep elements. Also, exactly one of the elementsRate, Percent or FixedAmount may be available. Additionally, thenumerator of the Rate element may not be non-dimensional. The numeratordimension may be a currency or a percentage. If the Rate elementrepresents a percentage or a fixed amount, the elements Rate/BaseValue,Rate/BaseMeasureUnitCode and Rate/BaseCurrencyCode must not bespecified.

In some implementations, if an element that is typed by the GDTPriceSpecificationElementScaleLine 35800HF has cardinality greater thanone, then the same type of scale value Rate, Percent, or FixedAmount hasto be specified in all instances.

In some implementations, if an element that is typed by the GDTPriceSpecificationElementScaleLine 35800HF has cardinality greater thanone, the elements ScaleAxisStep have to be specified with the samenumber and the same values of ScaleAxisStep/ScaleAxisBaseCode in allinstances.

(aaaaaaaaaaaaaaaaaa) PriceSpecificationProductGroupCode

The GDT PriceSpecificationProductGroupCode 35800HG is the codedrepresentation of a group of products for which the same pricedetermination applies. An example (Instance) of the GDTPriceSpecificationProductGroupCode 35800HG is:

<PriceSpecificationProductGroupCode>1</PriceSpecificationProductGroupCode>

The structure of GDT PriceSpecificationProductGroupCode 35800HG isdepicted in FIG. 358HG. The GDT PriceSpecificationProductGroupCode35800HG includes attributes listID 35814HG, listAgencyID 35830HG,listVersionID 35846HG, listAgencySchemeID 35862HG, andlistAgencySchemeAgencyID 35878HG. For the GDTPriceSpecificationProductGroupCode 35800HG, the Property term is PriceSpecification 35802HG, the Object Class term is Product Group 35804HG,the Representation/Association term is Code 35806HG, the Type term isCCT 35808HG, the Type Name term is Code 35810HG, and the Length iseither one or two 35812HG.

For the listID 35814HG, the Category is Attribute 35816HG, the ObjectClass term is CodeList 35818HG, the Property term is Identification35820HG, the Representation/Association term is Identifier 35822HG, theType term is XSD 35824HG, and the Type Name term is token 35826HG. Thecardinality between the listID 35814HG and the GDTPriceSpecificationProductGroupCode 35800HG is either zero or one35828HG.

For the listAgencyID 35830HG, the Category is Attribute 35832HG, theObject Class term is CodeListAgency 35834HG, the Property term isIdentification 35836HG, the Representation/Association term isIdentifier 35838HG, the Type term is XSD 35840HG, and the Type Name termis token 35842HG. The Cardinality between the listAgencyID 35830HG andthe GDT PriceSpecificationProductGroupCode 35800HG is either zero or one35844HG.

For the listVersionID 35846HG, the Category is Attribute 35848HG, theObject Class term is CodeList 35850HG, the Property term is Version35852HG, the Representation/Association term is Identifier 35854HG, theType term is XSD 35856HG, and the Type Name term is token 35858HG. Thecardinality between the listVersionID 35846HG and the GDTPriceSpecificationProductGroupCode 35800HG is either zero or one35860HG.

For the listAgencySchemeID 35862HG, the Category is Attribute 35864HG,the Object Class term is CodeListAgency 35866HG, the Property term isScheme 35868HG, the Representation/Association term is Identifier35870HG, the Type term is XSD 35872HG, and the Type Name term is token35874HG. The cardinality between the listAgencySchemeID 35862HG and theGDT PriceSpecificationProductGroupCode 35800HG is either zero or one35876HG.

For the listAgencySchemeAgencyID 35878HG, the Category is Attribute35880HG, the Object Class term is CodeListAgency 35882HG, the Propertyterm is SchemeAgency 35884HG, the Representation/Association term isIdentifier 35886HG, the Type term is XSD 35888HG, and the Type Name termis token 35890HG. The cardinality between the listAgencySchemeAgencyID35878HG and the GDT PriceSpecificationProductGroupCode 35800HG is eitherzero or one 35892HG.

The GDT PriceSpecificationProductGroupCode 35800HG is acustomer-specific code. For each administering organization (agency)only one code list is allowed. In some implementations, the attributesare used as follows:

listID—ID of the relevant code list. It is assigned and administered bya customer. The customer is responsible for the values of the ID inquestion.

listAgencyID—ID of the customer. An ID assigned by an organizationlisted in the DE 3055 may be used (such as the business IDs assigned byDUNS, EAN, and SWGZT).

listVersionID—Version of the relevant code list. It is assigned andadministered by the customer listed in the listAgencyID.

listAgencySchemeID—ID of the scheme by which the customer listed in thelistAgencyID is identified. It is a particular identification scheme forpartners, businesses, and members (such as DUNS+4), and so on, of anadministering organization (such as EAN, DUNS, and SWGZT) that is listedin the listAgencySchemeAgencyID.

listAgencySchemeAgencyID—ID of the administering organization (such asDUNS, EAN, or SWGZT) that is responsible for identifying theorganization listed in the listAgencyID. It has to be listed in DE 3055.

In some implementations, the GDT PriceSpecificationProductGroupCode35800HG may currently be used only in business objects and A2A messages.

In some implementations, the GDT PriceSpecificationProductGroupCode35800HG can be used, for example, for price determination in salesorders, in order to determine prices that apply to the product. Examplesof the possible semantics of the codes are, standard parts, which areproducts for which standard price determination should apply, and spareparts, which are products for which price determination for the spareparts should apply.

(bbbbbbbbbbbbbbbbbb) PricingProcedureCode

A GDT PricingProcedureCode 35800HH is a coded representation of theprocedure used for the price calculation. The procedure is defined by anumber of pricing element definitions arranged in sequence, and can beused to control the price calculation. In general, the procedure isspecified for the combination of business transaction type and businesspartner type. An example of GDT PricingProcedureCode 35800HH is:

<PricingProcedureCode>1</PricingProcedureCode>

The structure of GDT PricingProcedureCode 35800HH is depicted in FIG.358HH. The GDT PricingProcedureCode 35800HH includes attributes listID35814HH, listAgencyID 35830HH, listVersionID 35846HH, listAgencySchemeID35862HH, and listAgencySchemeAgencyID 35878HH. For the GDTPricingProcedureCode 35800HH, the Object Class term is Power of PricingProcedure 35802HH, the Representation/Association term is Code 35804HH,the Type term is CCT 35806HH, the Type Name term is Code 35808HH, andthe Length is from one to four 35810HH. The GDT PricingProcedureCode35800HH may be restricted 35812HH.

For the listID 35814HH, the Category is Attribute 35816HH, the ObjectClass term is CodeList 35818HH, the Property term is Identification35820HH, the Representation/Association term is Identifier 35822HH, theType term is XSD 35824HH, and the Type Name term is token 35826HH. Thecardinality between the listID 35814HH and the GDT PricingProcedureCode35800HH is either zero or one 35828HH.

For the listAgencyID 35830HH, the Category is Attribute 35832HH, theObject Class term is CodeListAgency 35834HH, the Property term isIdentification 35836HH, the Representation/Association term isIdentifier 35838HH, the Type term is XSD 35840HH, and the Type Name termis token 35842HH. The Cardinality between the listAgencyID 35830HH andthe GDT PricingProcedureCode 35800HH is either zero or one 35844HH.

For the listVersionID 35846HH, the Category is Attribute 35848HH, theObject Class term is CodeList 35850HH, the Property term is Version35852HH, the Representation/Association term is Identifier 35854HH, theType term is XSD 35856HH, and the Type Name term is token 35858HH. Thecardinality between the listVersionID 35846HH and the GDTPricingProcedureCode 35800HH is either zero or one 35860HH.

For the listAgencySchemeID 35862HH, the Category is Attribute 35864HH,the Object Class term is CodeListAgency 35866HH, the Property term isScheme 35868HH, the Representation/Association term is Identifier35870HH, the Type term is XSD 35872HH, and the Type Name term is token35874HH. The cardinality between the listAgencySchemeID 35862HH and theGDT PricingProcedureCode 35800HH is either zero or one 35876HH.

For the listAgencySchemeAgencyID 35878HH, the Category is Attribute35880HH, the Object Class term is CodeListAgency 35882HH, the Propertyterm is SchemeAgency 35884HH, the Representation/Association term isIdentifier 35886HH, the Type term is XSD 35888HH, and the Type Name termis token 35890HH. The cardinality between the listAgencySchemeAgencyID35878HH and the GDT PricingProcedureCode 35800HH is either zero or one35892HH.

A customer-specific code list is assigned to the GDTPricingProcedureCode 35800HH. For example, a customer can define thecodes in the customer-specific code list.

The attributes of the GDT PricingProcedureCode 35800HH correspond tothose of the CCT Code. As an example, the attributes of the GDTPricingProcedureCode 35800HH can be assigned the following values: thelistID is “10141,” the listAgencyID is the ID of the customer, thelistVersionID is the assigned and managed by the customer, thelistAgencySchemeID is the ID of the scheme if the listAgencyID is nottaken from DE 3055, and the listAgencySchemeAgencyID is the ID of theorganization (taken from DE 3055) that manages the scheme of thelistAgencySchemeID.

For example, some of the possible semantics of the codes are InternetSales that is calculation rule for business transactions in InternetSales, Wholesale Trade that is calculation rule for businesstransactions in wholesale trade, and Wholesale Trade Export that iscalculation rule for business transactions in wholesale trade forexport.

In some implementations, the GDT PricingProcedureCode 35800HH isrepresented by the pricing procedure in the ERP system.

(cccccccccccccccccc) PricingProcedureDeterminationCode

The GDT PricingProcedureDeterminationCode 35800HI is a codedrepresentation of the determination of a pricing procedure. A pricingprocedure describes the means, and, in particular, the sequence, bywhich price specifications are taken into consideration during pricedetermination. An example of the GDT PricingProcedureDeterminationCode35800HI is:

<PricingProcedureDeterminationCode>1</PricingProcedureDeterminationCode>

The structure of GDT PricingProcedureDeterminationCode 35800HI isdepicted in FIG. 358HI. For the GDT PricingProcedureDeterminationCode35800HI, the Object Class term is Pricing Procedure Determination35802HI, the Representation/Association term is Code 35804HI, the Typeterm is CCT 35806HI, the Type Name term is Code 35808HI, the Length isone 35810HI.

The GDT PricingProcedureDeterminafionCode 35800HI is a fixed, specificcode list. The attributes listID, listAgencyID, listVersionID,listAgencySchemeID, listAgencySchemeAgencyID are omitted in thestructure table, because they would contain only constant, specificvalues during runtime.

In some implementations, the GDT PricingProcedureDeterminationCode35800HI should only be used when both sender and recipient have accessto shared or harmonized Business Configuration, for example duringinternal communication in an enterprise.

The GDT PricingProcedureDeterminationCode 35800HI can be used todetermine a pricing procedure for a customer in a sales document. Someexamples for semantics of the code list are:

Standard—standard pricing procedure applies

Standard incl. sales tax—standard pricing procedure including sales taxapplies

(dddddddddddddddddd) ProductCategoryHierarchyUsageCode

The GDT ProductCategoryHierarchyUsageCode 35800HJ represents, in theform of a code, the usage of a product category hierarchy. A productcategory hierarchy is a classification system for products. The productcategory hierarchy describes a hierarchical ordering of productcategories that exist on both higher and lower levels in relation to oneanother, and whose structure can be represented as a tree. An example(instance) of the GDT ProductCategoryHierarchyUsageCode 35800HJ is:

<ProductCategoryHierarchyUsageCode>1</ProductCategoryHierarchyUsageCode>

The structure of GDT ProductCategoryHierarchyUsageCode 35800HJ isdepicted in FIG. 358HJ. For the ProductCategoryHierarchyUsageCode35800HJ, the Object Class term is Product Category Hierarchy 35802HJ,the Property term is Usage 35804HJ, the Representation/Association termis Code 35806HJ, the Type term is CCT 35808HJ, the Type Name term isCode 35810HJ, and the Length is from one to twenty 35812HJ. The GDTProductCategoryHierarchyUsageCode 35800HJ may be restricted 35814HJ.

Several code lists are allowed for the GDTProductCategoryHierarchyUsageCode 35800HJ. For example, a first codelist and additional code lists that depend on the implementedapplications may be provided by SAP AG in Walldorf Germany. Also,customers can add other code lists. As an example, the attributes havethe following values:

listID=“10065”

listAgencyID=“310”

listVersionID—version of the relevant code list.

In some implementations, the attributes are used as follows:

ListID—ID of the relevant code list. It is assigned and administered bya customer. The customer is responsible for the values of ID inquestion.

ListAgencyID—The ID of the customer. An ID assigned by an organizationlisted in the DE 3055 may be used.

ListVersionID—version of the relevant code list. It is assigned andadministered by the customer listed in the ListAgencyID.

ListAgencySchemeID—the ID of the scheme by which the customer listed inthe ListAgencyID is identified. It is a particular identification schemefor partners, businesses, and members and so on, of an administeringorganization that is listed in the ListAgencySchemeAgency ID.

ListAgencySchemeAgencyID—the ID of the administering organization thatis responsible for identifying the organization listed in theListAgencyID. It has to be listed in DE 3055.

During product maintenance the number of maintainable product categoryhierarchies, and thus the number of product attributes, is limited whenyou enter a ProductCategoryHierarchyUsageCode.

An exemplary code List is shown in the following table: Code NameDescription 1 Sales Product category hierarchy can be used to representthe sales data for a product 2 Purchasing Product category hierarchy canbe used to represent the purchasing data for a product 3 Basic DataProduct category hierarchy can be used to represent the basic data for aproduct

(eeeeeeeeeeeeeeeeee) ProductDimensions

The GDT ProductDimensions 35800HK contains the dimensions of a productin length, width and height in one single unit of measurement. Anexample (instance) of the ProductDimensions 35800HK is:<ProductDimensions measureUnitCode=“CM”>  <LengthMeasure>100,3</LengthMeasure >  <WidthMeasure>51,6</WidthMeasure >  <HeightMeasure>22,7</HeightMeasure > </ProductDimensions>

The structure of GDT ProductDimensions 35800HK is depicted in FIG.358HK. The GDT ProductDimensions 35800HK includes an attributeMeasureUnitCode 35808HK, and elements LengthMeasure 35824HK,WidthMeasure 35840HK, and HeightMeasure 35856HK. For the GDTProductDimensions 35800HK, the Object Class term is Product Dimensions35802HK, the Property term is Details 35804HK, and theRepresentation/Association term is Details 35806HK.

For the MeasureUnitCode 35808HK, the Category is Attribute 35810HK. TheObject Class term is Product Dimensions 35812HK. The Property term isMeasure Unit 35814HK. The Representation/Association term is Code35816HK. The Type term is GDT 35818HK. The Type Name term isMeasureUnitCode 35820HK. The Cardinality between the MeasureUnitCode35808HK and the GDT ProductDimensions 35800HK is one 35822HK.

For the LengthMeasure 35824HK, the Category is Element 35826HK. TheObject Class term is Product Dimension 35828HK. The Property term isLength 35830HK. The Representation/Association term is Measure 35832HK.The Type term is GDT 35834HK. The Type Name term is Measure 35836HK. TheCardinality between the LengthMeasure 35824HK and the GDTProductDimensions 35800HK is either zero or one 35838HK.

For the WidthMeasure 35840HK, the Category is Element 35842HK. TheObject Class term is Product Dimension 35844HK. The Property term isWidth 35846HK. The Representation/Association term is Measure 35848HK.The Type term is GDT 35850HK. The Type Name term is Measure 35852HK. TheCardinality between the WidthMeasure 35840HK and the GDTProductDimensions 35800HK is either zero or one 35854HK.

For the HeightMeasure 35856HK, the Category is Element 35858HK. TheObject Class term is Product Dimension 35860HK. The Property term isHeight 35862HK. The Representation/Association term is Measure 35864HK.The Type term is GDT 35866HK. The Type Name term is Measure 35868HK. TheCardinality between the HeightMeasure 35856HK and the GDTProductDimensions 35800HK is either zero or one 35870HK.

In some implementations, the GDT ProductDimensions 35800HK may haveleast one dimension, length, width, or height, be specified. Dependingon the character and use of the product, not all dimensions have to bespecified. The plausibility of the dimensions can only be checked in thecontext of each application.

(ffffffffffffffffff) ProductionSegmentID

A GDT ProductionSegmentID 35800HL is a unique identifier for aproduction segment. A ProductionSegment is a section in the productionof a material in a LogisticsDivision. An example (instance) of the GDTProductionSegmentID 35800HL is:

<ProductionSegmentID>WPRD_(—)1</ProductionSegmentID>

The structure of GDT ProductionSegmentID 35800HL is depicted in FIG.358HL. For the ProductionSegmentID 35800HL, the Object Class term isProduct Segment 35802HL, the Property term is Identification 35804HL,the Representation/Association term is Identifier 35806HL, the Type termis CCT 35808HL, the Type Name term is Identifier 35810HL, and the Lengthis from one to forty 35812HL. The GDT ProductionSegmentID 35800HL may berestricted 35814HL.

(gggggggggggggggggg) ProductModelID

A GDT ProductModelID 35800HM is a unique identifier for a model of aproduct. A model signifies the specific construction type of a materialproduct that can also be produced or provided in another, relatedconstruction type. There can be several models for one product. Anexample (instance) of the GDT ProductModelID 35800HM is:

<ProductModelID>MAN-10003<ProductModelID>

The structure of GDT ProductModelID 35800HM is depicted in FIG. 358HM.For the ProductModelID 35800HM, the Object Class term is Product Model35802HM, the Property term is Identification 35804HM, theRepresentation/Association term is Identifier 35806HM, the Type term isCCT 35808HM, the Type Name term is Identifier 35810HM, and the Length isfrom one to forty 35812HM. The GDT ProductModelID 35800HM may berestricted 35814HM.

In some implementations, aModelID is unique in the context of themanufacturer and a ProductID. As an example, a car manufacturer mayspecify his models by size, cubic capacity, engine type, body style. Acustomer can then represent the size by a letter, a number or a name,the cubic capacity by a number, the engine type by letters and the bodystyle by a name. An example of such values would be 435DI Caravan, 435SCoupe, or B22S Coupe.

(hhhhhhhhhhhhhhhhhh) ProductPartyID

A GDT ProductPartyID 35800HN is an identifier for a product assigned bya party. A product is either a tangible or intangible good, and is apart of the business activities of a company. It can be traded andcontributes directly or indirectly to value added. An example (instance)of the GDT ProductPartyID 35800HN is:

<ProductSellerID>B1165HS</ProductSellerID>

The structure of GDT ProductPartyID 35800HN is depicted in FIG. 358HN.For the GDT ProductPartyID 35800HN, the Object Class term is Product35802HN, the Property Qualifier term is Party 35804HN, the Property termis Identification 35806HN, the Representation/Association term isIdentifier 35808HN, the Type term is GDT 35810HN, the Type Name term isProductID 35812HN, and the Length is from one to sixty 35814HN. The GDTProductPartyID 35800HN may be restricted 35816HN.

The GDT ProductPartyID 35800HN is the proprietary identifier assigned bya business partner. The business partner (in its role) that assignedthis identifier must derive from the business context of the messagethat the GDT ProductPartyID 35800HN uses.

The use of the GDT ProductPartyID 35800HN is role-dependent (forexample, as an ID assigned by the Buyer). The party is specified by itsrole. “Party” is replaced with the “partner role type” (for example,ProductSellerID).

(iiiiiiiiiiiiiiiiii) ProductTax

A GDT ProductTax 35800HO is a tax that is incurred duringproduct-related business transactions such as purchase, sales orconsumption. An example (instance) of a GDT ProductTax 35800HO used inTaxDueNotification is: <ProductTax>   <CountryCode>DE</CountryCode>  <TypeCode>VAT</TypeCode>   <TypeDescription>Value addedtax</TypeDescription>   <BaseAmount currencyCode=“EUR”>100</BaseAmount>  <Percent>16</Percent>   <Amount currencyCode=“EUR”>116</Amount>  BusinessTransactionDocumentItemGroupID>1</BusinessTransaction  DocumentItemGroupID> </ProductTax>

The structure of GDT ProductTax 35800HO is depicted in FIG. 358HOi andFIG. 358HOii. The GDT ProductTax 35800HO includes elements CountryCode35803HO, JurisdictionCode 35811HO, TypeCode 35819HO, TypeDescription35827HO, BaseAmount 35835HO, Percent 35843HO, Amount 35851HO,NonDeductiblePercent 358559HO, NonDeductibleAmount 35867HO,BusinessTransactionDocumentItemGroupID 35875HO, TriangulationIndicator35883HO, and LegallyRequiredPhrase 35892HO. For the GDT ProductTax35800HO, the Object Class term is Product Tax 35801HO, and theRepresentation/Association term is Details 35802HO.

For the CountryCode 35803HO, the Category is Element 35804HO. The ObjectClass term is Product Tax 35805HO. The Property term is Country Code35806HO. The Representation/Association term is Code 35807HO. The Typeterm is GDT 35808HO. The Type Name term is Country Code 35809HO. TheCardinality between the CountryCode 35803HO and the GDT ProductTax35800HO is either zero or one 35810HO.

For the JurisdictionCode 35811HO, the Category is Element 35812HO. TheObject Class term is Product Tax 35813HO. The Property term is TaxJurisdiction Code 35814HO. The Representation/Association term is Code35815HO. The Type term is GDT 35816HO. The Type Name term is TaxJurisdiction Code 35817HO. The Cardinality between the JurisdictionCode35811HO and the GDT ProductTax 35800HO is either zero or one 35818HO.

For the TypeCode 35819HO, the Category is Element 35820HO. The ObjectClass term is Product Tax 35821HO. The Property term is Type Code35822HO. The Representation/Association term is Code 35823HO. The Typeterm is GDT 35824HO. The Type Name term is Product tax Type Code35825HO. The Cardinality between the TypeCode 35819HO and the GDTProductTax 35800HO is either zero or one 35826HO.

For the TypeDescription 35827HO, the Category is Element 35828HO. TheObject Class term is Product Tax 35829HO. The Property term is TypeDescription 35830HO. The Representation/Association term is Text35831HO. The Type term is GDT 35832HO. The Type Name term is Description35833HO. The Cardinality between the TypeDescription 35827HO and the GDTProductTax 35800HO is either zero or one 35834HO.

For the BaseAmount 35835HO, the Category is Element 35836HO. The ObjectClass term is Product Tax 35837HO. The Property term is Base Amount35838HO. The Representation/Association term is Amount 35839HO. The Typeterm is GDT 35840HO. The Type Name term is Amount 35841HO. TheCardinality between the BaseAmount 35835HO and the GDT ProductTax35800HO is either zero or one 35842HO.

For the Percent 35843HO, the Category is Element 35844HO. The ObjectClass term is Product Tax 35845HO. The Property term is Percent 35846HO.The Representation/Association term is Percent 35847HO. The Type term isGDT 35848HO. The Type Name term is Percent 35849HO. The Cardinalitybetween the Percent 35843HO and the GDT ProductTax 35800HO is eitherzero or one 35850HO.

For the Amount 35851HO, the Category is Element 35852HO. The ObjectClass term is Product Tax 35853HO. The Property term is Amount 35854HO.The Representation/Association term is Amount 35855HO. The Type term isGDT 35856HO. The Type Name term is Amount 35857HO. The Cardinalitybetween the Amount 35851HO and the GDT ProductTax 35800HO is either zeroor one 35858HO.

For the NonDeductiblePercent 35859HO, the Category is Element 35860HO.The Object Class term is Product Tax 35861HO. The Property term is NonDeductible Percent 35862HO. The Representation/Association term isDecimal 35863HO. The Type term is GDT 35864HO. The Type Name term isPercent 35865HO. The Cardinality between the NonDeductiblePercent35861HO and the GDT ProductTax 35800HO is either zero or one 35866HO.

For the NonDeductibleAmount 35867HO, the Category is Element 35868HO.The Object Class term is Product Tax 35869HO. The Property term is NonDeductible Amount 35870HO. The Representation/Association term is Amount35871HO. The Type term is GDT 35872HO. The Type Name term is Amount35873HO. The Cardinality between the Amount 35867HO and the GDTProductTax 35800HO is either zero or one 35874HO.

For the BusinessTransactionDocumentItemGroupID 35875HO, the Category isElement 35876HO. The Object Class term is Product Tax 35877HO. TheProperty term is Business Transaction Document Item Group Identification35878HO. The Representation/Association term is Identifier 35879HO. TheType term is GDT 35880HO. The Type Name term isBusinessTransactionDocumentItemGroupID 35881HO. The Cardinality betweenthe Amount 35875HO and the GDT ProductTax 35800HO is either zero or one35882HO.

For the TriangulationIndicator 35883HO, the Category is Element 35884HO.The Object Class term is Product Tax 35885HO. The Property term isTriangulation 35886HO. The Representation/Association term is Indicator35887HO. The Type term is CCT 35888HO. The Type Name term is Indicator35889HO. The Cardinality between the Amount 35883HO and the GDTProductTax 35800HO is either zero or one 35890HO.

For the LegallyRequiredPhrase 35891HO, the Category is Element 35892HO.The Object Class term is Product Tax 35893HO. The Property term isLegally Required Phrase 35894HO. The Representation/Association term isText 35895HO. The Type term is CCT 35896HO. The Type Name term is Text35897HO. The Cardinality between the Amount 35891HO and the GDTProductTax 35800HO is either zero or one 35899HO.

In this example, the following elements are used in the GDT ProductTax35800HO:

CountryCode—Country code (HMO 3166-1) defines the country in which thetax is incurred.

JurisdictionCode—used for some countries (in particular the US) toidentify the responsible tax authorities.

TypeCode—(tax code), see GDT ProductTaxTypeCode.

TypeDescription—short description of tax (e.g. for the tax code“OTH—Other taxes, unspecified, miscellaneous tax charges”).

BaseAmount—Base amount on which tax was calculated (assessment basis).

Percent—Tax rate, level of tax in percent.

Amount—Tax amount that is due for the underlying base amount.

NonDeductibleAmount—Percentage rate (portion) of tax that isnon-deductible.

NonDeductibleAmount—Amount of tax that is non-deductible.

BusinessTransactionDocumentItemGroupID—groups items of aBusinessTransactionDocument that are taxed in the same way. There is noglobal code list, the possible values are arbitrary and may be usedconsistently within a document (e.g., an invoice). The BTDItemGroupIDcan optionally be used to relate the taxes at item level to the summarytax lines at document level. The BTDItemGroupID assists during invoiceverification.

TriangulationIndicator—Yes/no indicator that specifies whether thetransaction is a triangular transaction.

LegallyRequiredPhrase—A legally required phrase that may be printed onthe invoice.

The segment “ProductTax” is always connected with an amount from whichthe base amount to be taxed is calculated. Exact rules on which taxesmay be reported in summary form or at item level are country-dependentand are derived from the relevant legal requirements. For example,German sales tax may be reported in an invoice in summarized form foreach tax rate. Non-deductible taxes are only relevant for incominginvoices and credit memos. When tax rate or tax amount is reported, thetax type (TypeCode) must also be specified.

The GDT ProductTax 35800HO can be used to report different tax portionsin invoice amounts or to initiate tax returns and payments of a companyto the responsible tax authorities. A tax is a mandatory public paymentthat a community levies on natural and legal persons in its territory ata unilaterally fixed level (unlike fees and contributions) withoutproviding a service in return.

The tax jurisdiction code of a natural or legal person is part of theaddress data. Tax calculation depends on the tax jurisdiction code ofthe ship-from or ship-to party in certain countries, e.g., the US,Brazil.

(jjjjjjjjjjjjjjjjj) ProductUsageCode

A GDT ProductUsageCode 35800HP is the coded representation of the usageof a product in a process. An example (instance) of the GDTProductUsageCode 35800HP is:

<ProductUsageCode>1</ProductUsageCode>

The structure of GDT ProductUsageCode 35800HP is depicted in FIG. 358HP.The GDT ProductUsageCode 35800HP includes attributes listID 35816HP,listAgencyID 35832HP, listVersionID 35846HP, listAgencySchemeID 35864HP,and listAgencySchemeAgencyID 35880HP. For the GDT ProductUsageCode35800HP, the Object Class term is Product 35802HP, the Property term isUsage 35804HP, the Representation/Association term is Code 35806HP, theType term is CCT 35808HP, the Type Name term is Code 35810HP, and theLength is either one or three 35812HP. The GDT ProductUsageCode 35800HPmay be restricted 35814HP.

For the listID 35816HP, the Category is Attribute 35818HP, the ObjectClass term is CodeList 35820HP, the Property term is Identification35822HP, the Representation/Association term is Identifier 35822HP, theType term is XSD 35826HP, and the Type Name term is token 35828HP. Thecardinality between the listID 35816HP and the GDT ProductUsageCode35800HP is either zero or one 35830HP.

For the listAgencyID 35832HP, the Category is Attribute 35834HP, theObject Class term is CodeListAgency 35836HP, the Property term isIdentification 35838HP, the Representation/Association term isIdentifier 35840HP, the Type term is XSD 35842HP, and the Type Name termis token 35844HP. The Cardinality between the listAgencyID 35832HP andthe GDT ProductUsageCode 35800HP is either zero or one 35846HP.

For the listVersionID 35848HP, the Category is Attribute 35850HP, theObject Class term is CodeList 35852HP, the Property term is Version35854HP, the Representation/Association term is Identifier 35856HP, theType term is XSD 35858HP, and the Type Name term is token 35860HP. Thecardinality between the listVersionID 35848HP and the GDTProductUsageCode 35800HP is either zero or one 35862HP.

For the listAgencySchemeID 35864HP, the Category is Attribute 35866HP,the Object Class term is CodeListAgency 35868HP, the Property term isScheme 35870HP, the Representation/Association term is Identifier35872HP, the Type term is XSD 35874HP, and the Type Name term is token35876HP. The cardinality between the listAgencySchemeID 35864HP and theGDT ProductUsageCode 35800HP is either zero or one 35878HP.

For the listAgencySchemeAgencyID 35880HP, the Category is Attribute35882HP, the Object Class term is CodeListAgency 35884HP, the Propertyterm is SchemeAgency 35886HP, the Representation/Association term isIdentifier 35888HP, the Type term is XSD 35890HP, and the Type Name termis token 35892HP. The cardinality between the listAgencySchemeAgencyID35880HP and the GDT ProductUsageCode 35800HP is either zero or one35894HP.

The GDT ProductUsageCode 35800HP is a customer-specific code. For eachadministering organization (agency) only one code list is allowed. Theattributes are used as follows:

listID—ID of the relevant code list. It is assigned and administered bya customer. The customer is responsible for the values of the ID inquestion.

listAgencyID—ID of the customer. An ID assigned by an organizationlisted in the DE 3055 may be used (such as the business IDs assigned byDUNS, EAN, and SWGZT).

listVersionID—Version of the relevant code list. It is assigned andadministered by the customer listed in the listAgencyID.

listAgencySchemeID—ID of the scheme by which the customer listed in thelistAgencyID is identified. It is a particular identification scheme forpartners, businesses, and members (such as DUNS+4), and so on, of anadministering organization (such as EAN, DUNS, and SWGZT) that is listedin the listAgencySche-meAgencyID.

listAgencySchemeAgencyID—ID of the administering organization (such asDUNS, EAN, or SWGZT) that is responsible for identifying theorganization listed in the listAgencyID. It has to be listed in DE 3055.

The GDT ProductUsageCode 35800HP can be used, for example, in salesorders, to define the usage for which a product is sold. Examples of thepossible semantics of the codes are:

Spare part—the product can be used as a spare part.

Sample—the product can be used as a sample.

Series product—the product can be used for repetitive manufacturing.

ProductWeights

A GDT ProductWeights 35800HQ specifies the gross, net and tare weight ofa product in a particular unit of measurement. An example of the GDTProductWeights 35800HQ is: <ProductWeights measureUnitCode=“KGM”>  <GrossWeightMeasure>10.3</GrossWeightMeasure>  <NetWeightMeasure>10.1</NetWeightMeasure>  <TareWeightMeasure>0.2</TareWeightMeasure> <ProductWeights>

The structure of GDT ProductWeights 35800HQ is depicted in FIG. 358HQ.The GDT ProductWeights 35800HQ includes an attribute MeasureUnitCode35808HQ, and elements GrowwWeightMeasure 35824HQ, NetWeightMeasure35840HQ, and TareWeightMeasure 35856HQ. For the GDT ProductWeights35800HQ, the Object Class term is Product Weight 35802HQ, the Propertyterm is Details 35804HQ, and the Representation/Association term isDetails 35806HQ.

For the MeasureUnitCode 35808HQ, the Category is Attribute 35810HQ. TheObject Class term is Product Weights 35812HQ. The Property term isMeasure Unit 35814HQ. The Representation/Association term is Code35816HQ. The Type term is GDT 35818HQ. The Type Name term isMeasureUnitCode 35820HQ. The Cardinality between the MeasureUnitCode35808HQ and the GDT ProductWeights 35800HQ is one 35822HQ.

For the GrossWeightMeasure 35824HQ, the Category is Element 35826HQ. TheObject Class term is Product Weight 35828HQ. The Property term is GrossWeight 35830HQ. The Representation/Association term is Measure 35832HQ.The Type term is GDT 35834HQ. The Type Name term is Measure 35836HQ. TheCardinality between the GrossWeightMeasure 35824HQ and the GDTProductWeights 35800HQ is either zero or one 35838HQ.

For the NetWeightMeasure 35840HQ, the Category is Element 35842HQ. TheObject Class term is Product Weight 35844HQ. The Property term is NetWeight 35846HQ. The Representation/Association term is Measure 35848HQ.The Type term is GDT 35850HQ. The Type Name term is Measure 35852HQ. TheCardinality between the NetWeightMeasure 35840HQ and the GDTProductWeights 35800HQ is either zero or one 35854HQ.

For the TareWeightMeasure 35856HQ, the Category is Element 35858HQ. TheObject Class term is Product Weight 35860HQ. The Property term is TareWeight 35862HQ. The Representation/Association term is Measure 35864HQ.The Type term is GDT 35866HQ. The Type Name term is Measure 35868HQ. TheCardinality between the TareWeightMeasure 35856HQ and the GDTProductWeights 35800HQ is either zero or one 35870HQ.

In some implementations, at least one weight in the GDT ProductWeights35800HQ may be specified. Depending on how the GDT ProductWeights35800HQ can be used, one of the weight details can be omitted since itcan be calculated using the other two weights. If all weights arespecified, then it may be according to the formula Gross Weight=NetWeight+Tare Weight. The plausibility of the weights can be checked inthe context of each application.

The GDT ProductWeights 35800HQ can be used to calculate the total weightof several products. In one example, the gross weight is important forselecting the method of transport since goods are normally transportedin their packaging. In another example, the net weight is important forthe maximum load bearing of a floor since the product is normallyinstalled without its packaging. For example, the packaging weight canbe specified instead of the gross weight, for example, to save weighingthe product once it is packed. The gross weight can then be calculatedfrom the specified packaging weight.

(kkkkkkkkkkkkkkkkkk) ProfitCentreTypeCode

The GDT ProfitCentreTypeCode 35800HR is the coded representation of thenature of a profit center. An example (instance) of the GDTProfitCentreTypeCode 35800HR is:

<ProfitCentreTypeCode>1</ProfitCentreTypeCode>

The structure of GDT ProfitCentreTypeCode 35800HR is depicted in FIG.358HR. For the GDT ProfitCentreTypeCode 35800HR, the Object Class termis Product Centre 35802HR, the Property term is Type 35804HR, theRepresentation/Association term is Code 35806HR, the Type term is CCT35808HR, the Type Name term is Code35810HR, and the Length is from oneto four 35812HR. The GDT ProfitCentreTypeCode 35800HR may be restricted35814HR.

The GDT ProfitCentreTypeCode 35800HR is a customer-specific code list.The GDT ProfitCentreTypeCode 35800HR is a fixed code list. Theattributes listID, listAgencyID, listVersionID, listAgencySchemeID,listAgencySchemeAgencyID are missing in the structure as they would befilled with constant, customer-specific values at run-time.

The GDT ProfitCentreTypeCode 35800HR makes it possible to define sets ofprofit centers on the basis of the value of the GDT ProfitCentreTypeCode35800HR. Reference can then be made to these sets in the assessment,overhead costing, or settlement, for example.

Some examples of possible code semantics are:

Production: The profit center has the nature of “Production”.

Sales and Distribution: The profit center has the nature of “Sales andDistribution”.

Research and Development: The profit center has the nature of “Researchand Development”.

(llllllllllllllllll) ProjectElementAssignment

The GDT ProjectElementAssignment 35800HS is the assignment between twoelements of a project. An example (instance) of the GDTProjectElementAssignment 35800HS is: <ProjectElementAssignment>  <FromProjectReference>     <ID>33FAEB7C03D0AF4CA09ECE33B3296C6D</ID><ElementID>548A8B7F39D8B618F40AB8154015D306</ElementID>    <ElementTypeCode>2</ElementTypeCode>   </FromReference>  <ToProjectReference>     <ID>33FAEB7C03D0AF4CA09ECE33B3296C6D</ID><ElementID>57F39D8B618F40AB8154015D306FF33A</ElementID>    <ElementTypeCode>1</ElementTypeCode>   </ToProjectReference></ProjectElementAssignment>

The structure of the GDT ProjectElementAssignment 35800HS is depicted inFIG. 358HS. The GDT ProjectElementAssignment 35800HS includes elementsFromProjectReference 35810HS and ToProjectReference 35826HS. For the GDTProjectElementAssignment 35800HS, the Object Class term is ProjectElement Assignment 35802HS, the Representation/Association term isDetails 35804HS, the Type term is GDT 35806HS, and the TypeName term isProjectElementAssignment 35808HS.

For the FromProjectReference 35810HS, the Category is Element 35812HS,the Object Class term is Project Element Assignment 35814HS, theProperty term is FromProjectReference 35816HS, theRepresentation/Association term is Details 35818HS, the Type term is GDT35820HS, and the TypeName term is ProjectReference 35822HS. TheCardinality between the FromProjectReference 35810HS and the GDTProjectElementAssignment 35800HS is one 35824HS.

For the ToProjectReference 35826HS, the Category is Element 35828HS, theObject Class term is Project Element Assignment 35830HS, the Propertyterm is ToProjectReference 35832HS, the Representation/Association termis Details 35834HS, the Type term is GDT 35836HS, and the TypeName termis ProjectReference 35838HS. The Cardinality between theToProjectReference 35826HS and the GDT ProjectElementAssignment 35800HSis one 35840HS.

The FromProjectReference 35810HS is a reference to the element in aproject from which another element is to be assigned. TheToProjectReference 35826HS is a reference to the element in a project towhich another element is to be assigned.

In some implementations, only assignments between elements of projectsare allowed, that is, FromProjectReference and ToProjectReference mustcontain references to elements in projects and not simply references toprojects as a whole.

For example, the FromProjectReference may be a role andToProjectReference may be a task in the same project—the task is assumedby the role (or more precisely, by a specific person who fills therole). A role can assume multiple tasks and a task can be performed bymultiple roles.

Generally, a ProjectElementAssignment can be used to assign two elementsof the same project to each other. The significance of the assignment isdependent on the type of the elements involved.

(mmmmmmmmmmmmmmmmmm) ProjectElementID

A GDT ProjectElementID 35800HT is a unique identifier for an element ina project. An element in a project is a component of the project of aspecific type, for example, a task or a role. An example (instance) ofthe GDT ProjectElementID 35800HT is:  <ProjectElementID>57F39D8B618F40AB8154015D306FF33A </ProjectElementID>

The structure of GDT ProjectElementID 35800HT is depicted in FIG. 358HT.The GDT ProjectElementID 35800HT includes attributes SchemeID 35814HT,SchemeAgencyID 35832HT, and schemeAgencySchemeAgencyID 35848HT. For theGDT ProjectElementID 35800HT, the Object Class term is Project Element35802HT, the Property term is Identification 35804HT, theRepresentation/Association term is Identifier 35804HT, the Type term isCCT 35806HT, the Type Name term is Identifier 35808HT, the TypeName termis Identifier 35010HT, and the Length is from one to thirty-two 35812HT.The GDT ProjectElementID 35800HT may be restricted 35814HT.

For the schemeID 35816HT, the Category is Attribute 35818HT, the ObjectClass term is IdentificationScheme 35820HT, the Property term isIdentification 35822HT, the Representation/Association term isIdentifier 35824HT, the Type term is XSD 35826HT, and the Type Name termis Token 35828HT, and the Length is from one to sixty 35830HT. Thecardinality between the schemeID 35816HT and the GDT ProjectElementID35800HT is either zero or one 35832HT.

For the schemeAgencyID 35834HT, the Category is Attribute 35836HT, theObject Class term is IdentificationSchemeAgency 35838HT, the Propertyterm is Identification 35840HT, the Representation/Association term isIdentifier 35842HT, the Type term is XSD 35844HT, and the Type Name termis Token 35846HT, and the Length is from one to sixty 35848HT. Thecardinality between the schemeAgencyID 35834HT and the GDTProjectElementID 35800HT is either zero or one 35850HT.

For the schemeAgencySchemeAgencyID 35852HT, the Category is Attribute35854HT, the Object Class term is IdentificationSchemeAgency 35856HT,the Property term is Scheme Agency 35858HT, theRepresentation/Association term is Identifier 35860HT, the Type term isXSD 35862HT, and the Type Name term is Token 35864HT, and the Length isfrom one to three 35848HT. The cardinality between theschemeAgencySchemeAgencyID 35852HT and the GDT ProjectElementID 35800HTis either zero or one 35850HT.

The GDT ProjectElementID 35800HT may consist of a character sequencewith a maximum of 32 characters, taking into account the restrictionsdefined in XSD. The attributes of a ProjectElementID are filled asfollows:

schemeID:

ProjectElementID—Identification by means of an identifier

ProjectElementGUID—Identification by means of a Global Unique Identifier

schemeAgencyID: Business system in which the identifier has beenassigned

schemeAgencySchemeAgencyID: mutually defined

The ID in the context of these attribute values may be unique togetherwith the related ProjectID.

The GDT ProjectElementID 35800HT can be used in order to uniquelyidentify an element in a project in a business process. In a firststep—for example, on creation or first transfer of data on a businesstransaction—one partner uses a ProjectElementID to inform the otherpartner of his identification for an element in a project. The secondpartner can use this identifier in the follow-on process to referencethe element.

(nnnnnnnnnnnnnnnnnn) ProjectElementTypeCode

A GDT ProjectElementTypeCode 35800HU is the coded representation of thetype of an element in a project. The element type describes the natureof elements in projects according to their business significance. Anexample (instance) of the GDT ProjectElementTypeCode 35800HU is:

<ProjectElementTypeCode>1</ProjectElementTypeCode>

The structure of GDT ProjectElementTypeCode 35800HU is depicted in FIG.358HU. For the ProjectElementTypeCode 35800HU, the Object Class term isProject Element 35802HU, the Property term is Type 35804HU, theRepresentation/Association term is Code 35806HU, the Type term is CCT35808HU, the Type Name term is Code 35810HU, and the Length is from oneto three 35812HU. The GDT ProjectElementTypeCode 35800HU may berestricted 35814HU.

In one example, the GDT ProjectElementTypeCode 35800HU can be used todescribe the type of an element in a project that is identified by meansof a ProjectElementID. In some implementations, the GDTProjectElementTypeCode 35800HU is an SAP-proprietary code list withfixed predefined attributes. Changes to the permitted attributes resultin interface changes.

(oooooooooooooooooo) ProjectID

The GDT ProjectID 35800HV is a unique identifier for a project. Aproject is a business plan with a defined objective that is to beachieved with predefined financial means, with the planned resources, atan agreed quality level, and by an agreed time. The project ischaracterized by its uniqueness, its risk character and itsorganizational significance. An example (instance) of the GDT ProjectID35800HV is:   <ProjectID schemeID=”ProjectGUID” schemeAgencyID=”SYS_010“ schemeAgencySchemeAgencyID=”ZZZ“>33FAEB7C03D0AF4CA09ECE33B3296C6D</ProjectID>

The structure of GDT ProjectID 35800HV is depicted in FIG. 358HV. TheGDT ProjectID 35800HV includes attributes SchemeID 35814HV,SchemeAgencyID 35832HV, and schemeAgencySchemeAgencyID 35848HV. For theGDT ProjectID 35800HV, the Object Class term is Project 35802HV, theProperty term is Identification 35804HV, the Representation/Associationterm is Identifier 35804HV, the Type term is CCT 35806HV, the Type Nameterm is Identifier 35808HV, the TypeName term is Identifier 35010HV, andthe Length is from one to thirty-two 35812HV. The GDT ProjectID 35800HVmay be restricted 35814HV.

For the schemeID 35816HV, the Category is Attribute 35818HV, the ObjectClass term is IdentificationScheme 35820HV, the Property term isIdentification 35822HV, the Representation/Association term isIdentifier 35824HV, the Type term is XSD 35826HV, and the Type Name termis Token 35828HV, and the Length is from one to sixty 35830HV. Thecardinality between the schemeID 35816HV and the GDT ProjectID 35800HVis either zero or one 35832HV.

For the schemeAgencyID 35834HV, the Category is Attribute 35836HV, theObject Class term is IdentificationSchemeAgency 35838HV, the Propertyterm is Identification 35840HV, the Representation/Association term isIdentifier 35842HV, the Type term is XSD 35844HV, and the Type Name termis Token 35846HV, and the Length is from one to sixty 35848HV. Thecardinality between the schemeAgencyID 35834HV and the GDT ProjectID35800HV is either zero or one 35850HV.

For the schemeAgencySchemeAgencyID 35852HV, the Category is Attribute35854HV, the Object Class term is IdentificationSchemeAgency 35856HV,the Property term is Scheme Agency 35858HV, theRepresentation/Association term is Identifier 35860HV, the Type term isXSD 35862HV, and the Type Name term is Token 35864HV, and the Length isfrom one to three 35848HV. The cardinality between theschemeAgencySchemeAgencyID 35852HV and the GDT ProjectID 35800HV iseither zero or one 35850HV.

The GDT ProjectID 35800HV may consist of a character sequence with amaximum of 32 characters, taking into account the restrictions definedin XSD. References to projects are to be stored in applications as32-character sequences.

The attributes of a ProjectID are filled as follows:

schemeID: Present fix “ProjectGUID”, further allowed values can besupplemented in future.

schemeAgencyID: Business system in which the identifier has beenassigned

schemeAgencySchemeAgencyID: mutually defined

In the context of these attribute values, the ID may be unique.

The GDT ProjectID 35800HV can be used in order to uniquely identify aproject in a business process. In a first step—for example, on creationor first transfer of data on a business transaction—one partner uses aProjectID to inform the other partner of his identification for aproject. The second partner can use this identifier in the follow-onprocess to reference the project.

(pppppppppppppppppp) ProjectReference

A GDT ProjectReference 35800HW is a unique reference to a project or toan element within a project. An example (instance) of the GDTProjectReference 35800HW is: <ProjectReference>  <ProjectID>33FAEB7C03D0AF4CA09ECE33B3296C6D</   ProjectID>  <ProjectElementID>57F39D8B618F40AB8154015D306FF33A  </ProjectElementID>  <ProjectElementTypeCode>1</ProjectElementTypeCode> </ProjectReference>

The structure of GDT ProjectReference 35800HW is depicted in FIG. 358HW.The GDT ProjectReference 35800HW includes elements ProjectID 35806HW,ProjectElementID 35822HW, ProjectElementTypeCode 35838HW. For the GDTProjectReference 35800HW, the Object Class term is Project Reference35802HW. The Representation/Association term is Details 35804HW.

For the ProjectID 35806HW, the Category is Element 35808HW, the ObjectClass term is Project Reference 35810HW, the Property term isIdentification 35812HW, the Representation/Association term isIdentification 35812HW, the Type term is GDT 35814HW, and the Type Nameterm is ProjectID 35818HW. The Cardinality between the ProjectID 35806HWand the GDT ProjectReference 35800HW is either zero or one 35820HW.

For the ProjectElementID 35822HW, the Category is Element 35824HW, theObject Class term is Project Reference 35826HW, the Property term isIdentification 35828HW, the Representation/Association term is ElementIdentification 35830HW, the Type term is GDT 35832HW, and the Type Nameterm is ProjectElementID 35834HW. The Cardinality between theProjectElementID 35806HW and the GDT ProjectReference 35800HW is eitherzero or one 35836HW.

For the ProjectElementTypeCode 35838HW, the Category is Element 35840HW,the Object Class term is Project Reference 35842HW, the Property term isElement Type Code 35844HW, the Representation/Association term is Code35846HW, the Type term is GDT 35848HW, and the Type Name term isProjectElementTypeCode 35850HW. The Cardinality between the ProjectID35806HW and the GDT ProjectReference 35800HW is either zero or one35852HW.

In some implementations, a ProjectID is an ID of the referenced project,a ProjectElementID is an ID of an element within the referenced project,and a ProjectElementTypeCode is a Type of the element identified viaProjectElementID.

For referencing an element in a project, the ProjectID, theProjectElementID and the ProjectElementTypeCode should be filled. If theProjectElementID is clear even without specifying theProjectElementTypeCode in a project, then it is sufficient to fill onlythe ProjectID and the ProjectElementID. If the ProjectElementID is cleareven without specifying the related project, then it is sufficient tofill only the ProjectElementID (and the ProjectElementTypeCode ifrequired).

(qqqqqqqqqqqqqqqqqq) Rate

A GDT Rate 35800HX is a fraction whose numerator and denominator arequantities, values, or dimensionless factors, independently from eachother. An example (instance) of the GDT Rate 35800HX is: <DiscountRate>  <DecimalValue>−29.99</DecimalValue>   <CurrencyCode>EUR</CurrencyCode>  <BaseMeasureUnitCode>C62</BaseMeasureUnitCode> </DiscountRate>

The structure of GDT Rate 35800HX is depicted in FIG. 358HX. The GDTRate 35800HX includes elements DecimalValue 35806HX, MeasureUnitCode35822HX, CurrencyCode 35840HX, BaseDecimalValue 35858HX,BaseMeasureUnitCode 35878HX, and BaseCurrencyCode 35891HX. For the GDTRate 35800HX, the Object Class term is Rate 35802HX, and theRepresentation/Association term is Details 35804HX.

For the DecimalValue 35806HX, the Category is Element 35808HX, theObject Class term is Rate 35810HX, the Property term is Decimal Value35812HX, the Representation/Association term is Value 35814HX, the Typeterm is GDT 35816HX, and the Type Name term is Decimal Value 35818HX.The Cardinality between the DecimalValue 35806HX and the GDT Rate35800HX is one 35820HX.

For the MeasureUnitCode 35822HX, the Category is Element 35824HX, theObject Class term is Rate 35826HX, the Property term is Measure Unit35828HX, the Representation/Association term is Code 35830HX, the Typeterm is GDT 35832HX, the Type Name term is Measure Unit Code 35834HX,and the Length is from one to three 35836HX. The Cardinality between theMeasureUnitCode 35822HX and the GDT Rate 35800HX is either zero or one35838HX.

For the CurrencyCode 35840HX, the Category is Element 35842HX, theObject Class term is Rate 35844HX, the Property term is Currency35846HX, the Representation/Association term is Code 35848HX, the Typeterm is GDT 35850HX, the Type Name term is Currency Code 35852HX, andthe Length is three 35854HX. The Cardinality between the CurrencyCode35840HX and the GDT Rate 35800HX is either zero or one 35856HX.

For the BaseDecimalValue 35858HX, the Category is Element 35860HX, theObject Class term is Rate 35862HX, the Property term is Base DecimalValue 35864HX, the Representation/Association term is Value 35866HX, theType term is GDT 35868HX, and the Type Name term is Decimal Value35870HX. The Cardinality between the BaseDecimalValue 35858HX and theGDT Rate 35800HX is either zero or one 35874HX. The default value of theBaseDecimalValue 35858HX is one 35876HX.

For the BaseMeasureUnitCode 35878HX, the Category is Element 35880HX,the Object Class term is Rate 35882HX, the Property term is Base MeasureUnit 35884HX, the Representation/Association term is Code 35886HX, theType term is GDT 35887HX, the Type Name term is Measure Unit Code35888HX, and the Length is from one to three 35889HX. The Cardinalitybetween the BaseMeasureUnitCode 35878HX and the GDT Rate 35800HX iseither zero or one 35890HX.

For the BaseCurrencyCode 35891HX, the Category is Element 35892HX, theObject Class term is Rate 35893HX, the Property term is Base Currency35894HX, the Representation/Association term is Code 35895HX, the Typeterm is GDT 35896HX, the Type Name term is Currency Code 35897HX, andthe Length is three 35898HX. The Cardinality between theBaseCurrencyCode 35891HX and the GDT Rate 35800HX is either zero or one35899HX.

The GDT Rate 35800HX has the following elements:

DecimalValue is the numerical value of the rate, or the numerical valueof the numerator of the rate.

MeasureUnitCode is the coded representation of the unit of measure ofthe numerator according to the UN/ECE Recommendation #20.

CurrencyCode is the coded representation of the currency unit of thenumerator according to the triple-character code used in HMO 4217.

BaseDecimalValue is the numerical value of the denominator of the rate.The default value is “1” if the element is omitted.

BaseMeasureUnitCode is the coded representation of the unit of measureof the denominator according to the UN/ECE Recommendation #20.

BaseCurrencyCode is the coded representation of the currency unit of thedenominator according to the triple-character code used in HMO 4217.

In some implementations, the GDT Rate 35800HX may include some or all ofthe following constraints. At the most, only one of the elementsMeasureUnitCode and CurrencyCode may be specified. At the most, only oneof the elements BaseMeasureUnitCode and BaseCurrencyCode may bespecified. The element BaseDecimalValue only has to be specified if thevalue of the denominator is not equal to The GDT Rate 35800HX specifiesa rate between two factors with specific units of measure, for example,the daily turnover of a business.

Special cases of the GDT Rate 35800 jD should be depicted with thecorresponding GDTs, for example:

Percentages according to a GDT Percent

Amounts according to a GDT Amount

Quantities according to a GDT Quantity

Exchange rates according to a GDT ExchangeRate

However, if the GDT Rate 35800HX can be used, there may be anappropriate business reason in the particular context.

For a purely numerical ratio where the numerator and the denominator areused without units of measure, the GDT Ratio should be used inaccordance with UN/CEFACT CCTS V.2.01.

(rrrrrrrrrrrrrrrrrr) RebateProductGroupCode

A GDT RebateProductGroupCode 35800HY is the coded representation of agroup of products for which a certain rebate applies. A rebate is paidout to the customer retroactively. An example (instance) of the GDTRebateProductGroupCode 35800HY is:

<RebateProductGroupCode>1</RebateProductGroupCode>

The structure of GDT RebateProductGroupCode 35800HY is depicted in FIG.358HY. The GDT RebateProductGroupCode 35800HY includes attributes listID35814HY, listAgencyID 35830HY, listVersionID 35846HY, listAgencySchemeID35862HY, and listAgencySchemeAgencyID 35878HY. For the GDTRebateProductGroupCode 35800HY, the Object Class Qualifier term is Price35802HY, the Object Class term is Product Group 35804HY, theRepresentation/Association Term is Code 35806HY, the Type term is CCT35808GZ, and the Type Name term is Code 35810HY, and the Length iseither one or two 35812HY.

For the listID 35814HY, the Category is Attribute 35816HY, the ObjectClass term is CodeList 35818HY, the Property term is Identification35820HY, the Representation/Association term is Identifier 35822HY, theType term is XSD 35824HY, and the Type Name term is token 35826HY. Thecardinality between the listID 35814HY and the GDTRebateProductGroupCode 35800HY is either zero or one 35828HY.

For the listAgencyID 35830HY, the Category is Attribute 35832HY, theObject Class term is CodeListAgency 35834HY, the Property term isIdentification 35836HY, the Representation/Association term isIdentifier 35838HY, the Type term is XSD 35840HY, and the Type Name termis token 35842HY. The cardinality between the listAgencyID 35830HY andthe GDT RebateProductGroupCode 35800HY is either zero or one 35844HY.

For the listVersionID 35846HY, the Category is Attribute 35848HY, theObject Class term is CodeList 35850HY, the Property term is Version35852HY, the Representation/Association term is Identifier 35854HY, theType term is XSD 35856HY, and the Type Name term is token 35858HY. Thecardinality between the listVersionID 35846HY and the GDTRebateProductGroupCode 35800HY is either zero or one 35860HY.

For the listAgencySchemeID 35862HY, the Category is Attribute 35864HY,the Object Class term is CodeListAgency 35866HY, the Property term isScheme 35868HY, the Representation/Association term is Identifier35870HY, the Type term is XSD 35872HY, and the Type Name term is token35874HY. The cardinality between the listAgencySchemeID 35862HY and theGDT RebateProductGroupCode 35800HY is either zero or one 35876HY.

For the listAgencySchemeAgencyID 35878HY, the Category is Attribute35880HY, the Object Class term is CodeListAgency 35882HY, the Propertyterm is SchemeAgency 35884HY, the Representation/Association term isIdentifier 35886HY, the Type term is XSD 35888HY, and the Type Name termis token 35890HY. The cardinality between the listAgencySchemeAgencyID35878HY and the GDT RebateProductGroupCode 35800HY is either zero or one35892HY.

The GDT RebateProductGroupCode 35800HY is a customer-specific code. Foreach administering organization (agency) only one code list is allowed.The attributes are used as follows:

listID—ID of the relevant code list. It is assigned and administered bya customer. The customer is responsible for the values of the ID inquestion.

listAgencyID—ID of the customer. An ID assigned by an organizationlisted in the DE 3055 may be used (such as the business IDs assigned byDUNS, EAN, and SWGZT).

listVersionID—Version of the relevant code list. It is assigned andadministered by the customer listed in the listAgencyID.

listAgencySchemeID—ID of the scheme by which the customer listed in thelistAgencyID is identified. It is a particular identification scheme forpartners, businesses, and members (such as DUNS+4), and so on, of anadministering organization (such as EAN, DUNS, and SWGZT) that is listedin the listAgencySche-meAgencyID.

listAgencySchemeAgencyID—ID of the administering organization (such asDUNS, EAN, or SWGZT) that is responsible for identifying theorganization listed in the listAgencyID. It has to be listed in DE 3055.

The GDT RebateProductGroupCode 35800HY can be used, for example, insales and billing documents, to group products and to determine pricesthat apply in the rebate agreement. Examples of the possible semanticsof the codes are:

Maximum rebate—products for which a maximum rebate applies

Minimum rebate—products for which a minimum rebate applies

For example, the following dictionary objects can be assigned to thisGDT in mySAP CRM:

Data element: CRMT_REBATE_GROUP

Domain: CRM_REBATE_GROUP

ReferenceInterestCurveCode

A GDT ReferenceInterestCurveCode 35800HZ is the coded representation ofthe description of a reference interest curve. The reference interestcurve serves as a guideline for the amount when determining whichcontractual interest rate is to be used for financial transactions. Anexample (instance) of the GDT ReferenceInterestCurveCode 35800HZ is:

<ReferenceInterestCurveCode listID=“221”listAgencyID=“17”>LIBO</ReferenceInterestCurveCode>

where listID=“221” means Swift Codeliste 221, listAgencyID=“17” meansS.W.I.F.T., which is Society for Worldwide Interbank FinancialTelecommunications s.c., LIBO is a reference interest curve LIBOR.

The structure of GDT ReferenceInterestCurveCode 35800HZ is depicted inFIG. 358HZ. The GDT ReferenceInterestCurveCode 35800HZ includesattributes listID 35814HZ, listAgencyID 35832HZ, listVersionID 35850HZ,listAgencySchemeID 35868HZ, and listAgencySchemeAgencyID 35886HZ. Forthe GDT ReferenceInterestCurveCode 35800HZ, the Object Class term isReference Interest 35802HZ, the Representation/Association Term is Code35804HZ, the Type term is CCT 35806HZ, the Type Name term is Code35808HZ, and the Length is from one to ten 35810HZ. The GDTReferenceInterestCurveCode 35800HZ may be restricted.

For the listID 35814HZ, the Category is Attribute 35816HZ, the ObjectClass term is CodeList 35818HZ, the Property term is Identification35820HZ, the Representation/Association term is Identifier 35822HZ, theType term is XSD 35824HZ, and the Type Name term is token 35826HZ, andthe Length is from one to sixty 35828HZ. The cardinality between thelistID 35814HZ and the GDT ReferenceInterestCurveCode 35800HZ is eitherzero or one 35830HZ.

For the listAgencyID 35832HZ, the Category is Attribute 35834HZ, theObject Class term is CodeListAgency 35836HZ, the Property term isIdentification 35838HZ, the Representation/Association term isIdentifier 35840HZ, the Type term is XSD 35842HZ, the Type Name term istoken 35844HZ, and the Length is from one to sixty 35846HZ. TheCardinality between the listAgencyID 35836HZ and the GDTReferenceInterestCurveCode 35800HZ is either zero or one 35848HZ.

For the listVersionID 35850HZ, the Category is Attribute 35852HZ, theObject Class term is CodeList 35854HZ, the Property term is Version35856HZ, the Representation/Association term is Identifier 35858HZ, theType term is XSD 35860HZ, the Type Name term is token 35862HZ, and theLength is from one to fifteen 35864HZ. The cardinality between thelistVersionID 35850HZ and the GDT ReferenceInterestCurveCode 35800HZ iseither zero or one 35866HZ.

For the listAgencySchemeID 35868HZ, the Category is Attribute 35870HZ,the Object Class term is CodeListAgency 35872HZ, the Property term isScheme 35874HZ, the Representation/Association term is Identifier35876HZ, the Type term is XSD 35878HZ, the Type Name term is token35880HZ, and the Length is from one to sixty 35882HZ. The cardinalitybetween the listAgencySchemeID 35868HZ and the GDTReferenceInterestCurveCode 35800HZ is either zero or one 35884HZ.

For the listAgencySchemeAgencyID 35886HZ, the Category is Attribute35888HZ, the Object Class term is CodeListAgency 35890HZ, the Propertyterm is SchemeAgency 35892HZ, the Representation/Association term isIdentifier 35894HZ, the Type term is XSD 35896HZ, the Type Name term istoken 35897HZ, and the Length is from one to three 35898HZ. Thecardinality between the listAgencySchemeAgencyID 35878HZ and the GDTReferenceInterestCurveCode 35800HZ is either zero or one 35892HZ.

(ssssssssssssssssss) ScaleAxisBaseCode

A GDT ScaleAxisBaseCode 35800IA is the coded representation of the scalebase type for a scale axis. An example (instance) of theScaleAxisBaseCode 35800IA is:

<BaseCode>3</BaseCode>

The structure of GDT ScaleAxisBaseCode 35800IA is depicted in FIG.358IA. For the GDT ScaleAxisBaseCode 35800IA, the Object Class term isScale Axis 35802IA, the Property term is Base 35804IA, theRepresentation/Association term is Code 35806IA, the Type term is CCT35808IA, the TypeName term is Code 35810A, and the Length is from one tothree 35812IA. The GDT ScaleAxisBaseCode 35800IA may be restricted35814IA.

The possible values for the GDT: ScaleAxisBaseCode are: Code NameMeaning 1 Quantity Item quantity in a document 2 Shipping quantity Itemshipping quantity 3 Net value Net value: Price including discounts andsurcharges, as well as freight, but before tax 4 Gross weight Item grossweight 5 Net weight Item net weight 6 Volume Item volume 7 Number ofpoints Non-dimensional number of points of an item 8 Distance Distance,for example, between ship-to party and plant 9 Time stamp UTC time stamp10 Year Number of years 11 Month Number of months 12 Week Number ofweeks 13 Day Number of days

The GDT ScaleAxisBaseCode 35800IA is a proprietary code list with fixedpredefined values. Changes to the permitted values involve changes tothe interface.

(tttttttttttttttttt) ScaleAxisStepIntervalBoundaryTypeCode

A GDT ScaleAxisStepIntervalBoundaryTypeCode 35800IB is the codedrepresentation of the typing of an interval boundary that is defined fora scale axis step. Scale axis steps are represented by discrete scaledimension values. An example (instance) of the GDTScaleAxisStepIntervalBoundaryTypeCode 35800IB is:

<ScaleAxisStepIntervalBoundaryTypeCode>2</ScaleAxisStepIntervalBoundaryTypeCode>

The structure of GDT ScaleAxisStepIntervalBoundaryTypeCode 35800IB isdepicted in FIG. 358IB. For the GDTScaleAxisStepIntervalBoundaryTypeCode 35800IB, the Object Class term isScale Axis Step 35802IB, the Property term is Interval Boundary TypeCode 35804IB, the Representation/Association term is Code 35806IB, theType term is CCT 35808IB, the TypeName term is Code 35810IB, and theLength is from one 35812IB. The GDTScaleAxisStepIntervalBoundaryTypeCode 35800IB may be restricted 35814IB.

An element of the GDT ScaleAxisStepIntervalBoundaryTypeCode 35800IB canrepresent the lower limit of an interval (e.g., from a respective scaledimension value up to, but excluding the next higher scale dimensionvalue), or the GDT ScaleAxisStepIntervalBoundaryTypeCode 35800IB canalso represent the upper limit of an interval (e.g., up to a respectivescale dimension value, from but excluding the next lowest scaledimension value).

The meaning of scale dimension values, determined via the GDTScaleAxisStepIntervalBoundaryCode 35800IB is described within thecontext of pricing scales as a “scale dimension type”, though additionalconstraints apply there so that scale dimension values all have the sameGDT ScaleAxisStepIntervalBoundaryTypeCode 35800IB. A scale dimension canbe used to determine the domain of a one-dimensional pricing scale. Inthis context, the values of scale dimensions are described as scalesteps. A pricing scale defines a scale rate (for example, net price,discount, and so on) for each scale step. Consequently, a pricing scalecomprises the scale levels as input values and the scale rates definedfor the steps as “output values”. Output values of the pricing scale areaccessed using the scale step(s) to determine conditions in the contextof pricing, depending on values, such as the order quantity.

A scale level and scale dimension type both determine for which intervalthe scale rate applies:

From the current scale step, up to, but not including the next higherstep.

To the current scale step, from, but not including the next lower step.

In the first case, the pricing scale is known as the “from” pricingscale, in the second case, it is known as the “to” pricing scale. Frompricing scales may explicitly have a minimal pricing scale. To pricingscales may have a maximal pricing scale.

The scale steps of a pricing scale are always defined in terms of apricing scale base type. The scale steps for the scale base typesquantity, gross value, and number are scale quantity with scale quantityunit, scale rate with scale currency and scale quantity without unitrespectively. The scale steps are divided into the scale dimensions fora pricing scale or the dimension of the pricing scale represented by it.The scale dimension type is valid for all scale steps of a pricingscale, which is the different scale steps of a one-dimensional pricingscale are always interpreted in the same way as interval boundaries.

The scale steps of a pricing scale always imply disconnected andconsuming intervals. For every characteristic value of the input value,exactly one scale step (and therefore the interval implied) is relevantfor determining the scale rate when using scale dimension types “lowerboundary” and “upper boundary”.

The same concepts as for pricing conditions are used for scales, forfree goods and for rebate conditions, that is the GDTScaleAxisStepIntervalBoundaryTypeCode 35800IB can also be used for thesescales.

(uuuuuuuuuuuuuuuuuu) ServiceWorkingConditionsCode

A GDT ServiceWorkingConditionsCode 35800IC is the coded representationof working conditions under which a service is carried out. For example,a service can be carried out at certain working times (for example, atweekends, during public holidays, at night, etc.), or under difficultcircumstances (for example, bonus for dirty work). An example of the GDTServiceWorkingConditionsCode 35800IC is:

<ServiceWorkingConditionsCode>1</ServiceWorkingConditionsCode>

The structure of GDT ServiceWorkingConditionsCode 35800IC is depicted inFIG. 358IC. The GDT S ServiceWorkingConditionsCode 35800IC includesattributes listID 35816IC, listAgencyID 35832IC, listVersionID 35846IC,listAgencySchemeID 35864IC, and listAgencySchemeAgencyID 35880IC. Forthe GDT ProductUsageCode 35800IC, the Object Class term is Service35802IC, the Property term is Working Conditions 35804IC, theRepresentation/Association term is Code 35806IC, the Type term is CCT35808IC, the Type Name term is Code 35810IC, and the Length is from oneto four 35812IC. The GDT ProductUsageCode 35800IC may be restricted35814IC.

For the listID 35816IC, the Category is Attribute 35818IC, the ObjectClass term is CodeList 35820IC, the Property term is Identification35822IC, the Representation/Association term is Identifier 35822IC, theType term is XSD 35826IC, and the Type Name term is token 35828IC. Thecardinality between the listID 35816IC and the GDTServiceWorkingConditionsCode 35800IC is either zero or one 35830IC.

For the listAgencyID 35832IC, the Category is Attribute 35834IC, theObject Class term is CodeListAgency 35836IC, the Property term isIdentification 35838IC, the Representation/Association term isIdentifier 35840IC, the Type term is XSD 35842IC, and the Type Name termis token 35844IC. The Cardinality between the listAgencyID 35832IC andthe GDT ServiceWorkingConditionsCode 35800IC is either zero or one35846IC.

For the listVersionID 35848IC, the Category is Attribute 35850IC, theObject Class term is CodeList 35852IC, the Property term is Version35854IC, the Representation/Association term is Identifier 35856IC, theType term is XSD 35858IC, and the Type Name term is token 35860IC. Thecardinality between the listVersionID 35848IC and the GDTServiceWorkingConditionsCode 35800IC is either zero or one 35862IC.

For the listAgencySchemeID 35864IC, the Category is Attribute 35866IC,the Object Class term is CodeListAgency 35868IC, the Property term isScheme 35870IC, the Representation/Association term is Identifier35872IC, the Type term is XSD 35874IC, and the Type Name term is token35876IC. The cardinality between the listAgencySchemeID 35864IC and theGDT ServiceWorkingConditionsCode 35800IC is either zero or one 35878IC.

For the listAgencySchemeAgencyID 35880IC, the Category is Attribute35882IC, the Object Class term is CodeListAgency 35884IC, the Propertyterm is SchemeAgency 35886IC, the Representation/Association term isIdentifier 35888IC, the Type term is XSD 35890IC, and the Type Name termis token 35892IC. The cardinality between the listAgencySchemeAgencyID35880IC and the GDT ServiceWorkingConditionsCode 35800IC is either zeroor one 35894IC.

There are only alternative code lists that differ at configurationand/or runtime. The GDT ServiceWorkingConditionsCode 35800IC is acustomer-specific code list. Examples of the possible semantics of thecodes can be found under the heading “Use”. The attributes are used asfollows:

listID is “10137”

listAgencyID—The ID of the customer. An ID assigned by an organizationlisted in the DE 3055 may be used (such as the business IDs assigned byDUNS, EAN and SWGZT).

listVersionID—Version of the relevant code list. It is assigned andadministered by the customer listed in the listAgencyID.

listAgencySchemeID—ID of the scheme by which the customer listed in thelistAgencyID is identified. It is a particular identification scheme forpartners, businesses, and members (such as DUNS+4, and so on), of anadministering organization (such as EAN, DUNS, and SWGZT) that is listedin the listAgencySche-meAgencyID.

listAgencySchemeAgencyID—the ID of the administering organization (suchas DUNS, EAN, or SWGZT) that is responsible for identifying theorganization listed in the ListAgencyID. It has to be listed in DE 3055.

The GDT ServiceWorkingConditionsCode 35800IC can be used for pricing, inorder to calculate surcharges or discounts for the customer. Thesurcharges and discounts can be an absolute or a percentage value. Forexample, if a service with a base price of 100 Euro has to be carriedout on a public holiday, a surcharge of 50% can be defined for thisservice. In this case, a total price of 150 Euro can be charged to thecustomer. In one example, a weekend is the service should be carried outon the weekend, or has already been carried out on the weekend. Inanother example, a public holiday is the service should be carried outon a public holiday, or has already been carried out on a publicholiday.

(vvvvvvvvvvvvvvvvvv) PaidByCompanyIndicator

A GDT PaidByCompanyIndicator specifies whether something was paid by thecompany or not.

(wwwwwwwwwwwwwwwwww) PaymentTransactionDescription

A GDT PaymentTransactionDescription is a description of a payment card.For example, operation specifies a course of action to be carried out bya resource or group of resources. For the GDTPaymentTransactionDescription, the Type is MEDUIM_Description.

(xxxxxxxxxxxxxxxxxx) ReasonDescription

A GDT ReasonDescription 35800 is a description of a reason. For the GDTReasonDescription, the Type is MEDIUM_Description.

(yyyyyyyyyyyyyyyyyy) ReceiptDescription

A GDT ReceiptDescription is a description of a receipt. For the GDTReceiptDescription, the Type is MEDIUM_Description.

(zzzzzzzzzzzzzzzzzz) ReconciliationPeriodCounterValue

A GDT ReconciliationPeriodCounterValue is a number of reconciliationperiods. For example, a reconciliation period is the time span betweentwo successive reconciliation messages of the same sequence context. Areconciliation message creates a common synchronization point between asender and a receiver. To achieve this, the sender sends the receiver acurrent copy of the business object instance affected. This copycontains all data relevant for the receiver. A sequence context isdefined by the receiver instance and the union of all nodes of abusiness object instance that are sent to this receiver instance forreconciliation purposes.

The GDT ReconciliationPeriodCounterValue is a counter value with aminimum value of 1. If the GDT ReconciliationPeriodCounterValue is usedas an element of a GDT (or a message), it may only occur once in thecomplete substructure of the element.

The GDT ReconciliationPeriodCounterValue is used when reconciliationmessages are the means for ensuring restartability. The reconciliationperiod refers to exactly one sequence context. This sequence contextspans all those nodes of a business object instance that are sent to thesame receiver instance using reconciliation messages. For a givenreceiver instance, every node of a business object instance belongs toone sequence context at most. Thus for a given receiver instance, everynode also belongs to at most one reconciliation period. The countervalue of the first reconciliation period is 1; every reconciliationmessage increases it by 1. In every message containing information froma node of a particular sequence context, the receiver must be able todetermine uniquely the corresponding reconciliation period. This isachieved with the following rule: if an element of a message containsthe GDT ReconciliationPeriodCounterValue as child element, this countervalue denotes the reconciliation period of all business object nodescontained in the substructure of this element.

An example of GDT ReconciliationPeriodCounterValue is:  <ProductionProgressMessage>     ...     <ProductionProgress>      <ID>4711</ID>       <ProductionRequestFulfillment>        <ReconciliationCounterValue >2</ReconciliationCounterValue >        <ProductionRequestID>0815</ ProductionRequestID>        <ProductionOperation>         ...         </ProductionOperation>      </ProductionRequestFulfillment>       <InventoryChangeItem>        <ID>77432</ID>         <Outbound>          <ReconciliationCounterValue >87451</ReconciliationCounterValue >          <Location>             <InternalID>1000CWM</InternalID>          </Location>           <Product>            <IternalID>100-100</InternalID>           </Product>          <Quantity>20</Quantity>         </Outbound>        <ID>77432</ID>         <Inbound>          <ReconciliationCounterValue >2327</ReconciliationCounterValue >          ...           <Quantity>5</Quantity>         </Inbound>      </InventoryChangeItem>     </ProductionProgress>  </ProductionProgressMessage>

All nodes contained in ProductionRequestFulfillment includingProductionRequestID belong to the same sequence context. Thereconciliation period of this sequence context is 2. The consumedmaterial (Outbound) whose node is uniquely determined by location andproduct ID makes up a separate sequence context, which is inreconciliation period 87451. The produced material (Inbound) constitutesanother sequence context with reconciliation period 2327.

(aaaaaaaaaaaaaaaaaaa) RoundTripIndicator

A GDT RoundTripIndicator indicates whether or not a trip is to a singledestination and starts and ends at the same location.

(bbbbbbbbbbbbbbbbbbb) StayDescription

A GDT StayDescription is a description of a stay. For the GDTStayDescription, the Type is MEDIUM_Description.

(ccccccccccccccccccc) SubstitutionAllowedIndicator

A GDT SubstitutionAllowedIndicator indicates whether it is allowed tosubstitute something or not. The GDT SubstitutionAllowedIndicator may beused for instance in logistics to determine whether certain elements ofa sales order item may be substituted within the logistic processing ofthe order. Such a substitution may be desired for instance in order toachieve an earlier delivery date. As an example, the GDTSubstitutionAllowedIndicator indicates if the requested material may besubstituted by an appropriate substitute material.

(ddddddddddddddddddd) TechnicalUserDescription

A GDT TechnicalUserDescription is a description of a technical user. Forthe GDT TechnicalUserDescription, the Type is MEDIUM_Description.

(eeeeeeeeeeeeeeeeeee) TransportationTermsDescription

A GDT TransportationTermsDescription is a natural-languagerepresentation of the characteristics of the transport For the GDTTransportationTermsDescription, the Type is LONG_Description.

(fffffffffffffffffff) VehicleDescription

A GDT VehicleDescription is a description of a vehicle. For the GDTVehicleDescription, the Type is LONG_Description.

(ggggggggggggggggggg) VehicleMakeName

A GDT VehicleMakeName is a Name of the manufacturer of a vehicle. Forthe GDT VehicleMakeName, the Type is SHORT_Description

(hhhhhhhhhhhhhhhhhhh) WomanOwnedIndicator

A GDT WomanOwnedIndicator indicates whether something is owned by awoman or a group of women. The GDT WomanOwnedIndicator is used, forexample, if within a certain procurement process, the desired businesspartner with this characteristic should be chosen. In almost all USstates, there are special regulations for the advancement of companiesowned by women; in some, they must then be specially considered in anRFQ. In others, a specified set amount of the requirement must beprocured from such a firm. These regulations refer to public facilitiesor government agencies, though private companies are also obligated tocomply with these requirements (Code of Business).

A company can receive woman-owned status from the official agency, if atleast 51% of the company is owned a woman or group of women (DOD Policyon Small Disadvantaged Business Utilization (FAR/DFARS Part 19.9)); theyare then added to the official register (Directory of woman/minorityowned business: http://www.sba8a.com/).

The above-mentioned regulations deal with the implementation of thefollowing edicts and federal laws of the USA: the Small BusinessAdministration 8(a) program 1968, full utilization of Women-OwnedBusinesses in Federal Acquisition, Executive order 12138, May 18, 1979,women's Business Ownership Act, public law 100-533, Oct. 25, 1988, andthe Federal Acquisition Streamlining Act (FASA) section 7106, 1994.

In the context of use, a description may be given as to which object theWomanOwnedIndicator refers. Examples may include:BusinessPartnerWomanOwnedIndicator, CompanyWomanOwnedIndicator,BankWomanOwnedIndicator and so on.

(iiiiiiiiiiiiiiiiiii) LocationName

A GDT LocationName is a Name of a location. For the GDT LocationName,the Type is MEDIUM_Name.

(jjjjjjjjjjjjjjjjjjj) PackagingMaterialTiedIndicator

A GDT PackagingMaterialTiedIndicator specifies whether or not apackaging material (load carrier, additional packaging material) is tiedto a packaging unit. For example, a packaging unit is a HandlingUnit ora LogisticsUnit.

Expensive load carriers (such as pallets) and additional packagingmaterial may be inventory-managed materials. Then the GDTPackagingMaterialTiedIn-dicator expresses whether or not a load carrier,for example, is a physical part of a packaging unit (“tied”).

(kkkkkkkkkkkkkkkkkkk) AutomaticallyGeneratedIndicator

The automatic generation by a system is understood as the opposite of amanual or a user-triggered generation. For example, a HandlingUnit canbe moved from one storage location to another. To document this stockchange, an inventory change item is created. As a result of thismovement, the other materials contained in the HandlingUnit andSub-HandlingUnits are also moved. To document these other materials'movements and the sub-HandlingUnits, additional inventory change itemare created that all have the AutomaticallyGeneratedIndicator: Theseadditional document items are created by the system automatically withno queries to the user.

(lllllllllllllllllll) BlockedIndicator

Specify exactly what is blocked/not blocked for every BlockedIndicator.This is reflected in a corresponding name prefix. For example,AccountBlockedIndicator specifies whether an account is blocked or not.The BlockedIndicator is required for indicating objects that can beblocked or not blocked, such as credit cards, accounts, escalators andstreets. In addition to the name prefix entry, the business meaning ofthe block must also be specified for the BlockedIndicator (compare toIntegrity Conditions).

(mmmmmmmmmmmmmmmmmmm) ApplyIndicator

An AppliedIndicator also exists. The AppliedIndicator specifies whethersomething was used whereas the ApplyIndicator specifies whethersomething should be used.

(nnnnnnnnnnnnnnnnnnn) BusinessPartnerBankDetailsName

A BusinessPartnerBankDetailsName is a word, or a combination of words,designating or describing the bank details of a business partner. Inaddition to specifying an account, the bank details of a businesspartner also contain administrative information (see GDTBusinessPartnerBankDetailsID).

(ooooooooooooooooooo) BusinessPartnerPartnerGroupName

A BusinessPartnerPartnerGroupName is a word, or a combination of words,designating or describing a partner group. By party group we meanpersons or organizations that have merged. This merger can be the resultof a common purpose or the occurrence of an event. Partner groups aremapped as business partners of the category group(GDTBusinessPartnerCategoryCode).

(ppppppppppppppppppp) BusinessPurposeDescription

A GDT BusinessPurposeDescription is a description of a business purpose.

(qqqqqqqqqqqqqqqqqqq) ChangeAllowedIndicator

A ChangeAllowedIndicator indicates whether something can be changed ornot. Comment: The word “something” usually stands for values or objects.

(rrrrrrrrrrrrrrrrrrr) CheckedIndicator

A CDT qualifier CheckedIndicator specifies whether something was checkedor not. A CheckedIndicator does not say anything about the result of thecheck.

(sssssssssssssssssss) CompleteIndicator

A CompleteIndicator specifies whether or not something is complete. Theword “something” usually refers to processes or objects. ACompletedIndicator is the information on whether an object is completedin a business sense or not. In general, a CompletedIndicator relates tobusiness transactions (for example, invoice creation, delivery,sourcing) or to objects that have the character of a transaction (forexample, product catalog transfer in multiple steps).

(ttttttttttttttttttt) CorrespondenceBrailleRequiredIndicator

A CorrespondenceBrailleRequiredIndicator indicates whether or notcorrespondence should be written in Braille.

(uuuuuuuuuuuuuuuuuuu) DeductionIndicator

A DeductionIndicator specifies whether something is a deduction or not.

(vvvvvvvvvvvvvvvvvvv) EnabledIndicator

An EnabledIndicator indicates whether or not something has been enabled.

The word “something” usually stands for specific attributes orprocesses.

(wwwwwwwwwwwwwwwwwww) FlatRateReimbursementIndicator

A FlatRateReimbursementIndicator specifies whether there is a flat ratereimbursement or not.

(xxxxxxxxxxxxxxxxxxx) IdentifierIssuingAgencyName

An IdentifierIssuingAgencyName is a word, or a combination of words,designating or describing an agency that assigns an ID number(identifier). The agency can be an authority (such as the office for theregistration of residents), a company (Dun & Bradstreet), or anorganization (UN).

(yyyyyyyyyyyyyyyyyyy) InstallationPointName

An InstallationPointName is a word or combination of words used todesignate an installation point.

(zzzzzzzzzzzzzzzzzzz) LimitViolationIndicator

A LimitViolationIndicator specifies whether a limit was violated or not.

(aaaaaaaaaaaaaaaaaaaa) MinorityOwnedIndicator

A MinorityOwnedIndicator specifies whether something is owned by aminority or not. The MinorityOwnedIndicator is used, for example, ifwithin a certain procurement process, the desired business partner withthis characteristic should be chosen.

In almost all US states, there are special regulations for theadvancement of companies owned by minorities; in some, they must then bespecially considered in an RFQ; in others, a specified set amount of therequirement must be procured from such a firm. These regulations referto public facilities or government agencies, though private companiesare also obligated to comply with these requirements (Code of Business).

A company can receive minority status from the official agency, if atleast 51% of the company is owned by people or group considered to be aminority (DOD Policy on Small Disadvantaged Business Utilization(FAR/DFARS Part 19)); they are then added to the official register(Directory of woman/minority owned business: http://www.sba8a.com/).

The above-mentioned regulations deal with the implementation of edictsand federal laws of the USA, such as The Small Business Administration8(a) program, Minority Business Enterprise Program, Executive Order11458, 5 Mar. 1969, Support of Minority Business Enterprise, ExecutiveOrder 11625, 1971, and Full utilization of Small Disadvantaged Business(SDB), public law 95-507, 24 Oct. 1978 to name a few examples.

In the context of use, a description must be given as to which objectthe MinorityOwnedIndicator refers. (e.g.,BusinessPartnerMinorityOwnedIndicator, CompanyMinorityOwnedIndicator,BankMinorityOwnedIndicator, etc.)

(bbbbbbbbbbbbbbbbbbbb) AcademicTitleCode

A GDT AcademicTitleCode 35800ID can represent, in the form of a code, anacademic title. An example of a GDT AcademicTitleCode 35800ID is:

<AcademicTitleCode listAgencyID=310>0001</AcademicTitleCode>

The structure of GDT AcademicTitleCode 35800ID is depicted in FIG.358ID. For the GDT AcademicTitleCode 35800ID, the Property is AcademicTitle 35802ID, the Representation/Association is Code 35804ID, the Typeis CCT 35806ID, the Type Name is Code 35808ID and the Length is from oneto four 35810ID. The Cardinality is zero or one 35812ID.

For the list ID 35814ID, the Category is Attribute 34516ID, the ObjectClass is Code List 35818ID, the Property is Identification 35820ID, theRepresentation/Association is Identifier 35822ID, the Type is xsd35824ID, and the Type Name is token 35826ID. The Cardinality is zero orone 35828ID.

For the list Agency ID 35830ID, the Category is Attribute 34532ID, theObject Class is Code List Agency 35834ID, the Property is Identification35836ID, the Representation/Association is Identifier 35838ID, the Typeis xsd 35840ID, and the Type Name is token 35842ID. The Cardinality iszero or one 35844ID.

For the list Version ID 35846ID, the Category is Attribute 34548ID, theObject Class is Code List 35850ID, the Property is Version 35852ID, theRepresentation/Association is Identifier 35854ID, the Type is xsd35856ID, and the Type Name is token 35858ID. The Cardinality is zero orone 35860ID.

For the list Agency-Scheme ID 35862ID, the Category is Attribute34564ID, the Object Class is Code List Agency 35866ID, the Property isScheme 35868ID, the Representation/Association is Identifier 35870ID,the Type is xsd 35872ID, and the Type Name is token 35874ID. TheCardinality is zero or one 35876ID.

For the list Agency-Scheme Agency ID 35878ID, the Category is Attribute34580ID, the Object Class is Code List Agency 35882ID, the Property isScheme Agency 35884ID, the Representation/Association is Identifier35886ID, the Type is xsd 35888ID, and the Type Name is token 35890ID.The Cardinality is zero or one 35892ID.

An extendable SAP code list is assigned to the GDT AcademicTitleCode35800ID. SAP customers can change this code list.

In its unchanged state, the SAP code list has the following attributes:listID=“10115”, listAgencyID=“310”, listVersionID which is the versionof the relevant code list assigned and managed by SAP AG. If an SAPcustomer makes changes to the SAP code list, the values of theattributes are changed as follows: listAgencyID which is the ID of theSAP customer (ID from DE 3055 if listed there), listVersionID which isassigned and managed by the SAP customer, listAgencySchemeID which isthe ID of the scheme if the listAgencyID does not come from DE 3055, andlistAgencySchemeAgencyID which is the ID of the organization from DE3055 that manages the listAgencySchemeID scheme.

The GDT AcademicTitleCode 35800ID is used as part of a name of a person.The following dictionary objects are assigned to this GDT in mySAPsystems: Data element: AD_TITLE1 and Domain: AD_TITLE1. The possiblevalues for GDT AcademicTitleCode 35800ID are maintained in table TSAD2.

The code list can include six values. Code 001, Dr., describes a Doctor.Code 0002, Prof., describes a Professor. Code 0003, Prof. Dr., describesa Professor Doctor. Code 0004, B.A., describes a Bachelor of Arts. Code0005, MBA, describes a Master of Business Administration. Code 0006,PhD, describes a Doctor of Philosophy.

(cccccccccccccccccccc) AccountDeterminationCompanyGroupCode

A GDT AccountDeterminationCompanyGroupCode 35800IE is the codedrepresentation of a group of companies from the viewpoint of identicaldetermination of accounts in accounting. For the purposes of properfinancial reporting, the value-based representation of businesstransactions in accounting must use different accounts. An example of aGDT AccountDeterminationCompanyGroupCode 35800IE is:

<AccountDeterminationCompanyGroupCode>1</AccountDeterminationCompanyGroupCode>

The structure of GDT AccountDeterminationCompanyGroupCode 35800IE isdepicted in FIG. 358IE. For the GDT AccountDeterminationCompanyGroupCode35800IE, the Object Class Term Qualifier is Account Determination35802IE, the Object Class Term is Company Group 35804IE, theRepresentation/Association is Code 35806IE, the Type is CCT 35808IE, theType Name is Code 35810IE, and the Length is from one to four 35812IE.The remark 35814IE shows that GDT AccountDeterminationCompanyGroupCode35800IE may be restricted.

The code list involved is a custom code list. The GDTAccountDeterminationCompanyGroupCode 35800IE is used only in thebusiness object models and in A2A messages. Examples of possible codesare domestic companies and foreign companies.

(dddddddddddddddddddd) AccountDeterminationResourceGroupCode

A GDT AccountDeterminationResourceGroupCode 35800IF is the codedrepresentation of a group of resources from the viewpoint of identicaldetermination of accounts in accounting. For the purposes of properfinancial reporting, the value-based representation of businesstransactions in accounting must use different general ledger accounts.An example of a GDT AccountDeterminationResourceGroupCode 35800IF is:

<AccountDeterminationResourceGroupCode>1</AccountDeterminationResourceGroupCode>

The structure of GDT AccountDeterminationResourceGroupCode 35800IF isdepicted in FIG. 358IF. For the GDTAccountDeterminationResourceGroupCode 35800IF, the Object Class isAccount Determination Resource Group 35802IF, theRepresentation/Association is Code 35806IF, the Type is CCT 35808IF, theType Name is Code 35810IF and the Length is from one to ten 35812IF. Theremark 35814IF shows that GDT AccountDeterminationResourceGroupCode35800IF may be restricted.

The GDT AccountDeterminationResourceGroupCode 35800IF is used only inthe business object models and in A2A messages. Examples of possiblecodes include machines, workers, consultants, and equipment

(eeeeeeeeeeeeeeeeeeee) AccountingBusinessTransactionTypeCode

A GDT AccountingBusinessTransactionTypeCode 35800IG is the codedrepresentation of the type of business transaction from the accountingview. A business transaction is a self-contained, logically coherentbusiness event that results in a change in quantity or value. An exampleof a GDT AccountingBusinessTransactionTypeCode 35800IG is:

<AccountingBusinessTransactionTypeCode>104</AccountingBusinessTransactionTypeCode>

The structure of GDT AccountingBusinessTransactionTypeCode 35800IG isdepicted in FIG. 358IG. For the GDTAccountingBusinessTransactionTypeCode 35800IG, the Object Class isAccounting Business Transaction 35802IG, the Property is Type 35804IG,the Representation/Association is Code 35806IG, the Type is CCT 35808IG,the Type Name is Code 35810IG and the Length is from one to four35812IG. The remark 35814IG shows that GDTAccountingBusinessTransactionTypeCode 35800IG may be restricted.

A fixed SAP code list has been assigned to GDTAccountingBusinessTransactionTypeCode 35800IG. The attributes of the CCTcode are listID=10007 and listAgencyID=“310”.

The GDT AccountingBusinessTransactionTypeCode 35800IG is used tocategorize all business transactions that are relevant for accountingand is used in accounting, for example, for account determination or tovaluate business transactions correctly.

Each process component describes its processes using the GDTBusinessProcessVariantTypeCode. This GDT is transferred in messages tothe process component It is then used in accounting, possibly incombination with other information, to determine the GDTAccountingBusinessTransactionTypeCode 35800IG. Examples of businesstransactions with the type “Goods Receipt from Vendor”, from theaccounting view, are goods receipt for an order in the warehouse (in theprocess component SiteLogisticsProcessing) and manually enteredconfirmation of goods receipt of consumable materials (in the processcomponent GoodsAndServiceAcknowledgement).

Business transactions generate or change business transaction documents.The data types GDT AccountingBusinessTransactionTypeCode 35800IG andBusinessTransactionDocumentTypeCode are therefore closely related. Sincecomplex business transactions (such as the confirmation of a productionorder) generate or change more than one business transaction document,it is not possible to create a simple (1:1 or 1:n) relationship betweenthe code lists of these data types.

The GDT BusinessTransactionTypeCode is obsolete and is replaced by thisGDT in accounting.

The code list and its values are as follows: code 101 is an incomingbank transfer, code 102 as an Incoming Direct Debit, code 103 is anIncoming Check Payment, code 104 is an Incoming Cash Payment, code 105is an Incoming BoE Payment, code 106 is an Incoming Payment Request,code 107 is an Incoming Payment Advice, code 108 is an Incoming CreditCard Payment, code 109 is an Incoming Lockbox Payment, code 141 is anOutgoing Bank Transfer, code 142 is an Outgoing Direct Debit, code 143is an Outgoing Check Payment, code 144 is an Outgoing Cash Payment, code145 is an Outgoing BoE Payment, code 146 is an Outgoing Payment Request,code 147 is an Outgoing Payment Advice, code 148 is a Credit CardSettlement, code 181 is a Check Deposit, code 182 is a BoE Submission,code 183 is a Cash Transfer, code 184 is a Bank Account Statement, code201 is an Incoming Invoice, code 212 is an Outgoing Invoice, code 301 isa Goods Receipt from Vendor, code 302 is a Goods Receipt from Customer,code 303 is a Goods Receipt from Production, code 304 is a Goods Receiptwithout Reference (Sender), code 341 is a Goods Issue for Customer, code342 is a Goods Issue for Transfer, code 343 is a Goods Issues forVendor, code 344 is a Goods Issue for Production, code 345 is a GoodsIssue for Consumption, code 346 is a Goods Issue without Reference, code381 is a Goods Transfer, code 401 is a Service Receipt from Vendor, code402 is a Service Confirmation for Sales, code 403 is an Internal ServiceConfirmation, code 501 is a Maintain Purchase Order, code 502 is aMaintain Production Lot, code 503 is a Maintain Sales Order, code 504 isa Maintain Customer Return, code 505 is a Maintain Service Order, code506 is a Maintain Service Contract, code 507 is a Maintain ServiceConfirmation, code 508 is a Maintain Service Request and code 509 is aMaintain Project.

(ffffffffffffffffffff) AccountingDocumentTypeCode

A GDT AccountingDocumentTypeCode 35800IH is a coded representation ofthe type of accounting document. For example, the type of accountingdocument is based on customer-defined criteria. A unique GDTAccountingDocumentTypeCode 35800IH is assigned to eachAccountingDocument. An accounting documentGlobal Data Types—Definitionenis the representation of changes to values resulting from a businesstransaction and relating to a company and a set of books. An example ofthe GDT AccountingDocumentTypeCode 35800IH is:

<AccountingDocumentTypeCode>1</AccountingDocumentTypeCode>

The structure of the GDT AccountingDocumentTypeCode 35800IH is depictedin FIG. 358IH. For the GDT AccountingDocumentTypeCode 35800IH, theObject Class is Accounting Document 35804IH, the Property is Type35806IH, the Representation/Association is Code 35808IH, the Type is CCT35810IH, the Type Name is Code 35812IH, and the Length is from one tofive 35814IH. The remark 35818IH shows that the GDTAccountingDocumentTypeCode 35800IH may be restricted.

The GDT AccountingDocumentTypeCode 35800IH is a customer-defined codelist. Examples of the possible semantics of the codes can be found under“Use”. AccountingDocumentTypeCode may currently only be used in businessobjects and A2A messages.

For business transactions that are entered in the operational system andtransferred to Accounting, the GDT AccountingDocumentTypeCode 35800IH isderived from the GDT BusinessTransactionTypeCode. For a more refinedderivation, other characteristics for the business transaction may beincluded in the derivation.

For business transactions that are entered in Accounting, the GDTAccountingDocumentTypeCode 35800IH is entered. Examples ofcustomer-defined codes: Customer Invoice—Accounting document thatrepresents an outgoing invoice, Vendor Invoice—Accounting document thatrepresents an incoming invoice, Goods Movement—Accounting document thatrepresents a movement of goods, and Depreciation of FixedAssets—Accounting document that represents the depreciation of a fixedasset.

There is an n:m relationship between GDT AccountingDocumentTypeCode35800IH and business transaction types (BusinessTransactionTypeCode).Some business transaction types may have a very similar meaning (forexample, in Inventory Accounting), in which case it can be useful tosummarize them as Accounting DocumentTypeCodes. On the other hand, thereare business transaction types that are of a more general nature (suchas a basic G/L account posting). For such business transaction types, itcan be useful from the customer perspective to differentiate furtherusing AccountingDocumentTypeCodes.

(gggggggggggggggggggg) AddressID

A GDT AddressID 35800II is a unique identifier of an address. An exampleof GDT AddressID 35800II is:

<AddressID>ADACR300000105130000010512</AddressID>

The structure of GDT AddressID 35800II is depicted in FIG. 358II. Forthe GDT AddressID 35800II, the Object Class is Address 35804II, theProperty is Identification 35806II, the Representation/Association isIdentifier 35808II, the Type is CCT 35810II, the Type Name is Identifier35812II, and the Length is from one to forty 35814II. The remark 35818IIshows that the GDT AddressID 35800II may be restricted.

(hhhhhhhhhhhhhhhhhhhh) AddressPersonID

A GDT AddressPersonID 35800IJ is a clear proprietary identifier of theperson part of an address. An example of the GDT AddressPersonID 35800IJis:

<AddressPersonID>0000010512</AddressPersonID>

The structure of the GDT AddressPersonID 35800IJ is depicted in FIG.358IJ. For the GDT AddressPersonID 35800IJ, the Object Class is AddressPerson 35804IJ, the Property is Identification 35806IJ, theRepresentation/Association is Identifier 35808IJ, the Type is CCT35810IJ, the Type Name is Identifier 35812IJ, and the Length is from oneto ten 35814IJ. The remark 35818IJ shows that the GDT AddressPersonID35800IJ may be restricted.

The GDT AddressPersonID 35800IJ is required to uniquely identifypersonal addresses and workplace addresses because these are notidentified uniquely by the GDT AddressPostalAddressID alone.

(iiiiiiiiiiiiiiiiiiii) AddressTypeCode

A GDT AddressTypeCode 35800IK is a coded representation of the type ofan address. For example, the address type describes the basic featuresof an address by means of the type of address data. An example of theGDT AddressTypeCode 35800IK is:

<AddressTypeCode listAgencyId=‘3110’>1</AddressTypeCode>

The structure of the GDT AddressTypeCode 35800IK is depicted in FIG.358IK. For the GDT AddressTypeCode 35800IK, the Property is Address Type35806IK, the Representation/Association is Code 35808IK, the Type is CCT35810IK, the Type Name is Code 35812IK, and the Length is from one35814IK. The remark 35818IK shows that the GDT AddressTypeCode 35800IKmay be restricted.

The GDT AddressTypeCode 35800IK is assigned a code list. The attributesare filled as follows: listID=“10087”, and listAgencyID=“310”. The datatype GDT AddressTypeCode 35800IK is used to determine the address typein addresses. The following dictionary objects are assigned to this GDT:Data element: ADDR_ADDRESS_TYPE, and Domain: ADDR_ADDRESS_TYPE.

The data type GDT AddressTypeCode 35800IK may use the following codes: 1(i.e., organization address), 2 (i.e., person address), 3 (i.e.,workplace address), 4 (i.e., communication data without postal address),5 (i.e., personal address without postal address).

(jjjjjjjjjjjjjjjjjjjj) BatchID

A GDT BatchID 35800IL is a unique identifier for a batch in the contextof a material number. For example, a batch is a homogenous subset of amaterial that is managed separately from other subsets of the samematerial. Individual batches can differ in their characteristics. Theindividual batches are either created together in one production processor purchased together in one order. An example of the GDT BatchID35800IL is:

<BatchID>CH20021015</BatchID>

The structure of the GDT BatchID 35800IL is depicted in FIG. 358IL. Forthe GDT BatchID 35800IL, the Category is Complex Type 35801ILNN, theObject Class is Batch 35802IL, the Property Term is Identifier 35803IL,the Representation Term is Identifier 35804IL, the Type is CCT 35805IL,the Type Name is Identifier 35806IL, and the Length is from one to ten35807IL. The remark 35809IL shows that the GDT BatchID 35800IL may berestricted.

For the SchemeID 35810IL, the Category is Attribute (A) 35811IL, theObject Class is IdentificationScheme 35812IL, the Property isIdentification 35813IL, the Representation Term is Identifier 35814IL,the Type is XSD 35815IL, the Type Name is Token 35816IL, and theCardinality is zero or one 35818IL.

For the SchemeVersionID 35820IL, the Category is Attribute (A) 35821IL,the Object Class is IdentificationScheme 35822IL, the Property isIdentification 35823IL, the Representation/Association is Identifier35824IL, the Type is XSD 35825IL, the Type Name is Token 35826IL, andthe Cardinality is zero or one 35828IL.

For the SchemeAgencyID 35830IL, the Category is Attribute (A) 35831IL,the Object Class is IdentificationSchemeAgency 35832IL, the Property isVersion 35833IL, the Representation/Association is Identifier 35834IL,the Type is XSD 35835IL, the Type Name is Token 35836IL, and theCardinality is zero or one 35838IL.

For the SchemeAgencySchemeID 35840IL, the Category is Attribute (A)35841IL, the Object Class is IdentificationSchemeAgency 35842IL, theProperty is Scheme 35843IL, the Representation Term is Identifier35844IL, the Type is XSD 35845IL, the Type Name is Token 35846IL, andthe Cardinality is zero or one 35848IL.

For the SchemeAgencySchemeAgencyID 35850IL, the Category is Attribute(A) 35851IL, the Object Class is IdentificationSchemeAgency 35852IL, theProperty is Scheme 35853IL, the Representation Term is Identifier35854IL, the Type is XSD 35855IL, the Type Name is Token 35846IL, andthe Cardinality is zero or one 35858IL. The GDT BatchID 35800IL has amaximum length of 10 characters and can comprise letters, numbers, anddisplayable special characters, with the exception of “*”, “&”, and “,”.The identifier must be uppercase. The GDT BatchID 35800IL must not beginwith blank characters or contain consecutive blank characters. The GDTBatchID 35800IL value range includes any combinations of the permittedcharacters up to a maximum length of 10 characters. The SchemeIDidentifies an identification scheme. The identification schemerepresents the context that is used to identify an object. The SchemeIDis unique only within the agency that manages this identificationscheme. The SchemeVersionID identifies the version of an identificationscheme. The SchemeAgencyID identifies the agency that manages anidentification scheme. The agencies from DE 3055 are used as thedefault, but the roles defined in DE 3055 must not be used. The GDTBatchID 35800IL is unique only within the identification scheme that ismanaged by schemeAgencyID. The SchemeAgencySchemeID identifies theidentification scheme that represents the context for agencyidentification. The SchemeAgencySchemeAgencyID identifies the agencythat manages the SchemeAgencySchemeID. This attribute can only containvalues from DE 3055 (excluding roles).

The BatchID is used only to identify batches. See the documentation forthe core component type CCT: Identifier for information about how theattributes are used. Specifying attributes is optional. By default, thesystem assumes that the batch identified by the BatchID is amanufacturer batch and therefore no attributes are required.

(kkkkkkkkkkkkkkkkkkkk) BuildingID

A GDT BuildingID 35800IM is a unique identifier of a building or part ofa building. An example of the GDT BuildingID 35800IM is:

<BuildingID>WDF03</BuildingID>

The structure of the GDT BuildingID 35800IM is depicted in FIG. 358IM.For the GDT BuildingID 35800IM, the Object Class is Building 35804IM,the Property is Identification 35806IM, the Representation/Associationis Identifier 35808IM, the Type is CCT 35810IM, the Type Name isIdentifier 35812IM, and the Length is from one to ten 35814IM. Theremark 35818IM shows that the GDT BuildingID 35800IM may be restricted.

The GDT BuildingID 35800IM may be unique in the usage context. The GDTBuildingID 35800IM is used in addresses. The following dictionaryobjects are assigned to this GDT: Data element—BU_BLDNG, andDomain—TEXT20.

(llllllllllllllllllll) BusinessIntelligenceFilterID

A GDT BusinessIntelligenceFilterID 35800IN is a unique ID for a filterin Business Intelligence. For example, business Intelligence (BI) is asoftware solution for the support of business decisions. The businessIntelligence (BI) software enables access to enterprise data in aspecially formatted form or formats the data itself. A filter is a setof conditions that delimits a dataset. An example of GDTBusinessIntelligenceFilterID 35800IN is:

<BusinessIntelligenceFilterIDschemeAgencyID=“Q12_(—)003”>MY_FILTER</BusinessIntelligenceFilterID>

The structure of GDT BusinessIntelligenceFilterID 35800IN is depicted inFIG. 358IN. For the GDT BusinessIntelligenceFilterID 35800IN, the ObjectClass is BusinessIntelligenceFilter 35801IN, the Property isIdentification 35803IN, the Representation/Association is Identifier35804IN, the Type is CCT 35805IN, the Type Name is Identifier 35806IN,and the Length is from one to sixty 35807IN. The remark 35809IN showsthat the GDT BusinessIntelligenceFilterID 35800IN may be restricted.

For the SchemeAgencyID 35810IN, the Category is Attribute (A) 35811IN,the Object Class is BusinessIntelligenceFilter 35812IN, the Property isIdentification 35813IN, the Representation/Association is Identifier35814IN, the Type is CCT 35815IN, the Type Name is Identifier 35816IN,the Length is from one to sixty 35817IN, and the Cardinality is zero orone 35818IN.

The attribute of the GDT BusinessIntelligenceFilterID 35800IN is filledas follows: schemeAgencyID: business system in which the ID wasassigned.

(mmmmmmmmmmmmmmmmmmmm) BusinessIntelligenceInformationObjectID

A GDT BusinessIntelligenceInformationObjectID 35800IO is a unique ID foran elementary information object in Business Intelligence. For example,Business Intelligence (BI) is a software solution for the support ofbusiness decisions. The Business Intelligence (BI) software enablesaccess to enterprise data in a specially formatted form or formats thedata itself. An elementary information object in Business Intelligencecontains master data or a key figure. An example of the GDTBusinessIntelligenceInformationObjectID 35800IO is:

<BusinessIntelligenceInformationObjectIDschemeAgencyID=“Q12_(—)003”>MY_OBJECT</BusinessIntelligenceInformationObjectID>

The structure of the GDT BusinessIntelligenceInformationObjectID 35800IOis depicted in FIG. 358IO. For the GDTBusinessIntelligenceInformationObjectID 35800IO, the Object Class isBusinessIntelligenceInformationObject 35801IO, the Property isIdentification 35803IO, the Representation/Association is Identifier35804IO, the Type is CCT 35805IO, the Type Name is Identifier 35806IO,and the Length is from one to sixty 35807IO. The remark 35809IO showsthat the GDT BusinessIntelligenceInformationObjectID 35800IO may berestricted.

For the SchemeAgencyID 35810IO, the Category is Attribute (A) 35811IO,the Object Class is IdentificationSchemeAgency 35812IO, the Property isIdentification 35813IO, the Representation/Association is Identifier35814IO, the Type is XSD 35815IO, the Type Name is Token 35816IO, theLength is from one to sixty 35817IO, and the Cardinality is zero or one35818IO.

The attribute of the GDT BusinessIntelligenceInformationObjectID 35800IOis filled as follows: schemeAgencyID—business system in which the ID wasassigned.

(nnnnnnnnnnnnnnnnnnnn) BusinessIntelligenceInformationProviderID

A GDT BusinessIntelligenceInformationProviderID 35800IM is a unique IDfor an information provider in Business Intelligence. For example, theBusiness Intelligence (BI) is a software solution for the support ofbusiness decisions. The Business Intelligence (BI) software enablesaccess to enterprise data in a specially formatted form or formats thedata itself. An example of the GDTBusinessIntelligenceInformationProviderID 35800IM is:  <BusinessIntelligenceInformationProviderID schemeAgencyID =“Q12_003”>MY_PROVIDER </BusinessIntelligenceInformationProviderID>

The structure of the GDT BusinessIntelligenceInformationProviderID35800IM is depicted in FIG. 358IM. For the GDTBusinessIntelligenceInformationProviderID 35800IM, the Object Class isBusiness Intelligence Information Provider 35801IM, the Property isIdentification 35803IM, the Representation/Association is Identifier35804IM, the Type is CCT 35805IM, the Type Name is Identifier 35806IM,and the Length is from one to sixty 35807IM. The remark 35809IM showsthat the GDT BusinessIntelligenceInformationProviderID 35800IM may berestricted.

For the SchemeAgencyID 35810IM, the Category is Attribute (A) 35811IM,the Object Class is IdentificationSchemeAgency 35812IM, the Property isIdentification 35813IM, the Representation/Association is Identifier35814IM, the Type is XSD 35815IM, the Type Name is Token 35816IM, theLength is from one to sixty 35817IM, and the Cardinality is zero or one35818IM.

The attribute of the GDT BusinessIntelligenceInformationProviderID35800IM is filled as follows: schemeAgencyID—business system in whichthe ID was assigned.

(oooooooooooooooooooo) BusinessIntelligencePlanningSequenceID

A GDT BusinessIntelligencePlanningSequenceID 35800IQ is a unique ID fora planning sequence in Business Intelligence. For example, BusinessIntelligence (BI) is a software solution for the support of businessdecisions. The Business Intelligence (BI) software enables access toenterprise data in a specially formatted form or formats the dataitself. A planning sequence is a list of planning functions and filtersthat are processed in the order in which they occur in the list. Aplanning function generates or changes planning data. A filter is a setof conditions that delimits a dataset. An example of the GDTBusinessIntelligencePlanningSequenceID 35800IQ is:  <BusinessIntelligencePlanningSequenceID schemeAgencyID =“Q12_003”>MY_SEQUENCE </BusinessIntelligencePlanningSequenceID>

The structure of the GDT BusinessIntelligencePlanningSequenceID 35800IQis depicted in FIG. 358IQ. For the GDTBusinessIntelligencePlanningSequenceID 35800IQ, the Object Class isBusinessIntelligencePlan-ningSequence 35801IQ, the Property isIdentification 35803IQ, the Representation/Association is Identifier35804IQ, the Type is CCT 35805IQ, the Type Name is Identifier 35806IQ,and the Length is from one to sixty 35807IQ. The remark 35809IQ showsthat the GDT BusinessIntelligencePlanningSequenceID 35800IQ may berestricted.

For the SchemeAgencyID 35810IQ, the Category is Attribute (A) 35811IQ,the Object Class is IdentificationSchemeAgency 35812IQ, the Property isIdentification 35813IQ, the Representation/Association is Identifier35814IQ, the Type is XSD 35815IQ, the Type Name is Token 35816IQ, theLength is from one to sixty 35817IQ, and the Cardinality is zero or one35818IQ.

The attribute of the GDT BusinessIntelligencePlanningSequenceID 35800IQis filled as follows: schemeAgencyID—business system in which the ID wasassigned.

(pppppppppppppppppppp) BusinessObjectTypeCode

A GDT BusinessObjectTypeCode 35800IR is a coded representation of thetype of business object. For example, a business object is arepresentation of a type of a uniquely identifiable business entitydescribed by a structural model, an internal process model, and one ormore service interfaces. An example of GDT BusinessObjectTypeCode35800IR is:

<BusinessObjectTypeCode>4</BusinessObjectTypeCode>

The structure of GDT BusinessObjectTypeCode 35800IR is depicted in FIG.358IR. For the GDT BusinessObjectTypeCode 35800IR, the Object Class isBusinessObject 35804IR, the Property is Type 35806IR, theRepresentation/Association is Code 35808IR, the Type is CCT 35810IR, theType Name is Code 35812IR, and the Length is from one to four 35814IR.The remark 35818IR shows that the GDT BusinessObjectTypeCode 35800IR maybe restricted.

Exactly one fixed code list has been assigned to the code. Theattributes are as follows: listID=“10315”, listAgencyID=“310”, andlistVersionID=/[Version of the relevant code list].

The data type GDT BusinessObjectTypeCode 35800IR may use the followingcodes 6 (i.e., a AccountingDocumentGlobal Data Types—Definitionen is therepresentation of changes to values resulting from a businesstransaction, and relating to a company and financial accounting), 7(i.e., a Global Data Types—Definitionen AccountingEntry is a businesstransaction entered in the terms of Financial Accounting, and concerningchanges in value to the asset and equity structure of a companyac-cording to the rules of one or more accounting principles. The entryis made in relation to the accounts of the general ledger and of thesubledgers), 8 (i.e., an AccountingNotification is a notification sentto Financial Accounting by an operational component regarding a businesstransaction. It represents this operational business transaction in astandardized form for all business transaction documents, and containsthe data needed to valuate the business transaction), 9 (i.e.,something), 14 (i.e., a bank payment order is an instruction to a housebank to make a transfer or direct debit from a specified house bankaccount), 15 (i.e., a BankStatement is a legally binding notificationfrom the house bank about the revenues (items) within a specific timeperiod at a house bank account (HouseBankAccount) with a definedstarting and closing bal-ance.), 23 (i.e., a ClearingHousePaymentOrderis an instruction to a clearing house (clearing center for cardpayments) to settle an incoming card payment using aClearingHouseAccount. A ClearingHousePaymentOrder is generated tofulfill an internal payment order), 26 (i.e., authorized incoming creditcard payment, that will be sent to the clearing house), 27 (i.e., acomplaint made by a customer regarding an experience that the customerhad with a sales or service employee), 28 (i.e., CustomerComplaintcontains parties involved in this complaint, such as the customer,items, as well as sales, service and invoicing-specific information, itsstatus, as well as references; CustomerComplaint itself containsidentifying and administrative information), 29 (i.e., aCustomerInvoiceRequest is a request to create one or moreCustomerInvoices, or to take data from the business transaction uponwhich this is based into consideration when creating theCustomerInvoice), 30 (i.e., a CustomerQuote is a quote by a vendor to acustomer regarding the delivery of goods, or the provision of servicesat a specific price, quantity and date.), 32 (i.e., a CustomerReturn isa request by the customer to the vendor to take delivered goods back,and to cancel the purchase), 33 (i.e., representation of possibleliabilities and receivables from bails, payment guarantees, and otherguarantees for third persons, deficiency suretyship, limited bails,directly enforceable guarantee, cosuretyship), 34 (i.e., a DemandForecast is a forecast from the material requirements planning about thedemand for a material at a particular location, in a particular area ofmaterial requirements planning), 35 (i.e., a DemandPlanningForecast isthe quantitative forecast of the sale of products within a planningperiod that is created according to the requirement on product, brand,or customer group level.), 36 (i.e., a group of receivables and payablesfor clearing), 37 (i.e., a payment request or payment confirmation withregard to trade receivables and payables), 42 (i.e., evaluation of timemanagement documents for an internal or external employee. The documentsare evaluated according to business factors such as availability, timeaccounts, or transfer of data to payroll or other target applications),43 (i.e., an EmployeeCompensationAgreement is the set of rules governingan employee's compensation), 44 (i.e., an EmployeeTimeAgreement containsthe statutory time management provisions and those agreed with anemployee), 47 (i.e., an ExpenseReport is a list of receipts for theexpenses incurred for the company (Company) within a certain period oftime that are to be reimbursed to an expense reporter (Employee). In thecase of a business trip, the ExpenseReport also contains the reason forthe trip and relevant general information on the trip such asdestinations, dates and times, and mileages), 48 (i.e., anExpenseArrangement is a definition by the company of parameters for anemployee that are needed for an expense report. It contains parametersrelevant for the determination of per diem amounts, the type of standardvehicle, and the standard cost distribution), 49 (i.e., the businessobject Factoring represents the sales of financial claims from goods andservices deals), 55 (i.e., a confirmation of physical changes toinventory (for example, goods movements, HU/LU movements) and the usageof activities in Logistics Execution), 60 (i.e., an IncomingCheque is acheck issued by a business partner for a company (incoming check)), 64(i.e., a Lead is a business transaction that describes the potential orprojected business interests of a business partner and the interactionsbased on this over a period of time), 66 (i.e., forecast of the medium-to long-term development of the liquidity situation of a company or agroup of companies), 67 (i.e., an ExpectedLiquidityItem is an expectedinflow or outflow of liquidity in a company), 69 (i.e., aMaterialCostEstimate is a statement of the costs that are calculated forthe procurement or production of a material. It contains both thecomplete result of costing, as well as details of individual cost items,such as the usage of materials, resources, or the usage of external orinternal services), 70 (i.e., a MaterialInspection is the document thatdescribes the execution of an inspection for a particular material, andthat is used to record this inspection), 71 (i.e., aMaterialInspectionSample is the sample required for an examination inthe context of a material inspection. The sample is the subject ofexamination for inspection procedures. A sample can be drawn from amaterial independently of a material inspection and, if necessary, itcan later be assigned to a material inspection), 75 (i.e., anOutgoingCheque is a check issued by a company for a business partner forthe fulfillment of an internal PaymentOrder), 80 (i.e., a PaymentAdviceis the notification of a payment transaction by a business partner thatspecifies reasons), 81 (i.e., a PaymentAllocation is the assignment of apayment item (an item of the business object Payment) to the paymentreason from which the payment item originated), 83 (i.e., aPersonnelHiring is the first hiring, rehiring, or closing of anotherwork agreement of an employee), 84 (i.e., a PersonnelTransfer is theorganizational reassignment of an employee within the company), 85(i.e., a PersonnelTransfer is the organizational reassignment of anemployee within the company), 89 (i.e., a ProcurementPlanningOrder is aplanned order for procuring materials that is to be placed with anexternal vendor. It defines the required quantities and availabilitydates), 90 (i.e., a PlannedIndependentRequirement is a plannedrequirement for a material for a particular time period withoutreference to a sales order), 91 (i.e., Description of a material flowfrom one planned receipt to one planned requirement for a predeterminedquantity at a specific point in time in the future), 9 (i.e.,something), 92 (i.e., a ProductionPlanningOrder is a request made to aplanning area (SupplyPlanningArea) to initiate the pro-duction of aparticular quantity of a material on a defined date), 93 (i.e., aPlanningViewOnPurchaseOrder is the planning view of planning ofmaterials, dates, quantities, delivery conditions, parties, and sourcesof supply of a purchase order that are relevant to planning), 97 (i.e.,a ProductionOrder is an order for the production of a specific quantityof a particular material within a pre-defined time. A ProductionOrdercontains all information required for the actual execution ofproduction), 100 (i.e., a ProductionTask is a task in production that aprocessor executes at a predefined production step within a productionprocess. It also represents the request to the processor to carry outthe activities described by the production task at a certain point intime), 103 (i.e., a ProjectCostEstimate is a statement of the costs thatare calculated to carry out a project. It contains both the overallresult of the cost estimate and details of individual cost items, suchas the usage of resources or external/internal services), 9 (i.e.,something), 9 (i.e., something), 104 (i.e., PlanningViewOnInventory isthe planning-related view of a stock), 109 (i.e., a PurchaseRequisitionis a request to purchasing for the external procurement of a requirementplanned in logistics. The PurchaseRequisition is derived from thePlannedExternalProcurementOrder and describes which products are to beprocured in what quantities, and at what time), 114 (i.e., a SalesOrderis an agreement between a vendor and a customer concerning the sale anddelivery of goods, plus any associated services, for a specific date,for a specific quantity, and at a specific price), 115 (i.e., aServiceConfirmation is the confirmation by a service technicianregarding working time spent and spare parts used when performing aservice for a customer), 116 (i.e., a ServiceContract is an agreementconcluded between a service provider and a customer for a specific timeperiod, specifying the scope of services, their prices, and specificservice levels that are used as a ba-sis for processing ServiceRequestsand ServiceOrders. A ServiceContract is valid for a specified period oftime), 117 (i.e., a ServiceOrder is an agreement between a serviceprovided and a customer regarding the execution of services at aspecific time and for a specific price. A service order also containsthe planning personnel, spare parts and other effort required to carryout these services), 118 (i.e., ServiceRequest is a customer request toa service provider for clarification of a concern regarding a pro-duct.In addition to the description and categorization of the concern, theServiceRequest contains the do-cumentation and results of theclarification, as well as the resulting effort), 124 (i.e., aSiteLogisticsTask is a task for executing a logistics operation oractivity within a site. It represents a piece of work to be performed bya person or an automated system), 130 (i.e., a SupplyPlanningExceptionreports a problem or error in supply planning), 131 (i.e., aSupplyPlanningRequirement is a requirement that is derived from abusiness document and to which details on the anticipated availabilitydate have been added. It contains the material quantities required onspecific dates as well as information on which quantities are availableon which dates), 143 (i.e., an AccountsReceivablePayableLedgerAccount isa subledger account that records valuated payables and receivables of acompany for a specific business partner. This record serves the purposeof proper financial reporting of these payables and receivables, and/orprofit and loss statement of a company), 147 (i.e., a business partneris a person, organization, or group of people in which a company has abusiness interest), 149 (i.e., a CashLedgerAccount is a record ofvaluated liquid assets of a company. This record serves the purpose ofproper financial reporting of liquid assets, and/or profit and lossstatement of a company), 151 (i.e., a ChequeStorage is the storagelocation for incoming checks that a company receives from its businesspartners (for example, customers)), 153 (i.e., a ClearingHouseAccount isthe internal representation of an account that is set up and managed ata clearing house for card payments on the basis of an agreement betweenthe company and the clearing house), 154 (i.e., a company is afinancially and legally independent, geographically unboundorganizational center regis-tered under business law), 155 (i.e., aCompensationComponentType describes the employee compensation componentsin the context of Human Resources), 156 (i.e., aCompensationComponentTypeCatalogueGlobal Data Types—Definitionen is astructured index of Com-pensationComponentTypes), 157 (i.e., aCompensationStructure is an organized structure of pay grade ranges. Apay grade range reflects the value of tasks and activities in thecompany. Employees can be assigned to a pay grade range based on thetasks and activities they perform. A CompensationStructure can becompany-specific or can be prede-fined according to pay scaleregulations), 158 (i.e., a CostCentre is an organizational center thatrepresents a clearly defined location at which costs arise, and forwhich costs are entered separately. The definition can be based onfunctional requirements, allocation criteria, physical location, andresponsibility for costs), 159 (i.e., in addition to the businesstransaction-related individual movements, it also contains totals thatsummarize the individual movements), 163 (i.e., a DemandHistory is thequantitative representation of sales or consumption of products within ahistorical period. This also includes corrections to demand quantities.The demand history is subdivided according to characteristics such asbrand, sales region, etc. as well as combinations of them), 165 (i.e., aDistributionCentre is an organizational unit that is responsible for theorganization and handling of incoming and outgoing delivery processesand site logistics processes), 9 (i.e., something), 9 (i.e., something),166 (i.e., a document is a carrier of unstructured information andadditional control and monitoring information), 167 (i.e., an Employeeis a person who contributes or has contributed to the creation of goodsor services for a company. There are internal and external employees.Unlike external employees, internal employees are bound by theinstructions and are subject to the control of the labor organization),168 (i.e., an EmployeeTime is a document of the working times of aninternal or external employee. In addition to planned and actual workingtimes and activities carried out for the company, it also documentsabsence times, break times, and availability times), 170 (i.e., anEmployeeTimeCalendar is the calendar representation of the evaluationresults determined by time evaluation from recorded time documents foran employee), 181 (i.e., a house bank account is the internalrepresentation of a company's bank account at a house bank. It containsall control information required for processing payment-releventprocesses), 183 (i.e., an IndividualMaterial is a material that onlyoccurs once in the real world and therefore describes a uniquelyidentifiable material. It can also be a material that will only exist inthe future), 184 (i.e., an InspectionRule contains the specificationsfor an inspection as to whether an object or procedure meets predefinedrequirements), 185 (i.e., an InstallationPoint is the physical orlogical location at which a business object, for example a material orsoftware, is installed during a certain period of time. The installationpoint contains descriptive information about its installed object, forexample, the quantity of materials incorporated, and can additionally bestruc-tured on multiple levels and hierarchically-related to otherinstallation points), 186 (i.e., from a functional perspective, anInstalledBase is a structural arrangement of business objects at alogical or physical location), 9 (i.e., something), 187 (i.e., Inventory(Root) is the quantity of all the materials in a certain locationincluding the material reservations at this location), 193 (i.e., aLogisticsTaskFolder is a folder for storing and grouping of logisticstask according to business criteria. It determines the businessassignment criteria that a logistics task must meet in order to bestored in a specific folder, and contains details about the processorsthat are registered in the folder), 194 (i.e., a material is a tangibleproduct that can be created and then represents a business value. Itscreation/production is time-independent on its sale and consumption/use.A material can be traded, used in manufacture, consumed, or produced),195 (i.e., a MaterialInspectionQualityLevel represents the currentquality level determined by the material inspection for an inspectionarea that is specified by a combination of: Material, Supplier,Receiving Plant, and Receiving Logistics Area (DistributionDepartment)), 198 (i.e., a MaterialLedgerAccount is the record ofquantities, values and prices regarding materials in a company that arerelevant for evaluation. This record serves the purpose of properfinancial reporting of the inventory or profit and loss statement of acompany), 200 (i.e., an OrganisationalCentre is a business unit withinan organizational structure (for example, organizational plan, financialstructure, geographical structure) of a company), 201 (i.e., record fora Company based on the principle of double-entry bookkeeping that showsthe effects of business transactions on other direct costs. In additionto individual account movements related to business transactions, itcontains period-based totals that summarize the movements), 203 (i.e.,an OverheadCostLedgerAccount Global Data Types—Definitionen is a recordof the costs incurred by the provision of resources. This record servesthe purpose of proper financial reporting of the profit and lossstatement of a Company, and contains the costs that cannot be assigneddirectly to market segments), 206 (i.e., a PaymentAgreement is anagreement between a company and a business partner regarding thehandling of payments. It defines, for example, the payment methodsallowed and which bank details or credit cards should be used), 207(i.e., a PaymentCard is an issued identification card that authorizesthe holder to pay an invoice without cash at an authorized location),208 (i.e., a directory of all internally initiated and externallyinitiated incoming and outgoing payments of a company), 209 (i.e., aPermanentEstablishment is an organizational centre that represents ageographically bound area of a company whose business activity issubject to uniform tax processing), 210 (i.e., a Position Global DataTypes—Definitionen is an organizational element that represents an areaof responsibility within the organizational structure of an enterprise.Its tasks, competencies and responsibilities can be taken care ofpermanently by one or more suitable employees), 221 (i.e., a productcategory hierarchy is a hierarchical arrangement of product categoriesaccording to objective business aspects. Subordinate product categoriesrepresent a semantic refinement of the respective higher level productcategory), 223 (i.e., a ProductionBillOfOperations is the description ofa production process for manufacturing a product), 224 (i.e., aProductionBillOfOperationsTemplate is a pattern for creating complexproduction processes or individual production operations. The templatecan be included in one or more ProductionBillOfOperations by copying),225 (i.e., a ProductionCentre is an organizational center that isresponsible for the organization and handling of the processes inproduction), 226 (i.e., a ProductionLedgerAccount is the record ofquantities and values regarding good being manufactured that arerelevant for valuation within a company. This record serves the purposeof proper financial reporting of the inventory or profit and lossstatement of a company), 227 (i.e., a ProductionModel is a model of aproduction process in a production center that is determined by anet-work of production segments), 229 (i.e., ProfitCentre is anorganizational center that represents a company area for which aseparate period based profit is determined and used for evaluating andregulating the activities of the company area in a profit-orientedmanner), 230 (i.e., Programme is an organizational center foradministrating a group of projects or subprograms. Programme representsa complex, time restricted endeavor for reaching higher-level goalswithin a far-reaching strategy), 231 (i.e., Business plan with a definedgoal that is to be attained in a specified time frame. It is to beachieved using predefined funds and planned resources, while reaching anagreed quality level. The project is characterized by the fact that itis unique and that it involves an element of risk), 234 (i.e., Snapshotof a project that documents the state of a project. A project snapshotcannot be changed), 235 (i.e., Business plan with a defined goal that isto be attained in a specified time frame. It is to be achieved usingpredefined funds and planned resources, while reaching an agreed qualitylevel. The project is characterized by the fact that it is unique andthat it involves an element of risk), 238 (i.e., a PurchaseLedgerAccountis a record of quantities and values that are relevant to valuation forbusiness processes in which material goods or services are procured),239 (i.e., PurchasingUnit is an organizational center responsible forstrategic and/or operational purchasing), 245 (i.e., ReportingLineUnitis an organizational center in the personnel reporting line of thecompany. A reporting line unit typically has a personnel manager who isresponsible for defining the objectives and salaries of the directly orindirectly assigned holders), 247 (i.e., a Sales Arrangement is anagreement between a sales unit and a customer that is used for salestransactions. This agreement contains, for example, payment conditions,invoice currency and incoterms. This agreement is not a contract withthe customer), 248 (i.e., a SalesLedgerAccount is a record of quantitiesand values that are relevant to valuation and that reference sales anddistribution processes. The record is used for proper reporting of thecompany's income statement and for accruing revenue recognition. Therecord is also the basis of evaluations in profitability analysis), 251(i.e., a SalesUnit is an organizational centre responsible for planning,realizing and administering sales processes), 252 (i.e., aSampleDrawingProcedure is a procedure that defines how samples are to betaken. It contains data for the sample-drawing frequency, sample size,and sample quantity), 255 (i.e., An SupportRequest is a request toeliminate an error in an IT solution. The request is ei-ther triggeredby a user, or by the system itself. It documents the error, the solutionprocess, and the solutions found. The SupportRequest contains data onthe requester, the nature and context of the error. It can also containa description of the symptom, attributes for classification of errors,problem, cause, meaning and so on. It permits an appropriate reaction,prioritization and sequence in processing), 256 (i.e., Segment is anorganizational center that represents a company area whose businessactivities result in revenue and expenditure, and whose operating incomeis regularly monitored by the main decision makers for the purpose ofassigning resources and evaluating performance. Financial information isavailable for a segment), 257 (i.e., a ServiceCategoryCatalogue is astructured directory of issue categories that describe business cases inCustomer Service from an objective or a subjective point of view), 258(i.e., a Service Product is an intangible product that describes theprovision of a service. A service is provided at the time of its use),259 (i.e., a ServiceUnit is an organizational centre responsible forprocesses covering all aspects of a customer ser-vice and supportcentre's business), 260 (i.e., a SiteLogisticsBillofOperations is thedescription of a process for the company-internal movement of goods,goods receipt, or goods issue), 264 (i.e., a SourceOfSupply is a sourceof supply for the external and internal procurement of materials), 266(i.e., a supplier is a business partner who offers/makes availablematerials or services), 267 (i.e., a SupplyPlanningArea is an area inwhich planning is executed separately to guarantee the availability ofproducts on time. To achieve this, the SupplyPlanningArea groupsrequirements, stocks, and further requirement coverage elements of asite for consumption in the net requirements calculation in materialrequirements planning), 269 (i.e., a SupplyQuotaArrangement defines thedistribution of material requirements or material issues to differentsources of supply, business partners, or internal organizational units),270 (i.e., a specification between a Company and a Tax Authority for atax type (TaxTypeCode), based on legal re-quirements. The specificationincludes data that is relevant for creating legal tax declarations, suchas, for example, the tax number or the contact person), 272 (i.e., aTaxLedgerAccount is the recording of valuated payables and receivablesfrom sales tax and excise duty for a company with regard to the taxauthorities and relating to a tax type and other tax characteristics.This record serves the purpose of proper financial reporting for salestax and excise duty for a company), 273 (i.e., Structure element of DueItem Processing for data entry and reporting of all trade receivables ortrade payables of a company from or to a business partner), 274 (i.e.,Trade receivables/payables from goods and services of a company from/toits business partners), 275 (i.e., Relationship between two locations ortransportation zones that specifies which materials can be trans-portedbetween the locations or transportation zones, and which means oftransport can be used), 276 (i.e., a zone containing geographicallocations that may be considered collectively for modeling or planningtransportation routes or transportations), 278 (i.e., a business objectWarranty is a guarantee to vouch for defects or faults in the productpurchased and is valid for a specific period of time. The type and scopeof these services (such as repairing the defect for free or taking theproduct back) is defined in the warranty), and 279 (i.e., aWorkAgreement is the contract between employer and employee by means ofwhich the employee is obliged to provide his or her labor. Theactivities and responsibilities of the employee are specified in thework agreement. This agreement establishes an employment. It is thefoundation for further particulars such as working time and salarydetails specified in other objects.).

(qqqqqqqqqqqqqqqqqqqqq) ChequeStorageInternalID

A GDT ChequeStorageInternalID 35800IT is a unique proprietary identifierfor the storage for incoming checks. An example of the GDTChequeStorageInternalID 35800IT is:

<ChequeStorageInternalID

schemeAgencyID=“VV4_(—)000”>DWDF01/3.12</ChequeStorageInternalID> Thestructure of GDT ChequeStorageInternalID 35800IT is depicted in FIG.358IT. For the GDT ChequeStorageInternalID 35800IT, the Object Class isCheque Storage 35801IT, the Property Qualification is something Internal35802ITNN, the Property is Identification 35803IT, theRepresentation/Association is Identifier 35804IT, the Type is CCT35805IT, the Type Name is Identifier 35806IT, and the Length is from oneto thirty two 35807IT. The remark 35809IT shows that the GDTChequeStorageInternalID 35800IT may be restricted.

For the SchemeAgencyID 35810IT, the Category is Attribute (A) 35811IT,the Object Class is IdentificationSchemeAgency 35812IT, the Property isIdentification 35813IT, the Representation/Association is Identifier35814IT, the Type is XSD 35815IT, the Type Name is Token 35816IT, theLength is from one to sixty 35817IT, and the Cardinality is zero or one35818IT.

The attributes of the GDT ChequeStorageInternalID 35800IT are filled asfollows: schemeID—“ChequeStorageID” (implicit), andschemeAgencyID—Business system in which the identifier was assigned

(rrrrrrrrrrrrrrrrrrrr) ExceptionFolderID

A GDT ExceptionFolderID 35800JE is an identifier for an exceptionfolder. For example, an ExceptionFolder may be a folder for storing andgrouping exceptions according to business criteria. The ExceptionFoldermay define the business criteria that an exception must meet to bestored in a particular folder. It may also contain information about theprocessors or users that are registered for the folder. Based on theassignment criteria defined in the exception folder, exceptions can beput into a folder (push) or collected using a folder (pull). Whether afolder is filled by pushing or by pulling exceptions depends on the typeof folder. An example of GDT ExceptionFolderID 35800JE is:

<ExceptionFolderID>RCUE_IN_(—)0001</ExceptionFolderID>

The structure of GDT ExceptionFolderID 35800JE is depicted in FIG.358JE. For the GDT ExceptionFolderID 35800JE, the Object Class isException Folder 35801JE, the Property is Identification 35803JE, theRepresentation/Association is Identifier 35804JE, the Type is CCT35805JE, the Type Name is Identifier 35806JE, and the Length is from oneto forty 35807JE. The remark 35809JE shows that the GDTExceptionFolderID 35800JE may be restricted.

For the SchemeAgencyID 35810JE, the Category is Attribute (A) 35811JE,the Object Class is IdentificationScheme-Agency 35812JE, the Property isIdentification 35813JE, the Representation/Association is Identifier35814JE, the Type is XSD 35815JE, the Type Name is Token 35816JE, theLength is from one to sixty 35817JE, and the Cardinality is zero or one35818JE.

The attributes of ExceptionFolderID are filled as follows: schemeID isan “ExceptionFolderID” (implicit), SchemeAgencyID is a Business systemin which the identifier was defined. The ID of an exception folder isthe unique identifying description of an exception folder.

(ssssssssssssssssssss) ExceptionKeyFigure

A GDT ExceptionKeyFigure 35800JF is a key figure that describes theseriousness of an exception from a business viewpoint. For example, anexception may be a means of reporting problems or errors. The key figureis the result of the calculation or measurement of a deviation from atarget value, where this deviation from a target value is the cause ofthe exception. An example of GDT ExceptionKeyFigure 35800JF is:<ExceptionKeyFigure> <Code>1</Code> <Value> <Percent> 13.5 </Percent></Value> </ExceptionKeyFigure>

The structure of GDT ExceptionKeyFigure 35800JF is depicted in FIG.358JF. For the GDT ExceptionKeyFigure 35800JF, the Object Class isException Key FIG. 35801JF and the Representation/Association is Details35804JF.

For the Code 35810JF, the Category is Element (E) 35811JF, the ObjectClass is Exception Key FIG. 35812JF, the Property is Code 35813JF, theRepresentation/Association is Code 35814JF, the Type is GDT 35815JF, theType Name is ExceptionKeyFigureCode 35816JF, and the Cardinality is one35818JF.

For the Value 35820JF, the Category is Element (E) 35821JF, the ObjectClass is Exception Key FIG. 35822JF, the Property is Value 35823JF, theRepresentation/Association is Value 35824JF, the Type is GDT 35825JF,the Type Name is ExceptionKeyFigureValue 35826JF, and the Cardinality isone 35828JF.

The Code is a coded representation of the key figure, for example,“deviation from target value”. The Value is a Key figure value, whichrepresents the actual value of the key figure.

(tttttttttttttttttttt) ExceptionKeyFigureCode

A GDT ExceptionKeyFigureCode 35800JG is a coded representation of thekey figure that describes the seriousness of an exception from abusiness viewpoint. For example, an exception may be a means ofreporting problems or errors. An example of GDT ExceptionKeyFigureCode35800JG is:

<ExceptionKeyFigureCode>1</ExceptionKeyFigureCode>

The structure of GDT ExceptionKeyFigureCode 35800JG is depicted in FIG.358JG. For the GDT ExceptionKeyFigureCode 35800JG, the Object Class isException 35804JG, the Property is KeyFigure 35806JG, theRepresentation/Association is Code 35808JG, the Type is CCT 35810JG, theType Name is Code 35812JG, and the Length is from one to two 35814JG.The remark 35818JG shows that the GDT ExceptionKeyFigureCode 35800JG maybe restricted.

An example of a coded representation of an exception key figure is“Overload”. The actual key figure of an exception of the type “CapacityOverload in Bucket” that uses this code would then be “Overload by 13%”.This could, for example, be triggered by a resource overload of 13% onresource “XYZ”.

The attributes of the data type GDT ExceptionKeyFigureCode 35800JG areas follows: listID of 10229, listAgencyID of 310, listVersionID is aversion of the relevant code list. The data type GDTExceptionKeyFigureCode 35800JG may use the following codes: 1 (i.e., Keyfigure of an exception for a quantity-based deviation between the actualquantity and the required quantity), 2 (i.e., Key figure of an exceptionfor a deviation of the actual stock quantity from a target stockquantity), 3 (i.e., Key figure of an exception for a capacity overload),4 (i.e., Key figure of an exception for a capacity underload), 5 (i.e.,Exception key figure for the actual utilization), 6 (i.e., Exception keyfigure for a delay in relation to a target date), 7 (i.e., Exception keyfigure for earliness in relation to a target date), 8 (i.e., Exceptionkey figure for a deviation from a required time interval), 9 (i.e.,Exception key figure for a deviation from a required days' supply).

(uuuuuuuuuuuuuuuuuuuu) ExceptionKeyFigureValue

A GDT ExceptionKeyFigureValue 35800JH is a key figure value of anexception from a business viewpoint. For example, an exception may be ameans of reporting problems or errors. The key figure value may be theresult of the calculation or measurement of a deviation from a targetvalue, where this deviation from a target value is the cause of theexception. An example of GDT ExceptionKeyFigureValue 35800JH is:<ExceptionKeyFigureValue> <Percent>13,5</Percent></ExceptionKeyFigureValue>

The structure of GDT ExceptionKeyFigureValue 35800JH is depicted in FIG.358JH. For the GDT ExceptionKeyFigureValue 35800JH, the Object Class isException Key Figure Value 35801JH and the Representation/Association isDetails 35804JH.

For the Quantity 35810JH, the Category is Element (E) 35811JH, theProperty is Quantity 35813JH, the Representation/Association is Quantity35814JH, the Type is GDT 35815JH, the Type Name is Quantity 35816JH, theLength indicates that the number may have thirteen places with sixplaces past the decimal 35817JH, and the Cardinality is zero or one35818JH.

For the Percent 35820JH, the Category is Element (E) 35821JH, theProperty is Percent 35823JH, the Representation/Association is Percent35824JH, the Type is GDT 35825JH, the Type Name is Percent 35826JH, theLength indicates that the number may have ten places with six placespast the decimal 35827JH, and the Cardinality is zero or one 35828JH.

For the Duration 35830JH, the Category is Element (E) 35831JH, theProperty is Duration 35833JH, the Representation/Association is Duration35834JH, the Type is GDT 35835JH, the Type Name is Duration 35836JH, andthe Cardinality is zero or one 35838JH.

The Quantity is the absolute quantity used to describe the seriousnessof an exception. The Percent is the percentage used to describe theseriousness of an exception. The Duration is the time-based deviationused to describe the seriousness of an exception. In someimplementations, at least one element from the set that includesquantity, percentage, or duration must be specified.

(vvvvvvvvvvvvvvvvvvvv) FamilyNamePrefixCode

A GDT FamilyNamePrefixCode 35800JI is a coded representation of one ormore prefix words for the name of a person. An example of GDTFamilyNamePrefixCode 35800JI is:

<FamilyNamePrefixCode>0001</FamilyNamePrefixCode>

The structure of GDT FamilyNamePrefixCode 35800JI is depicted in FIG.358JI. For the GDT FamilyNamePrefixCode 35800JI, the Object Class isPerson 35801JI, the Property is Family Name Prefix 35803JI, theRepresentation/Association is Code 35804JI, the Type is CCT 35805JI, theType Name is Code 35806JI, and the Length is from one to four 35807JI.

For the ListAgencyID 35810JI, the Category is Attribute (A) 35811JI, theObject Class is CodeListAgency 35812JI, the Property is Identification35813JI, the Representation/Association is Identifier 35814JI, the Typeis XSD 35815JI, the Type Name is Token 35816JI, and the Cardinality iszero or one 35818JI.

For the ListVersionID 35820JI, the Category is Attribute (A) 35821JI,the Object Class is CodeList 35822JI, the Property is Version 35823JI,the Representation/Association is Identifier 35824JI, the Type is XSD35825JI, the Type Name is Token 35826JI, and the Cardinality is zero orone 35828JI.

For the ListAgency-SchemeID 35830JI, the Category is Attribute (A)35831JI, the Object Class is CodeListAgency 35832JI, the Property isScheme 35833JI, the Representation/Association is Identifier 35834JI,the Type is XSD 35835JI, the Type Name is Token 35836JI, and theCardinality is zero or one 35838JI.

For the ListAgency-SchemeAgencyID 35840JI, the Category is Attribute (A)35841JI, the Object Class is CodeListAgency 35842JI, the Property isSchemeAgency 35843JI, the Representation/Association is Identifier35844JI, the Type is XSD 35845JI, the Type Name is Token 35846JI, andthe Cardinality is zero or one 35848JI.

There is a code list for the FamilyNamePrefixCode. Customers can createtheir own code list. The attributes for the FamilyNamePrefixCode havethe following values: listID of “10163”, listAgencyID of “310” assignedby the customer for the customer code list, listVersionID is a versionof the relevant code list assigned and administered by the organizationlisted in the ListAgencyID, listAgencySchemeID is the identification ofthe scheme once the organization listed in the listAgencyID isidentified (It is a particular identification scheme for partners,businesses, and members, such as DUNS+4, and so on, of an administeringorganization, such as EAN, DUNS, and SWIFT, that is listed in thelistAgencySchemeAgencyID.), listAgencySchemeAgencyID is a blank for thecode list (otherwise it is the ID of the managing organization, forexample, DUNS, EAN, SWIFT, that is responsible for identification of theorganization listed in the listAgencyID. It may be listed in DE 3055).

The data type FamilyNamePrefixCode is used as part of the name in therepresentation of the name of a person. A FamilyNamePrefixCode canrepresent a title such as ‘von’.

The data type GDT FamilyNamePrefixCode 35800JI may use the followingcodes: 0001 (i.e., von), 0002 (i.e., von der), 0003 (i.e., van), 0004(i.e., van der), 0005 (i.e., da), 0006 (i.e., de), 0007 (i.e., de la),0008 (i.e., dos), 0009 (i.e., du), 0010 (i.e., el).

(wwwwwwwwwwwwwwwwwwww) FloorID

A GDT FloorID 35800JJ is a unique identifier of a floor within abuilding. An example of GDT FloorID 35800JJ is:

<FloorID>3</FloorID>

The structure of GDT FloorID 35800JJ is depicted in FIG. 358JJ. For theGDT FloorID 35800JJ, the Object Class is Floor 35804JJ, the Property isIdentification 35806JJ, the Representation/Association is Identifier35808JJ, the Type is CCT 35810JJ, the Type Name is Identifier 35812JJ,and the Length is from one to ten 35814JJ. The remark 35818JJ shows thatthe GDT FloorID 35800JJ may be restricted.

The FloorID may be unique for each building. The building is known fromthe context. The FloorID is used in address and business partner.

(xxxxxxxxxxxxxxxxxxxx) GenderCode

A GDT GenderCode 35800JK is a coded representation of a person's genderAn example of GDT GenderCode 35800JK is:

<GenderCode>1</GenderCode>

The structure of GDT GenderCode 35800JK is depicted in FIG. 358JK. Forthe GDT GenderCode 35800JK, the Property is Gender 35806JK, theRepresentation/Association is Code 35808JK, the Type is CCT 35810JK, theType Name is Code 35812JK, and the Length is one 35814JK. The remark35818JK shows that the GDT GenderCode 35800JK may be restricted.

The GDT GenderCode 35800JK is assigned exactly one standard code list asper ISO code 5218. The attributes are as follows: listID (‘5218’),listAgencyID (‘5’). The data type GDT GenderCode 35800JK may use thefollowing codes: 1 (i.e., gender is unknown), 2 (i.e., gender is male),3 (i.e., gender is female g), 4 (i.e., gender is not determined).

(yyyyyyyyyyyyyyyyyyyy) GeneralLedgerAccountAliasCode

A GDT GeneralLedgerAccountAliasCode 35800JL is a coded representation ofan alias for a G/L account For example, The alias may represent a G/Laccount independently of a chart of accounts An example of GDTGeneralLedgerAccountAliasCode 35800JL is:

<GeneralLedgerAccountAliasCode>231100</GeneralLedgerAccountAliasCode>

The structure of GDT GeneralLedgerAccountAliasCode 35800JL is depictedin FIG. 358JL. For the GDT GeneralLedgerAccountAliasCode 35800JL, theObject Class is General Ledger Account 35801JL, the Property is Alias35803JL, the Representation/Association is Code 35804JL, the Type is CCT35805JL, the Type Name is Code 35806JL, and the Length is from one toten 35807JL. The remark 35809JL shows that the GDTGeneralLedgerAccountAliasCode 35800JL may be restricted.

For the ListID 35810JL, the Category is Attribute (A) 35811JL, theObject Class is CodeList 35812JL, the Property is Identification35813JL, the Representation/Association is Identifier 35814JL, the Typeis XSD 35815JL, the Type Name is Token 35816JL, and the Cardinality iszero or one 35818JL.

For the ListAgencyID 35820JL, the Category is Attribute (A) 35821JL, theObject Class is CodeListAgency 35822JL, the Property is Identification35823JL, the Representation/Association is Identifier 35824JL, the Typeis XSD 35825JL, the Type Name is Token 35826JL, and the Cardinality iszero or one 35828JL.

For the ListVersionID 35830JL, the Category is Attribute (A) 35831JL,the Object Class is CodeList 35832JL, the Property is Version 35833JL,the Representation/Association is Identifier 35834JL, the Type is XSD35835JL, the Type Name is Token 35836JL, and the Cardinality is zero orone 35838JL.

For the ListAgency-SchemeID 35840JL, the Category is Attribute (A)35841JL, the Object Class is CodeListAgency 35842JL, the Property isScheme 35843JL, the Representation/Association is Identifier 35844JL,the Type is XSD 35845JL, the Type Name is Token 35846JL, and theCardinality is zero or one 35848JL.

For the ListAgency-SchemeAgencyID 35850JL, the Category is Attribute (A)35851JL, the Object Class is CodeListAgency 35852JL, the Property isSchemeAgency 35853JL, the Representation/Association is Identifier35854JL, the Type is XSD 35855JL, the Type Name is Token 35856JL, andthe Cardinality is zero or one 35858JL.

The data type GDT GeneralLedgerAccountAliasCode 35800JL is acustomer-specific code list.

The attributes may be as follows: listID (“10277”), listAgencyID (ID ofthe SAP customer), listVersionID (assigned and managed by the SAPcustomer), listAgencySchemeID (ID of the scheme),listAgencySchemeAgencyID (ID of the organization that manages the schemeof the listAgencySchemeID).

The alias for a G/L account may be used in applications that areexternal to Accounting and in which assignments are to be made directlyto a G/L account, such as in the case of an invoice without orderreference. It simplifies entry because a chart of accounts does not needto be specified and any multiple charts of accounts outside ofAccounting are not made visible.

The assignment to a G/L account (GDT GeneralLedgerAccountReference) andthe representation on accounts of other charts of accounts does notoccur in Accounting until the posting is made.

(zzzzzzzzzzzzzzzzzzzz) IncotermsClassificationCode

A GDT IncotermsClassificationCode 35800JM is a coded representation forthe characterization of delivery conditions for Incoterms. For example,Incoterms may be typical contract formulations for delivery conditionsthat correspond to the rules defined by the International Chamber ofCommerce (ICC). An example of GDT IncotermsClassificationCode 35800JMis:

<IncotermsClassificationCode>FOB </IncotermsClassificationCode>

The structure of GDT IncotermsClassificationCode 35800JM is depicted inFIG. 358JM. For the GDT IncotermsClassificationCode 35800JM, the ObjectClass is Incoterms 35804JM, the Property is Classification 35806JM, theRepresentation/Association is Code 35808JM, the Type is CCT 35810JM, theType Name is Code 35812JM, and the Length is three 35814JM. The remark35818JM shows that the GDT IncotermsClassificationCode 35800JM may berestricted.

One fixed standard code list is assigned to the code. The attributes areas follows: listID (DE4053), listAgencyID (6).

The GDT IncotermsClassificationCode 35800JM is part of the Incoterms.Most codes, with the exception of ‘EXW’ and ‘CPT’, must always be usedtogether with an IncotermsTransferLocation.

The GDT IncotermsClassificationCode 35800JM is used during thedetermination of delivery conditions in Incoterms.

The data type GDT IncotermsClassificationCode 35800JM may use thefollowing codes: EXW (i.e., the transfer of risks to the importer occursdirectly Ex Works of the exporter. The importer transports the goodsentirely at his own costs), FCA (i.e., the transfer of costs and riskstakes place at a place of lading as specified by the importer. The costsfor the main transport are carried by the importer. Applicable for alltransport types), FAS (i.e., the exporter pays the costs up to the quayof the port of lading, and up when the goods are cleared for export. Thetransfer of risks to the importer takes place when the goods are loadedonto the ship. Costs for transport insurance are carried by theimporter. Applicable for maritime and inland shipping), FOB (i.e.,except for the costs, like FAS; the exporter also carries the loadingcosts. The transfer of risks to the importer only occurs when the ship'srail is crossed), CFR (i.e., something) (i.e., the exporter carries allcosts up to when the port of destination is reached. Costs for transportinsurance are carried by the importer. The transfer of risks to theimporter occurs when the ship's rail is crossed/at the port of shipment), CIF (i.e., like CFR, however the exporter carries the costs fortransport insurance), CPT (i.e., the exporter carries all transportcosts for the goods up to the place of destination, as well as the costsfor arranging the export. The importer covers the costs for transportinsurance. The transfer of risks to the importer occurs when the goodsare transferred to the carrier. Applicable for all transport types), CIP(i.e., like CPT, however the exporter carries the costs for transportinsurance), DAF (i.e., the exporter carries the transport costs for theshipment up to a place of destination at the border, as well as forarranging the export. The transfer of risks to the importer occurs atthe border, Applicable for all transport types), DES (i.e., the exportercarries all transport costs up to the port of destination; he alsocarries the costs for transport insurance, if this has been agreed upon.The transfer of risks to the importer occurs as soon as the ship hasreached its port of destination. The importer also pays import duty, andcarries the costs for unloading and subsequent transport. Applicable formaritime and inland shipping), DEQ (i.e., the exporter carries alltransport costs up to the quay of the port of destination; he alsocarries the costs for transport insurance, if this has been agreed upon.The exporter also carries the risks connected with transporting thegoods to the port of destination, and with unloading the goods to thequay. The importer has to clear the goods for import, and is responsiblefor the costs, formalities, duties and taxes that occur as a result),DDU (i.e., the exporter carries the transport costs up to the place ofdestination, the importer pays import duty. The exporter also carriesthe risks up to the place of destination), DDP (i.e., like DDU, howeverthe exporter also pays the import duty).

(aaaaaaaaaaaaaaaaaaaaa) InhouseMailID

A GDT InhouseMailID 35800JM is a unique identifier of a mail depot forpostal shipping within the company An example of GDT InhouseMailID35800JM is:

<InhouseMailID>16</InhouseMailID>

The structure of GDT InhouseMailID 35800JM is depicted in FIG. 358JM.For the GDT InhouseMailID 35800JM, the Object Class is InhouseMail35804JM, the Property is Indentification 35806JM, theRepresentation/Association is Identifier 35808JM, the Type is CCT35810JM, the Type Name is Identifier 35812JM, and the Length is from oneto ten 35814JM. The remark 35818JM shows that the GDT InhouseMailID35800JM may be restricted.

The data type GDT InhouseMailID 35800JM must be unique in the usagecontext.

(bbbbbbbbbbbbbbbbbbbbb) PaymentRegisterGroupingCriterionCode

A GDT PaymentRegisterGroupingCriterionCode 35800JO is a codedrepresentation of a criterion for grouping payments An example of GDTPaymentRegisterGroupingCriterionCode 35800JO is:  <PaymentRegisterGroupingCriterionCode>1</PaymentRegisterGroupingCriterionCode>

The structure of GDT PaymentRegisterGroupingCriterionCode 35800JO isdepicted in FIG. 358JO. For the GDT PaymentRegisterGroupingCriterionCode35800JO, the Object Class is PaymentRegister 35801JO, the Property isGroupingCriterion 35803JO, the Representation/Association is Code35804JO, the Type is CCT 35805JO, the Type Name is Code 35806JO, and theLength is from one to two 35807JO. The remark 35809JO shows that the GDTPaymentRegisterGroupingCriterionCode 35800JO may be restricted.

For the ListAgencyID 35810JO, the Category is Attribute (A) 35811JO, theObject Class is CodeListAgency 35812JO, the Property is Identification35813JO, the Representation/Association is Identifier 35814JO, the Typeis XSD 35815JO, the Type Name is Token 35816JO, and the Cardinality iszero or one 35818JO.

For the ListVersionID 35820JO, the Category is Attribute (A) 35821JO,the Object Class is CodeList 35822JO, the Property is Version 35823JO,the Representation/Association is Identifier 35824JO, the Type is XSD35825JO, the Type Name is Token 35826JO, and the Cardinality is zero orone 35828JO.

For the ListAgency-SchemeID 35830JO, the Category is Attribute (A)35831JO, the Object Class is CodeListAgency 35832JO, the Property isScheme 35833JO, the Representation/Association is Identifier 35834JO,the Type is XSD 35835JO, the Type Name is Token 35836JO, and theCardinality is zero or one 35838JO.

For the ListAgency-SchemeAgencyID 35840JO, the Category is Attribute (A)35841JO, the Object Class is CodeListAgency 35842JO, the Property isSchemeAgency 35843JO, the Representation/Association is Identifier35844JO, the Type is XSD 35845JO, the Type Name is Token 35846JO, andthe Cardinality is zero or one 35848JO.

An extendable SAP code list may be assigned to the GDTPaymentRegisterGroupingCriterionCode 35800JO. SAP customers can changethis code list. In its unchanged state, the SAP code list has thefollowing attributes: listID (“10251”), listAgencyID (“310”),listVersionID (version of the relevant code list).

If an SAP customer makes changes to the SAP code list, the valuesassigned to the attributes change as follows: listAgencyID (ID of theSAP customer), listVersionID (assigned and managed by the SAP customer),listAgencySchemeID (ID of the scheme), listAgencySchemeAgencyID (ID ofthe organization).

A Definition of the GDT PaymentRegisterGroupingCriterionCode 35800JO maybe used to define further grouping criteria in addition to theprocess-specific grouping criteria for payments.

Only existing attributes of the business object PaymentRegister can beused.

Process-specific grouping criteria are grouping criteria that mustalways be considered within a business process for a grouping. Examplesof process-specific grouping criteria for a payment are house bankaccount and payment procedure.

During the grouping of payments, payments that match in all groupingcriteria are summarized.

There can be a default PaymentRegisterGroupingCriterionCode in acompany. An alternative PaymentRegisterGroupingCriterionCode can beentered for individual business partners (for example, a grouping bybusiness origin of the payment at specific customers).

(ccccccccccccccccccccc) PersonNameSupplementCode

A GDT PersonNameSupplementCode 35800JQ is a coded representation of aname supplement An example of GDT PersonNameSupplementCode 35800JQ is:

<PersonNameSupplementCode>0003</PersonNameSupplementCode>

The structure of GDT PersonNameSupplementCode 35800JQ is depicted inFIG. 358JQ. For the GDT PersonNameSupplementCode 35800JQ, the Propertyis Person Name Supplement 35803JQ, the Representation/Association isCode 35804JQ, the Type is CCT 35805JQ, the Type Name is Code 35806JQ,and the Length is from one to four 35807JQ.

For the ListID 35810JQ, the Category is Attribute (A) 35811JQ, theObject Class is CodeList 35812JQ, the Property is Identification35813JQ, the Representation/Association is Identifier 35814JQ, the Typeis XSD 35815JQ, the Type Name is Token 35816JQ, and the Cardinality iszero or one 35818JQ.

For the ListAgencyID 35820JQ, the Category is Attribute (A) 35821JQ, theObject Class is CodeListAgency 35822JQ, the Property is Identification35823JQ, the Representation/Association is Identifier 35824JQ, the Typeis XSD 35825JQ, the Type Name is Token 35826JQ, and the Cardinality iszero or one 35828JQ.

For the ListVersionID 35830JQ, the Category is Attribute (A) 35831JQ,the Object Class is CodeList 35832JQ, the Property is Version 35833JQ,the Representation/Association is Identifier 35834JQ, the Type is XSD35835JQ, the Type Name is Token 35836JQ, and the Cardinality is zero orone 35838JQ.

For the ListAgency-SchemeID 35840JQ, the Category is Attribute (A)35841JQ, the Object Class is CodeListAgency 35842JQ, the Property isScheme 35843JQ, the Representation/Association is Identifier 35844JQ,the Type is XSD 35845JQ, the Type Name is Token 35846JQ, and theCardinality is zero or one 35848JQ.

For the ListAgency-SchemeAgencyID 35850JQ, the Category is Attribute (A)35851JQ, the Object Class is CodeListAgency 35852JQ, the Property isSchemeAgency 35853JQ, the Representation/Association is Identifier35854JQ, the Type is XSD 35855JQ, the Type Name is Token 35856JQ, andthe Cardinality is zero or one 35858JQ.

An extendable SAP code list may be assigned to the data type GDTPersonNameSupplementCode 35856JQ. SAP customers can change this codelist. In its unchanged state, the SAP code list has the followingattributes: listID (“10119”), listAgencyID (“310”),listVersionID(version of the relevant code list)

If an SAP customer makes changes to the SAP code list, the values of theattributes are changed as follows: listAgencyID (ID of the SAPcustomer), listVersionID (assigned and managed by the SAP customer),listAgencySchemeID (ID of the scheme), listAgencySchemeAgencyID (ID ofthe organization that manages the scheme of the listAgencySchemeID).

The data type GDT PersonNameSupplementCode 35856JQ may be used as partof the name in the representation of the name of a person.

The data type GDT PersonNameSupplementCode 35800JQ may use the followingcodes: 0001 (i.e., Graf), 0002 (i.e., Gräfin), 0003 (i.e., Freiherr),0004 (i.e., Freifrau), 0005 (i.e., Earl), 0006 (i.e., Sir), 0007 (i.e.,Member of the Bundestag), 0008 (i.e., Member of the Landtages).

(ddddddddddddddddddddd) POBoxID

A GDT POBoxID 35800JR is a unique identifier of a PO Box For example,something. An example of GDT POBoxID 35800JR is:

<POBoxID>14711</POBoxID>

The structure of GDT POBoxID 35800JR is depicted in FIG. 358JR. For theGDT POBoxID 35800JR, the Object Class is POBox 35804JR, the Property isIdentification 35806JR, the Representation/Association is Identifier35808JR, the Type is CCT 35810JR, the Type Name is Identifier 35812JR,and the Length is from one to ten 35814JR. The remark 35818JR shows thatthe GDT POBoxID 35800JR may be restricted.

A PO Box number may be used as part of the address.

In the GDT POBoxIDCreditCommitmentTypeCode 35800JR, only the number ofthe PO Box is to be entered. The text “PO Box” is determinedlanguage-specifically when the address is printed. The recipientlanguage is used for this purpose.

When the address is printed, a distinction is made between thecategories “Street address” and “PO Box address”. The print programspecifies which category is to take precedence if both values aremaintained in one address record.

Besides the PO Box number, the following fields are taken intoconsideration for the PO Box address: Postcode of the PO Box (if filled,otherwise the normal postcode), City of the PO Box (if filled, otherwisethe normal city), Region of the PO Box (if filled, otherwise the normalregion), Country of the PO Box (if filled, otherwise the normalcountry).

If only the “PO Box” information (without number) applies in theaddress, then the “PO Box” field is not to be filled. Instead, theindicator “PO Box without number” is to be selected. Instead of PO Boxinformation, a company postcode can also be maintained in a special,separate field for organizational addresses.

(eeeeeeeeeeeeeeeeeeeee) PostalCode

A GDT PostalCode 35800JS is a coded representation of a postcode. Anexample of GDT PostalCode 35800JS is:

<PostalCode>69190</PostalCode>

The structure of GDT PostalCode 35800JS is depicted in FIG. 358JS. Forthe GDT PostalCode 35800JS, the Object Class is PostalCode 35804JS, theRepresentation/Association is Code 35808JS, the Type is CCT 35810JS, theType Name is Code 35812JS, and the Length is from one to ten 35814JS.The remark 35818JS shows that the GDT PostalCode 35800JS may berestricted.

The data type GDT PostalCode 35800JS may be used to specify a postcodein an address.

PostalCode can be used to represent different postcodes. There is aunique code list for each country. The code list may use the followingcodes: StreetPostalCode (i.e., postcode of a street address),POBoxPostalCode (i.e., postcode of a PO Box address), CompanyPostalCode(i.e., postcode that is directly assigned to a company).

(fffffffffffffffffffff) PriceSpecificationElementTypeCode

A GDT PriceSpecificationElementTypeCode 35800JT is a codedrepresentation of the type of specification of a price, discount orsurcharge. For example, the GDT PriceSpecificationElementTypeCode35800JT may specify a special percent or absolute discount based on the50th anniversary of a company. An example of GDTPriceSpecificationElementTypeCode 35800JT is:

<PriceSpecificationElementTypeCode>2310</PriceSpecificationElementTypeCode>

The structure of GDT PriceSpecificationElementTypeCode 35800JT isdepicted in FIG. 358JT. For the GDT PriceSpecificationElementTypeCode35800JT, the Object Class is PriceSpecificationElement 35804JT, theProperty is Type 35806JT, the Representation/Association is Code35808JT, the Type is CCT 35810JT, the Type Name is Code 35812JT, and theLength is four 35814JT. The remark 35818JT shows that the GDTPriceSpecificationElementTypeCode 35800JT may be restricted.

The data type GDT PriceSpecificationElementTypeCode 35800JT may use thefollowing codes: 1000 (i.e., specifies a price ), 1010 (i.e., specifiesa special price), 1100 (i.e., specifies a basic price), 1110 (i.e.,specifies a price based on a recommended price), 1120 (i.e., Specifies aprice based on a price requirement), 1200 (i.e., specifies a price basedon special properties of the master data used), 1210 (i.e., specifies aprice based on group membership of the business partner), 1220 (i.e.,specifies a price based on group membership of the product ), 1230(i.e., Specifies a price based on a specific product configuration),1300 (i.e., specifies a price based on a promotion), 1310 (i.e.,specifies a price based on a one-time sales event that is restricted toa certain time period), 1320 (i.e., specifies a price based on arecurring promotion that is restricted to a certain time period), 1400(i.e., specifies a price based on business processes that deviate fromthe business standard ), 1410 (i.e., specifies a price for a quantity ofa product or the total document as a result of exceeding or fallingshort of a value limit), 1420 (i.e., specifies a price for the quantityof a product or the total document as a result of exceeding or fallingshort of a quantity limit), 1430 (i.e., specifies a price for thequantity of a product or the total document as a result of a bindingagreement, for example when ordering or when signing a contract), 2000(i.e., specifies a discount or surcharge), 2010 (i.e., specifies aspecial discount or surcharge), 2100 (i.e., specifies a base valuediscount or surcharge), 2200 (i.e., specifies a discount or surchargebased on special properties of the master data used), 2210 (i.e.,specifies a discount or surcharge based on the group membership of thebusiness partner), 2220 (i.e., specifies a discount or surcharge basedon the group membership of the product), 2230 (i.e., specifies adiscount or surcharge based on product configuration), 2300 (i.e.,specifies a discount or surcharge based on a promotion), 2310 (i.e.,specifies a discount or surcharge based on a one-time sales event thatis restricted to a certain time period), 2320 (i.e., specifies adiscount or surcharge based on a recurring promotion that is restrictedto a certain time period), 2340 (i.e., specifies a discount or surchargebased on a coupon or voucher), 2400 (i.e., Specifies a discount orsurcharge based on business processes that deviate from the businessstandard), 2410 (i.e., specifies a discount or surcharge for thequantity of a product or the total document as a result of exceeding orfalling short of the value limit), 2420 (i.e., specifies a price for aquantity of a product or the total document as a result of exceeding orfalling short of the quantity limit), 2430 (i.e., specifies a discountor surcharge for the quantity of a product or the total document as aresult of a binding agreement, for example when ordering or when signinga contract), 2500 (i.e., specifies a discount or surcharge based onspecial calculative processing), 2510 (i.e., specifies a discount basedon free goods), 2520 (i.e., specifies a discount or surcharge based onthe clearing of rounding differences), 4000 (i.e., specifies transportcosts), 4100 (i.e., specifies packaging), 4200 (i.e., specifies freight), 5100 (i.e., specifies customs duty), 6000 (i.e., specifies specialterms of payment), 6100 (i.e., cash discount).

(ggggggggggggggggggggg) PriceTypeCode

A GDT PriceTypeCode 35800JU is a coded representation of a price typeFor example, the price type may specify the business relevance of aprice An example of GDT PriceTypeCode 35800JU is:

<PriceTypeCode listAgencyID=“310”>1</PriceTypeCode>

The structure of GDT PriceTypeCode 35800JU is depicted in FIG. 358JU.For the GDT PriceTypeCode 35800JU, the Object Class is Price 35804JU,the Property is Type 35806JU, the Representation/Association is Code35808JU, the Type is CCT 35810JU, the Type Name is Code 35812JU, and theLength is from one to three 35814JU. The remark 35818JU shows that theGDT PriceTypeCode 35800JU may be restricted.

For the ListID 35810JU, the Category is Attribute (A) 35811JU, theObject Class is CodeList 35812JU, the Property is Identification35813JU, the Representation/Association is Identifier 35814JU, the Typeis XSD 35815JU, the Type Name is Token 35816JU, and the Cardinality iszero or one 35818JU.

For the ListAgencyID 35820JU, the Category is Attribute (A) 35821JU, theObject Class is CodeListAgency 35822JU, the Property is Identification35823JU, the Representation/Association is Identifier 35824JU, the Typeis XSD 35825JU, the Type Name is Token 35826JU, and the Cardinality iszero or one 35828JU.

For the ListVersionID 35830JU, the Category is Attribute (A) 35831JU,the Object Class is CodeList 35832JU, the Property is Version 35833JU,the Representation/Association is Identifier 35834JU, the Type is XSD35835JU, the Type Name is Token 35836JU, and the Cardinality is zero orone 35838JU.

For the ListAgency-SchemeID 35840JU, the Category is Attribute (A)35841JU, the Object Class is CodeListAgency 35842JU, the Property isScheme 35843JU, the Representation/Association is Identifier 35844JU,the Type is XSD 35845JU, the Type Name is Token 35846JU, and theCardinality is zero or one 35848JU.

For the ListAgency-SchemeAgencyID 35850JU, the Category is Attribute (A)35851JU, the Object Class is CodeListAgency 35852JU, the Property isSchemeAgency 35853JU, the Representation/Association is Identifier35854JU, the Type is XSD 35855JU, the Type Name is Token 35856JU, andthe Cardinality is zero or one 35858JU.

Multiple code lists are allowed for the GDT PriceTypeCode 35800JU. Adefault code list is delivered by SAP. The customer can add other codelists.

The default code list attributes are as follows: listID (“10064”),listAgencyID(“310”), listVersionID (version of the relevant code list).

The data type GDT PriceTypeCode 35800JU may use the following codes: 1(i.e., the price type Material Inventory Price describes the pricedetermined from the inventory value of a MaterialSubledgerAccount), 2(i.e., the price type Material Standard Price describes the materialprice that is used over an extended length of time without beingchanged. This price is usually calculated in standard cost planning andnormally represents a target that should not be exceeded).

The attributes may be used as follows: listID (ID of the relevant codelist. It is assigned and administered by a customer. The customer isresponsible for the values of the ID in question), listAgencyID (The IDof the customer), listVersionID (version of the relevant code list. Thisis assigned and administered by the customer listed in thelistAgencyID), listAgencySchemeID(the ID of the scheme by which thecustomer listed in the listAgencyID is identified. It is a particularidentification scheme for partners, businesses, and members, and so on,of an administering organization that is listed in thelistAgencySchemeAgencyID), listAgencySchemeAgencyID (ID of theadministering organization that is responsible for identifying theorganization listed in the listAgencyID).

Examples of custom codes: Purchase price (price at which a product isprocured), Material price based on commercial code (price at which amaterial is valuated based on the commercial code), Material price basedon tax code (price at which a material is valuated based on the taxcode), Planned price (planned price used to valuate an internalactivity).

(hhhhhhhhhhhhhhhhhhhhh) ProjectTypeCode

A GDT ProjectTypeCode 35800JV is a coded representation of a projecttype For example, the key characteristics of a project type are theprocess category, the scheduling type, permitted project tasks, andpermitted check lists. An example of GDT ProjectTypeCode 35800JV is:

<ProjectTypeCode>DEV_INTERNAL </ProjectTypeCode>

The structure of GDT ProjectTypeCode 35800JV is depicted in FIG. 358JV.For the GDT ProjectTypeCode 35800JV, the Object Class is Project35801JV, the Property is Type 35803JV, the Representation/Association isCode 35804JV, the Type is CCT 35805JV, the Type Name is Code 35806JV,and the Length is from one to fifteen 35807JV. The remark 35809UV showsthat the GDT ProjectTypeCode 35800JV may be restricted.

For the ListAgencyID 35810JV, the Category is Attribute (A) 35811JV, theObject Class is CodeListAgency 35812JV, the Property is Identification35813JV, the Representation/Association is Identifier 35814JV, the Typeis XSD 35815JV, the Type Name is Token 35816JV, and the Cardinality iszero or one 35818JV.

For the ListVersionID 35820JV, the Category is Attribute (A) 35821JV,the Object Class is CodeList 35822JV, the Property is Version 35823JV,the Representation/Association is Identifier 35824JV, the Type is XSD35825JV, the Type Name is Token 35826JV, and the Cardinality is zero orone 35828JV.

For the ListAgency-SchemeID 35830JV, the Category is Attribute (A)35831JV, the Object Class is CodeListAgency 35832JV, the Property isScheme 35833JV, the Representation/Association is Identifier 35834JV,the Type is XSD 35835JV, the Type Name is Token 35836JV, and theCardinality is zero or one 35838JV.

For the ListAgency-SchemeAgencyID 35840JV, the Category is Attribute (A)35841JV, the Object Class is CodeListAgency 35842JV, the Property isSchemeAgency 35843JV, the Representation/Association is Identifier35844JV, the Type is XSD 35845JV, the Type Name is Token 35846JV, andthe Cardinality is zero or one 35848JV. A customer-specific code listmay be assigned to the data type GDT ProjectTypeCode 35800JV. An SAPcustomer defines the codes in the code list.

Values may be assigned to the attributes of data type GDTProjectTypeCode 35800JV as follows: listID (“10223”), listAgencyID (IDof the SAP customer), listVersionID (assigned and managed by the SAPcustomer), listAgencySchemeID (ID of the scheme),listAgencySchemeAgencyID (ID of the organization that manages the schemeof the listAgencySchemeID).

Examples of customer-specific code semantics: Research project (researchinto a new product), Investment project (construction of a dam),Consultancy project (provision of support during the course of a largerproject), Organizational project (planning of major events), Developmentproject (development of a new software application), Servicing project(maintenance of technical assets).

(iiiiiiiiiiiiiiiiiiiii) PurchaseLedgerAccountTypeCode

A GDT PurchaseLedgerAccountTypeCode 35800JW is a coded representation ofthe type of a PurchaseLedgerAccount For example, the GDTPurchaseLedgerAccountTypeCode 35800JW may be a record of quantities andvalues that are relevant to valuation for business processes in whichmaterial goods or services are procured. This record serves the purposeof proper financial reporting of the inventory or profit and lossstatement of a company. An example of GDT PurchaseLedgerAccountTypeCode35800JW is:

<PurchaseLedgerAccountTypeCode>1</PurchaseLedgerAccountTypeCode>

The structure of GDT PurchaseLedgerAccountTypeCode 35800JW is depictedin FIG. 358JW. For the GDT PurchaseLedgerAccountTypeCode 35800JW, theObject Class is PurchaseLedgerAccount 35804JW, the Property is Type35806JW, the Representation/Association is Code 35808JW, the Type is CCT35810JW, the Type Name is Code 35812JW, and the Length is from one totwo 35814JW. The remark 35818JW shows that the GDTPurchaseLedgerAccountTypeCode 35800JW may be restricted.

The attributes may be as follows: listID (“10212”), listAgencyID(“310”), listVersionID (Version of the respective code list).

The data type GDT PurchaseLedgerAccountTypeCode 35800JW may use thefollowing codes: 1 (i.e., a PurchasingObject is a purchase ledger whoserecord refers to a business transaction document of Purchasing (purchaseorder, purchasing contract)), 2 (i.e., a PurchasingSegment is a purchaseledger whose record refers to a section of the procurement process. ThePurchasingSegment represents an accounting view of procurement processesthat were not posted for a business transaction document of Purchasing.This section is defined by product and supplier characteristics (such asproduct and supplier) and organizational characteristics).

(jjjjjjjjjjjjjjjjjjjjj) AccountDeterminationIncomeGroupCode

A GDT AccountDeterminationIncomeGroupCode 35800KG is the codedrepresentation of a group of revenues from the perspective of anidentical or similar determination of an account in accounting. For thepurposes of proper financial reporting, the value-based representationof business transactions in accounting must use different accounts. Anexample of the GDT AccountDeterminationIncomeGroupCode 35800KG is:<AccountDeterminationIncomeGroupCode>10</AccountDeterminationIncomeGroupCode>

The structure of GDT AccountDeterminationIncomeGroupCode 35800KF isdepicted in FIG. 358KF. For the GDT AccountDeterminationIncomeGroupCode35800KF, the Object Class term Qualifier is Account Determination35802KF, the Object Class term is Income Group 35804KF, theRepresentation/Association term is Code 35806KF, the Type term is CCT35808KF, the Type Name term is Code 35810KF, and the Length is from oneto four 35812KF. The GDT AccountDeterminationIncomeGroupCode 35800KF maybe restricted 35814KF.

In some variations, a customer-specific code list can be assigned to thecode. The customer can define the codes in the code list. As an example,the attributes of the code may include assigned values as follows:

listID=“10400”

listAgencyID—ID of the customer

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme

listAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID

In some implementations, the GDT AccountDeterminationIncomeGroupCode35800KF is used in the business object models and in A2A messages. Someexamples of possible codes are Revenue from employee sales and Revenuefrom sale of old PCs.

(kkkkkkkkkkkkkkkkkkkkk) AccountingClosingStepCode

A GDT AccountingClosingStepCode 35800KG is the coded representation of astep in an accounting closing. Closing in accounting describes aconsolidated status on the key date in the books in accounting. Closingis divided into steps that are processed in a logical order from thebusiness view. An example of the GDT AccountingClosingStepCode 35800KGis:

<AccountingClosingStepCode>10</AccountingClosingStepCode>

The structure of GDT AccountingClosingStepCode 35800KG is depicted inFIG. 358KG. For the GDT AccountingClosingStepCode 35800KG, the ObjectClass term is Accounting Closing Step 35802KG, theRepresentation/Association term is Code 35804KG, the Type term is CCT35806KG, the Type Name term is Code 35808KG, and the Length is from oneto fifteen 35810KG. The AccountingClosingStepCode 35800KG may berestricted 35812KG.

In some variations, the AccountingClosingStepCode 35800KG is acustomer-specific code list. For example, the attribute “listID” can befilled implicitly with “10109.” The AccountingClosingStepCode 35800KGmay not currently be used in A2A or B2B messages.

The definition of a step in closing is meant byAccountingClosingStepCode 35800KG and not an “instance”, that is, not aconcrete posting in a concrete closing.

Some examples of customer-specific codes includes posting of adepreciation posting run as a closing process of theperiod/quarter/fiscal year, posting of a material price valuation as aclosing process of the period/quarter/fiscal year, posting of aregrouping of receivables and payables as a closing process of theperiod/quarter/fiscal year, posting of an assessment as a closingprocess of the period/quarter/fiscal year, and manual correction by thehead of accounting at the end of the period, for example, manualaccrual.

In some implementations, an initial AccountingClosingStepCode 35800KGrepresents a business transaction that takes place outside Accounting,for example, invoice issue or receipt, goods issue or receipt.

(lllllllllllllllllllll) InspectionContainerTypeCode

A GDT InspectionContainerTypeCode 35800KH is the coded representation ofthe container in which the inspection sample is transported and storedfor inspection purposes. An example of GDT InspectionContainerTypeCode35800KH is:

<InspectionContainerTypeCode>1</InspectionContainerTypeCode>

The structure of GDT InspectionContainerTypeCode 35800KH is depicted inFIG. 358KH. The GDT InspectionContainerTypeCode 35800KH includesattributes listAgencyID 35814KH, listVersionID 35830KH,listAgencySchemeID 35846KH, and listAgencySchemeAgencyID 35862KH. Forthe GDT InspectionContainerTypeCode 35800KH, the Object Class term isInspection 35802KH, the Representation/Association term is Code 35804KH,the Type term is xsd 35806KH, the Type Name term is token 35808KH, andthe Length is from one to fifteen 35810KH. TheInspectionContainerTypeCode 35800KH may be restricted 35812KH.

For the listAgencyID 35814KH, the Category is Attribute 35816KH, theObject Class term is CodeListAgency 35818KH, the Property term isIdentification 35820KH, the Representation/Association term isIdentifier 35822KH, the Type term is xsd 35824KH, and the Type Name termis token 35826KH. The cardinality between the listAgencyID 35814KH andthe GDT InspectionContainerTypeCode 35800KH is either zero or one35828KH.

For the listVersionID 35830KH, the Category is Attribute 35832KH, theObject Class term is CodeList 35834KH, the Property term is Version35836KH, the Representation/Association term is Identifier 35838KH, theType term is xsd 35840KH, and the Type Name term is token 35842KH. Thecardinality between the listVersionID 35830KH and the GDTInspectionContainerTypeCode 35800KH is either zero or one 35844KH.

For the listAgencySchemeID 35846KH, the Category is Attribute 35848KH,the Object Class term is CodeListAgency 35850KH, the Property term isScheme 35852KH, the Representation/Association term is Identifier35854KH, the Type term is xsd 35856KH, and the Type Name term is token35858KH. The cardinality between the listAgencySchemeID 35862KH and theGDT InspectionContainerTypeCode 35800KH is either zero or one 35860KH.

For the listAgencySchemeAgencyID 35862KH, the Category is Attribute35864KH, the Object Class term is CodeListAgency 35866KH, the Propertyterm is Scheme 35868KH, the Representation/Association term isIdentifier 35870KH, the Type term is xsd 35872KH, and the Type Name termis token 35874KH. The cardinality between the listAgencySchemeAgencyID35862KH and the GDT InspectionContainerTypeCode 35800KH is either zeroor one 35876KH.

The attributes of Code are assigned values as follows:

listID=“10402”

listAgencyID—ID of the SAP customer (ID from DE 3055 if listed there)

listVersionID—Assigned and managed by the SAP customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of the organization (taken from DE 3055)that manages the scheme of the listAgencySchemeID

The InspectionContainerTypeCode can, for example, be used to describetransport containers for samples in the context of a materialinspection. In some variations, the InspectionContainerTypeCode 35800KHis represented by the following dictionary objects: Data element:QIE_TV_CONTAINER_ID.

(mmmmmmmmmmmmmmmmmmmmm) InspectionDecisionCode

An InspectionDecisionCode 35800KI is the coded representation of thedecision that is made as part of an inspection regarding the acceptanceor rejection of the inspected object. An example of theInspectionDecisionCode 35800KI is:

<InspectionDecisionCode>1</InspectionDecisionCode>

The structure of GDT InspectionDecisionCode 35800KI is depicted in FIG.358KI. The GDT InspectionDecisionCode 35800KI includes attributeslistAgencyID 35814KI, listVersionID 35830KI, listAgencySchemeID 35846KI,and listAgencySchemeAgencyID 35862KI. For the GDT InspectionDecisionCode35800KI, the Object Class term is Inspection 35802KI, theRepresentation/Association term is Code 35804KI, the Type term is xsd35806KI, the Type term is token 35808KI, the Type Name term is Code35810KI, and the Length is from one to fifteen 35810KI. TheInspectionDecisionCode 35800KI may be restricted 35812KI.

For the listAgencyID 35814KI, the Category is Attribute 35816KI, theObject Class term is CodeListAgency 35818KI, the Property term isIdentification 35820KI, the Representation/Association term isIdentifier 35822KI, the Type term is xsd 35824KI, and the Type Name termis token 35826KI. The cardinality between the listAgencyID 35814KI andthe GDT InspectionDecisionCode 35800KI is either zero or one 35828KI.

For the listVersionID 35830KI, the Category is Attribute 35832KI, theObject Class term is CodeList 35834KI, the Property term is Version35836KI, the Representation/Association term is Identifier 35838KI, theType term is xsd 35840KI, and the Type Name term is token 35842KI. Thecardinality between the listVersionID 35830KI and the GDTInspectionDecisionCode 35800KI is either zero or one 35844KI.

For the listAgencySchemeID 35846KI, the Category is Attribute 35848KI,the Object Class term is CodeListAgency 35850KI, the Property term isScheme 35852KI, the Representation/Association term is Identifier35854KI, the Type term is xsd 35856KI, and the Type Name term is token35858KI. The cardinality between the listAgencySchemeID 35862KI and theGDT InspectionDecisionCode 35800KI is either zero or one 35860KI.

For the listAgencySchemeAgencyID 35862KI, the Category is Attribute35864KI, the Object Class term is CodeListAgency 35866KI, the Propertyterm is Scheme 35868KI, the Representation/Association term isIdentifier 35870KI, the Type term is xsd 35872KI, and the Type Name termis token 35874KI. The cardinality between the listAgencySchemeAgencyID35862KI and the GDT InspectionDecisionCode 35800KI is either zero or one35876KI.

As an example, the attributes of Code can be assigned values as follows:

listID=“10403”

listAgencyID—ID of the customer

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of the organization (taken from DE 3055)that manages the scheme of the listAgencySchemeID

The GDT InspectionDecisionCode 35800KI can, for example, be used in thecontext of a material inspection. This code is used to document thedecision about whether the inspected material is accepted or rejectedfor the further production process.

Some examples of customer-specific code semantics are:

“OK”—Accepted

“OK with Restrictions”—Accepted with restrictions

“Not OK”—Rejected, material should not be used

(nnnnnnnnnnnnnnnnnnnnn) InspectionDecisionCodeListID

A GDT InspectionDecisionCodeListID 35800KJ is an identifier for a listof codes that are used to valuate the inspection object. AnInspectionDecisionCodeList is a list of codes that are valid for adecision in an inspection regarding the acceptance or rejection of theinspected object. An example of the GDT InspectionDecisionCodeListID35800KJ is:

<InspectionDecisionCodeListID>123456789012345</InspectionDecisionCodeListID>

The structure of GDT InspectionDecisionCodeListID 35800KJ is depicted inFIG. 358KJ. The GDT InspectionDecisionCodeListID 35800KJ includesattributes SchemeID 35816KJ and SchemeAgencyID 35834KJ. For the GDTInspectionDecisionCodeListID 35800KJ, the Object Class term isInspection Decision Code List 35802KJ, the Property term isIdentification 35804KJ, the Representation/Association term isIdentifier 35806KJ, the Type term is CCT 35808KJ, the Type Name term isIdentifier 35810KJ, and the Length is from one to fifteen 35812KJ. TheGDT InspectionDecisionCodeListID 35800KJ may be restricted 35814KJ.

For the SchemeID 35816KJ, the category is attribute 35818KJ, the ObjectClass is Identification Scheme 35820KJ, the Property term isIdentification 35822KJ, the Representation/Association term isIdentifier 35824KJ, the Type term is xsd 35826KJ, the Type Name term istoken 35828KJ, and the Length is from one to sixty 35830KJ. Thecardinality between the SchemeID 35816KJ and the GDTInspectionDecisionCodeListID 35800ID is either zero or one 35832KJ.

For the SchemeAgencyID 35834KJ, the category is attribute 35836KJ, theObject Class is Identification Scheme Agency 35838KJ, the Property termis Identification 35840KJ, the Representation/Association term isIdentifier 35842KJ, the Type term is xsd 35844KJ, the Type Name term istoken 358646KJ, and the Length is from one to sixty 35848KJ. Thecardinality between the SchemeAgencyID 35834KJ and the GDTInspectionDecisionCodeListID 35800ID is either zero or one 35850KJ.

The attributes of InspectionDecisionCodeListID are filled as follows:

schemeID=InspectionDecisionCodeList<Qualifier>ID

schemeAgencyID: Business system in which the identifier was assigned.

In some examples, the GDT InspectionDecisionCodeListID 35800KK canidentify a list of decision codes in a material inspection.

(ooooooooooooooooooooo) InspectionDynamicModificationCriterionCode

The GDT InspectionDynamicModificationCriterionCode 35800KK is the codedrepresentation of a dynamic modification criterion used for the dynamicmodification of an inspection. The dynamic modification criteriondetermines the properties according to which inspections are dynamicallymodified. A dynamic modification criterion can, for example, define thatthe properties color of a bottle and volume of a bottle are used in thedynamic modification of the inspection. An example (Instance) of the GDTInspectionDynamicModificationCriterionCode 35800KK is:

<InspectionDynamicModificationCriterionCode>DMODCRIT01</InspectionDynamicModificationCriterionCode>

The structure of GDT InspectionDynamicModificationCriterionCode 35800KKis depicted in FIG. 358KK. For the GDTInspectionDynamicModificationCriterionCode 35800KK, the Object Classterm is Inspection Dynamic Modification Criterion 35802KK, theRepresentation/Association term is Code 35804KK, the Type term is CCT35806KK, the Type Name term is Code 35808KK, and the Length is from oneto fifteen 35810KK. The GDT InspectionDynamicModificationCriterionCode35800KK may be restricted 35812KK.

In some variations, a customer-specific code list can be assigned to theGDT InspectionDynamicModificationCriterionCode 35800KK. For example, acustomer can define the codes in the code list. As an example, theattributes of the GDT InspectionDynamicModificationCriterionCode 35800KKmay be assigned values as follows:

listID—ID of a relevant code list.

listAgencyID—ID of a customer

listVersionID—Assigned and managed by a customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of an organization that managed the schemeof the listAgencySchemeID

The InspectionModificationCriterionCode 35800KK is used as a key fordifferentiating the quality level in the context of an inspection. Someexamples of codes are: DMODCRIT01 Dynamic modification related tomaterial DMODCRIT02 Dynamic modification related to material and vendorDMODCRIT03 Dynamic modification related to material and customer

(ppppppppppppppppppppp) InspectionLevelCode

The GDT InspectionLevelCode 35800KL is the coded representation of aninspection level. In a sampling inspection using a sampling scheme inaccordance with DIN ISO 2859, the inspection level is a factor in thedetermination of the sample size based on the quantity (lot quantity)that is to be inspected. For the same inspection quantity, a lowinspection level will usually give rise to a sample size in the lowerrange, a higher inspection level will give rise to a sample size in thehigher range. An example (Instance) of the GDT InspectionLevelCode35800KL is:

<InspectionLevelCode>3</InspectionLevelCode>

The structure of GDT InspectionLevelCode 35800KL is depicted in FIG.358KL. For the GDT InspectionLevelCode 35800KL, the Object Class term isInspection 35802KL, the Property term is Level 35804KL, theRepresentation/Association term is Code 35806KL, the Type term is CCT35808KL, the Type Name term is Code 35810KL, and the Length is one35812KL. The GDT InspectionLevelCode 35800KL may be restricted 35814KL.

The GDT InspectionLevelCode 35800KL can include one fixed code list. Forexample, the attributes may contain the following values:

-   -   listID=“10098”    -   listAgencyID=“310”    -   listVersionID—Version of the relevant code list.

The values of this code list are based on the DIN ISO standard 2859. Thestandard does not contain a code list for this purpose.

The GDT InspectionLevelCode 35800KL can be used in the context of aninspection and provides information regarding the inspection level basedon DIN ISO 2859. For inspection level S-1, the sample size tends to bethe lowest and for inspection level III it tends to be the highest.

In some variations, the GDT InspectionLevelCode 35800KL can berepresented by the following dictionary objects:

Data element: QIE_TV_INSP_LEVEL

Domain: QIE_INSP_LEVEL

An example code list can be described by the following table: Code NameDescription 1 Inspection level S-1 Name of the inspection level S-1according to DIN ISO 2859 2 Inspection level S-2 Name of the inspectionlevel S-2 according to DIN ISO 2859 3 Inspection level S-3 Name of theinspection level S-3 according to DIN ISO 2859 4 Inspection level S-4Name of the inspection level S-4 according to DIN ISO 2859 5 Inspectionlevel I Name of the inspection level I according to DIN ISO 2859 6Inspection level II Name of the inspection level II according to DIN ISO2859 7 Inspection level III Name of the inspection level III accordingto DIN ISO 2859

(qqqqqqqqqqqqqqqqqqqqq) InspectionQualityLevelHistoryItemTypeCode

The GDT InspectionQualityLevelHistoryItemTypeCode 35800KM is the codedrepresentation of a type of history item of a quality level. A historyitem describes an event that has affected the history of a qualitylevel, and has led to a change in the quality level. A quality levelrepresents the current state of inspection effort reduction forinspections of the same type and specifies the inspection stage for thenext inspection of the same type. Inspections of the same type areinspections that have, for example, the same combination of material andsupplier for material deliveries. An example of the GDTInspectionQualityLevelHistoryItemTypeCode 35800KM is:

<InspectionQualityLevelHistoryItemTypeCode>2</InspectionQualityLevelHistoryItemTypeCode>

The structure of GDT InspectionQualityLevelHistoryItemTypeCode 35800KMis depicted in FIG. 358KM. For the GDTInspectionQualityLevelHistoryItemTypeCode 35800KM, the Object Class termis Inspection Quality Level History Item 35802KM, the Property term isType 35804KM, the Representation/Association term is Code 35806KM, theType term is CCT 35808KM, the Type Name term is Code 35810KM, and theLength is one 35812KM. The GDT InspectionQualityLevelHistoryItemTypeCode35800KM may be restricted 35814KM.

In some implementations, one fixed code list can be assigned to the GDTInspectionQualityLevelHistoryItemTypeCode 35800KM. An example of theattributes may be as follows:

SAP Code List:

listID=10387

listAgencyID=“310”

For a quality level in the context of an inspection, the GDTInspectionQualityLevelHistoryItemTypeCode 35800KM can differentiate, forexample, between three history item types that affect the progression ofthe quality level. The history allows you to make projections regardingthe future progression of the quality level, and to depict the processof inspection effort reduction.

An example of a code list can be defined as: Code Name Description 1Intervention Intervention to adjust the quality level 2 Newly CreatedInspection A new inspection has been created. 3 Inspection DecisionDecision regarding the acceptance or rejection of the inspectionquantity for further use

(rrrrrrrrrrrrrrrrrrrrr) InspectionRuleComponentCode

The GDT InspectionRuleComponentCode 35800KN is the coded representationof a component of an inspection rule. An inspection rule (businessobject inspection rule) contains the specifications for the inspection.The inspection is used to check whether an object or procedure meetspredefined requirements. A component of the inspection rule is onesingle specification in the inspection rule. An example of the GDTInspectionRuleComponentCode 35800KN is:

<InspectionRuleComponentCode>2</InspectionRuleComponentCode>

The structure of GDT InspectionRuleComponentCode 35800KN is depicted inFIG. 358KN. The GDT InspectionRuleComponentCode 35800KN includesattributes listAgencyID 35814KN, listVersionID 35830KN,listAgencySchemeID 35846KN, and listAgencySchemeAgencyID 35862KN. Forthe GDT InspectionRuleComponentCode 35800KN, the Object Class term isInspection Rule Component 35802KN, the Representation/Association termis Code 35804KN, the Type term is xsd 35806KN, the Type term is token35808KN, the Type Name term is Code 35810KN, and the Length is from oneto three 35810KN. The InspectionRuleComponentCode 35800KN may berestricted 35812KN.

For the listAgencyID 35814KN, the Category is Attribute 35816KN, theObject Class term is CodeListAgency 35818KN, the Property term isIdentification 35820KN, the Representation/Association term isIdentifier 35822KN, the Type term is xsd 35824KN, and the Type Name termis token 35826KN. The cardinality between the listAgencyID 35814KN andthe GDT InspectionRuleComponentCode 35800KN is either zero or one35828KN.

For the listVersionID 35830KN, the Category is Attribute 35832KN, theObject Class term is CodeList 35834KN, the Property term is Version35836KN, the Representation/Association term is Identifier 35838KN, theType term is xsd 35840KN, and the Type Name term is token 35842KN. Thecardinality between the listVersionID 35830KN and the GDTInspectionRuleComponentCode 35800KN is either zero or one 35844KN.

For the listAgencySchemeID 35846KN, the Category is Attribute 35848KN,the Object Class term is CodeListAgency 35850KN, the Property term isScheme 35852KN, the Representation/Association term is Identifier35854KN, the Type term is xsd 35856KN, and the Type Name term is token35858KN. The cardinality between the listAgencySchemeID 35862KN and theGDT InspectionRuleComponentCode 35800KN is either zero or one 35860KN.

For the listAgencySchemeAgencyID 35862KN, the Category is Attribute35864KN, the Object Class term is CodeListAgency 35866KN, the Propertyterm is Scheme 35868KN, the Representation/Association term isIdentifier 35870KN, the Type term is xsd 35872KN, and the Type Name termis token 35874KN. The cardinality between the listAgencySchemeAgencyID35862KN and the GDT InspectionRuleComponentCode 35800KN is either zeroor one 35876KN.

In some variations, an extendable code list can be assigned to the GDTInspectionRuleComponentCode 35800KN. Customers can change this codelist. In its unchanged state, the assigned code list has, as an example,the following attributes:

listID=“10164”

listAgencyID=“310”

listVersionID=Version of the relevant code list.

If a customer makes changes to the assigned code list, the valuesassigned to the attributes change as follows:

listAgencyID—ID of the customer

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not taken

listAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID

The GDT InspectionRuleComponentCode 35800KN is used to identify theindividual components of an inspection rule. An example forcustomer-specific code semantics is an InspectionRuleSampleDrawingTool,which is a tool for taking samples.

An example of a code list is presented in the following table: Code NameDescription 1 InspectionRuleInspectionScopeCode Inspection scope 2InspectionRuleInspectionDynamicModificationRuleCode Dynamic modificationrule 3 InspectionRuleInspectionDynamicModificationCriterion Dynamicmodification criterion 4InspectionRuleQualityInspectionDecisionCodeListID Decision code list 5InspectionRuleInspectionSampleSizeDeterminationCode Type ofdetermination used for the sample size 6InspectionRuleSampleSizeNumberValue Specified sample size 7InspectionRuleSampleSizePercent Sample size as a percentage of the totalquantity 8 InspectionRuleSampleQuantity Sample quantity that can bedivided up into several primary or reserve samples 9InspectionRuleSampleQuantityPercent Sample quantity as a percentage ofthe total quantity 10 InspectionRuleMaximumAcceptedDefectsIntegerValueMaximum acceptable number of nonconforming units or defects 11InspectionRuleMaximumAcceptedDefectsPercent Maximum acceptablepercentage of nonconforming units or defects in an inspection 12InspectionRuleSamplingSchemeCode Sampling scheme 13InspectionRuleInspectionLevelCode Inspection level 14InspectionRuleInspectionSeverityCode Inspection severity 15InspectionRuleAcceptableQualityLevelNumeric Acceptable quality level 16InspectionRuleSampleSizeQuantityCalculationRuleName Individual rule fordetermining the sample size 17InspectionRuleInspectionResultValuationTypeCode Valuation type for theinspection result 18InspectionRuleSubsetQualityInspectionDecisionCodeListID List ofinspection decision codes for a subset 19InspectionRuleQualityInspectionSampleTypeCode Sample type 20InspectionRuleSampleDrawingProcedureUUID Sample-drawing procedure 21InspectionRuleSampleDrawingUnitUUID Sample-drawing unit 22InspectionRuleSampleQualityInspectionDecisionCodeListID List ofinspection decision codes for samples 23 InspectionRuleFindingTypeCodeFinding type

(sssssssssssssssssssss)

InspectionSampleCategoryCode

The GDT InspectionSampleCategoryCode 35800KO is the coded representationof the category of a sample in the context of an inspection. An exampleof the GDT InspectionSampleCategoryCode 35800KO is:

<InspectionSampleCategoryCode>1</InspectionSampleCategoryCode>

The structure of GDT InspectionSampleCategoryCode 35800KO is depicted inFIG. 358KO. The GDT InspectionSampleCategoryCode 35800KO includesattributes listversionID 35814KO, listVersionID 35830KO,listAgencySchemeID 35846KO, and listAgencySchemeAgencyID 35862KO. Forthe GDT InspectionSampleCategoryCode 35800KO, the Object Class term isInspection Rule Component 35802KO, the Representation/Association termis Code 35804KO, the Type term is xsd 35806KO, the Type term is token35808KO, the Type Name term is Code 35810KO, and the Length is from oneto three 35810KO. The InspectionSampleCategoryCode 35800KO may berestricted 35812KO.

For the listVersionID 35814KO, the Category is Attribute 35816KO, theObject Class term is CodeListAgency 35818KO, the Property term isVersion 35820KO, the Representation/Association term is Identifier35822KO, the Type term is xsd 35824KO, and the Type Name term is token35826KO. The cardinality between the listVersionID 35814KO and the GDTInspectionSampleCategoryCode 35800KO is either zero or one 35828KO.

In some implementations, one fixed code list may be assigned to thecode. For example, the attributes may be as follows:

listID=“10404”

listAgencyID=“310”

listVersionID=Version of the relevant code list.

In the context of a material inspection, theInspectionSampleCategoryCode 35800KO can define whether a sample is aprimary sample, pooled sample, or reserve sample. An example of a codelist for the GDT InspectionSampleCategoryCode 35800KO is: Code NameDescription 1 Primary Sample Sample that is taken directly from thematerial to be examined 2 Pooled Sample Sample that consists of amixture of at least two primary samples 3 Reserve Sample Sample thatmust be stored for a specific time period for documentation purposes

(ttttttttttttttttttttt) InspectionSeverityCode

The GDT InspectionSeverityCode 35800KP is the coded description of aninspection severity. In a sampling inspection using a sampling schemeaccording to DIN ISO 2859, the sample size is determined based on theinspection severity, the inspection level, and the quantity to beinspected (lot size). If the inspection is not a sampling inspectionaccording to DIN ISO 2859, the sample size is determined directly basedon the inspection severity and the quantity to be inspected (lot size).In this case, the inspection level is not taken into consideration. Theinspection severity is used to adjust the sample size. A reducedinspection severity gives rise to a smaller sample size, a tightenedinspection severity gives rise to a larger sample size. An example(Instance) of the GDT InspectionSeverityCode 35800KP is:

<InspectionSeverityCode>2</InspectionSeverityCode>

The structure of GDT InspectionSeverityCode 35800KP is depicted in FIG.358KP. For the GDT InspectionSeverityCode 35800KP, the Object Class termis Inspection 35802KP, the Property term is Severity 35804KP, theRepresentation/Association term is Code 35806KP, the Type term is CCT35808KP, the Type Name term is Code 35810KP, and the Length is one35812KP. The GDT InspectionSeverityCode 35800KP may be restricted35814KP.

The GDT InspectionSeverityCode 35800KP may include one fixed code list.Since this is a fixed code list, no attributes are needed. In somevariations, the attributes contains the following values:

listID=“10099”

listAgencyID=“310”

listVersionID—Version of the relevant code list.

The InspectionSeverityCode 35800KP is used in the context of inspectionsand provides information about the inspection severity based on DIN ISO2859. An exemplary code list is presented as follows: Code NameDescription 1 Normal Normal inspection according to ISO 2859 2 TightenedTightened inspection according to ISO 2859 3 Reduced Reduced inspectionaccording to ISO 2859

(uuuuuuuuuuuuuuuuuuuuu) AmountTolerance

A GDT AmountTolerance 35800KQ is the acceptable deviation between anexpected and an actual monetary amount. An example (Instance) of the GDTAmountTolerance 35800KQ is:   <LowerVarianceAmountCurrencyCode=“EUR”>5 </LowerVarianceAmount>   <LowerVarianceAmountUnlimitedIndicator>false </LowerVarianceAmountUnlimitedIndicator>   <UpperVarianceAmount currencyCode=“EUR”>10 </UpperVarianceAmount>  <UpperVarianceAmountUnlimitedIndicator>false </UpperVarianceAmountUnlimitedIndicator>  <LowerVariancePercent>3.5</LowerVariancePercent>  <UpperVariancePercent>4</UpperVariancePercent>  <UpperVariancePercentUnlimitedIndicator>false</UpperVariancePercentUnlimitedIndicator>  </AmountTolerance>

The structure of the GDT AmountTolerance 35800KQ is depicted in FIG.358KQ. The GDT AmountTolerance 35800KQ includes a Lower Variance Amount35806KQ, a Lower Variance Amount Unlimited indicator 35822KQ, an UpperVariance Amount 35838KQ, and an Upper Variance Amount UnlimitedIndicator 35854KQ, and a Lower Variance Percent 35870KQ. For the GDTAmountTolerance 35800KQ, the Object Class term is Amount Tolerance35802KQ and the Representation/Association term is Details 35804KQ.

For the Lower Variance Amount 35806KQ, the Category is Element 35806KQ,the Object Class term is Amount Tolerance 35810KQ, the PropertyQualifier term is Lower 35812KQ, the Property term is Variance 35814KQ,the Representation/Association Qualifier term is Amount 35816KQ, theType term is GDT 35818KQ, and the Type Name term is Amount 35820KQ. Thecardinality between the Lower Variance Amount 35806KQ and the GDTAmountTolerance 35800KQ is either zero or one 35821KQ.

For the Lower Variance Amount Unlimited indicator 35822KQ, the Categoryis Element 35824KQ, the Object Class term is Amount Tolerance 35826KQ,the Property Qualifier term is Lower Variance Amount 35828KQ, theProperty term is Unlimited 35830KQ, the Representation/AssociationQualifier term is Indicator 35832KQ, the Type term is GDT 35834KQ, andthe Type Name term is Indicator 35836KQ. The cardinality between theLower Variance Amount Unlimited indicator 35822KQ and the GDTAmountTolerance 35800KQ is either zero or one 35837KQ.

For the Upper Variance Amount 35838KQ, the Category is Element 35840KQ,the Object Class term is Amount Tolerance 35842KQ, the PropertyQualifier term is Upper 35844KQ, the Property term is Variance 35846KQ,the Representation/Association Qualifier term is Amount 35848KQ, theType term is GDT 35850KQ, and the Type Name term is Amount 35852KQ. Thecardinality between the Upper Variance Amount 35838KQ and the GDTAmountTolerance 35800KQ is either zero or one 35853KQ.

For the Upper Variance Amount Unlimited Indicator 35854KQ, the Categoryis Element 35856KQ, the Object Class term is Amount Tolerance 35858KQ,the Property Qualifier term is Upper Variance Amount 35860KQ, theProperty term is Unlimited 35862KQ, the Representation/AssociationQualifier term is Indicator 35864KQ, the Type term is GDT 35866KQ, andthe Type Name term is Indicator 35868KQ. The cardinality between theUpper Variance Amount Unlimited Indicator 35854KQ and the GDTAmountTolerance 35800KQ is either zero or one 35869KQ.

For the Lower Variance Percent 35870KQ, the Category is Element 35872KQ,the Object Class term is Amount Tolerance 35874KQ, the PropertyQualifier term is Lower 35876KQ, the Property term is Variance 35878KQ,the Representation/Association Qualifier term is Percent 35880KQ, theType term is GDT 35882KQ, and the Type Name term is Percent 35884KQ. Thecardinality between the Lower Variance Percent 35870KQ and the GDTAmountTolerance 35800KQ is either zero or one 35886KQ.

In some variations, the LowerVarianceAmount specifies a value x, whichmeans that an amount y is accepted if y is less than z minus x. Forexample, in a purchase order, an item worth 50

is ordered, in which the LowerVarianceAmount is set at 10, and thecurrency is set to Euro, so a purchase order confirmation will only beaccepted if the entered value is at least 40

(in relation to LowerVarianceAmount). TheLowerVarianceAmountUnlimitedIndicator indicates that amount y must bewell below expected amount z. The UpperVarianceAmount specifies a valuex, which means that an amount y is accepted if y is more than z minus x.For example, in a purchase order, an item worth 50

is ordered, in which the UpperVarianceAmount is set at 5, and thecurrency is set to Euro, so a purchase order confirmation will only beaccepted if the entered value is at least 55

(in relation to UpperVarianceAmount). TheUpperVarianceAmountUnlimitedIndicator indicates that amount y must bewell above expected amount z. The LowerVariancePercent specifies a valuex, which means that an amount y is accepted if y is less than z minus xpercent. For example, in a purchase order, an item worth 50

is ordered, in which the LowerVariancePercent is set at 10, and thecurrency is set to Euro, so a purchase order confirmation will only beaccepted if the entered value is at least 45

(in relation to LowerVariancePercent ). The UpperVariancePercentspecifies a value x in this means that amount y is accepted if y is morethan z minus x percent. For example, in a purchase order, an item worth50

is ordered, in which the UpperVariancePercent is set at 5, and thecurrency is set to Euro, so a purchase order confirmation will only beaccepted if the entered value is at least 52.50

(in relation to UpperVariancePercent). TheUpperVariancePercentUnlimitedIndicator indicates that amount y as apercentage must be well above expected amount z

In some implementations, variances (based on amount or percentage) arenot affected by sign (plus or minus), which is why negative amounts orpercentages are not allowed. The maximum value for LowerVariancePercentallowed is 100 since the threshold value of an amount can not be morethan 100%. Additionally, there may be unlimited indicators that are notspecified will be interpreted as ‘false’. The indicators have priorityover eventual maintained values, that means that ifUpperVarianceAmountUnlimitedIndicator has the value true, then the valueof the attribute UpperVarianceAmount will not be evaluated (this appliesfor the other unlimited indicators as well).

In some variations, if no absolute or percentage value for the varianceupwards or downwards is entered, then the relevant variance is notallowed. If an absolute or percentage value for an upwards or downwardsvariation is maintained, then both values are consulted for verificationof the variance (this involves a AND relationship of the absolute andpercentage conditions). If only one absolute value or only onepercentage value for the upwards or downwards variance is maintained(the respective other value is ‘0’), then only the values differing fromnull are consulted for verification (in this case, the value ‘0’ isinterpreted as user-defined).

The GDT AmountTolerance 35800KQ is used in business documents, forexample to determine if specified value of goods in the vendor orderconfirmation are accepted or not, based on the specified value in theorder. In the above example, the AmountTolerance 35800KQ can be assignedby a buyer—this is equal to an authorization that the buyer can acceptvariances up to the entered variances for AmountTolerance 35800KQ—orassigned by a vendor—in this case it is a type of control function thatvariances outside of the AmountTolerance 35800KQ are not accepted.

(vvvvvvvvvvvvvvvvvvvvv) InspectionSubsetID

The GDT InspectionSubsetID 35800KR is the unique identification of asubset in the context of an inspection. An example (Instance) of the GDTInspectionSubsetID 35800KQ is:

<InspectionSubsetID>Subset0001</InspectionSubsetID>

The structure of GDT InspectionSubsetID 35800KR is depicted in FIG.358KR. The GDT InspectionSubsetID 35800KR includes attributes SchemeID35816KR and SchemeAgencyID 35834KR. For the GDT InspectionSubsetID35800KR, the Object Class term is Inspection Subset 35802KR, theProperty term is Identification 35804KR, the Representation/Associationterm is Identifier 35806KR, the Type term is CCT 35808KR, the Type Nameterm is Identifier 35810KR, and the Length is from one to fifteen35812KR. The GDT InspectionSubsetID 35800KR may be restricted 35814KR.

For the SchemeID 35816KR, the category is attribute 35818KR, the ObjectClass is Identification Scheme 35820KR, the Property term isIdentification 35822KR, the Representation/Association term isIdentifier 35824KR, the Type term is xsd 35826KR, the Type Name term istoken 35828KR, and the Length is from one to sixty 35830KR. Thecardinality between the SchemeID 35816KR and the GDT InspectionSubsetID35800ID is either zero or one 35832KR.

For the SchemeAgencyID 35834KR, the category is attribute 35836KR, theObject Class is Identification Scheme Agency 35838KR, the Property termis Identification 35840KR, the Representation/Association term isIdentifier 35842KR, the Type term is xsd 35844KR, the Type Name term istoken 358646KR, and the Length is from one to sixty 35848KR. Thecardinality between the SchemeAgencyID 35834KR and the GDTInspectionSubsetID 35800ID is either zero or one 35850KR.

In some variations, the attributes of the InspectionSubsetID 35800KR arefilled as follows:

schemeID=InspectionSubset<Qualifier>ID

schemeAgencyID: Business system in which the identifier was assigned.

In the context of, for example, a material inspection, theInspectionSubsetID 35800KR can be used to identify a subset of thematerial that is to be inspected.

(wwwwwwwwwwwwwwwwwwwww) InspectionTypeCode

The GDT InspectionTypeCode 35800KS is the coded representation of thetype of an inspection. An example of the InspectionTypeCode 35800KS is:

<InspectionTypeCode>1</InspectionTypeCode>

The structure of GDT InspectionTypeCode 35800KS is depicted in FIG.358KS. The GDT InspectionTypeCode 35800KS includes attributeslistAgencyID 35814KS, listVersionID 35830KS, listAgencySchemeID 35846KS,and listAgencySchemeAgencyID 35862KS. For the GDT InspectionTypeCode35800KS, the Object Class term is Inspection Type 35802KS, theRepresentation/Association term is Code 35804KS, the Type term is xsd35806KS, the Type term is token 35808KS, the Type Name term is Code35810KS, and the Length is from one to four 35810KS. TheInspectionTypeCode 35800KS may be restricted 35812KS.

For the listAgencyID 35814KS, the Category is Attribute 35816KS, theObject Class term is CodeListAgency 35818KS, the Property term isIdentification 35820KS, the Representation/Association term isIdentifier 35822KS, the Type term is xsd 35824KS, and the Type Name termis token 35826KS. The cardinality between the listAgencyID 35814KS andthe GDT InspectionTypeCode 35800KS is either zero or one 35828KS.

For the listVersionID 35830KS, the Category is Attribute 35832KS, theObject Class term is CodeList 35834KS, the Property term is Version35836KS, the Representation/Association term is Identifier 35838KS, theType term is xsd 35840KS, and the Type Name term is token 35842KS. Thecardinality between the listVersionID 35830KS and the GDTInspectionTypeCode 35800KS is either zero or one 35844KS.

For the listAgencySchemeID 35846KS, the Category is Attribute 35848KS,the Object Class term is CodeListAgency 35850KS, the Property term isScheme 35852KS, the Representation/Association term is Identifier35854KS, the Type term is xsd 35856KS, and the Type Name term is token35858KS. The cardinality between the listAgencySchemeID 35862KS and theGDT InspectionTypeCode 35800KS is either zero or one 35860KS.

For the listAgencySchemeAgencyID 35862KS, the Category is Attribute35864KS, the Object Class term is CodeListAgency 35866KS, the Propertyterm is Scheme 35868KS, the Representation/Association term isIdentifier 35870KS, the Type term is xsd 35872KS, and the Type Name termis token 35874KS. The cardinality between the listAgencySchemeAgencyID35862KS and the GDT InspectionTypeCode 35800KS is either zero or one35876KS.

The type of an inspection defines the process and the object for whichinspection documents can be created. This type could, for example,describe a material inspection in the goods receipt process. It is thecentral controlling element of the inspection.

In some variations, an extendable code list may be assigned to the code.Customers may replace the assigned code lists with their own code list.In its unchanged state, the assigned code list has the followingattributes:

listID=“10407”

listAgencyID=“310”

listVersionID=Version of the relevant code list.

If a customer creates a code list, the attributes change as follows:

listAgencyID—ID of the customer

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme

listAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID

As an example, an assigned code list and its values can be: Code NameDescription 1 Goods Receipt Material inspection in goods receipt processInspection 2 Returns Inspection Inspection of material that a customerhas complained about and that has been returned

(xxxxxxxxxxxxxxxxxxxxx) BusinessPartnerID

A GDT BusinessPartnerID 35800KT is a unique identifier for a businesspartner. A business party is a person, organization, or group ofpeople/organizations in which a company has a business interest. Anexample (Instance) of the GDT BusinessPartnerID 35800KT is:

<BusinessPartnerID>065055766</BusinessPartnerID>

The structure of GDT BusinessPartnerID 35800KT is depicted in FIG.358KT. For the GDT BusinessPartnerID 35800KT, the Object Class term isBusiness Partner 35802KT, the Property term is Identification 35804KT,the Representation/Association term is Code 35806KT, the Type term isCCT 35808KT, the Type Name term is Identification 35810KT, and theLength is from one to sixty 35812KT. The GDT BusinessPartnerID 35800KTmay be restricted 35814KT.

In some variations, the GDT BusinessPartnerID 35800KT may be used torepresent an alternative business partner number. This GDT may not beused in messages. In message, the GDT PartyID may be used instead. Whenmapping from BusinessPartnerID 35800KT to PartyID the attributes aretransferred 1:1. The contents of the scheme attributes are determined bythe type of alternative business partner number (see GDTPartyIDTypeCode). If, for example, the alternative business partnernumber is a DUNS, the values would be as follows: SchemeID “DUNS”SchemeAgencyID “16”

(yyyyyyyyyyyyyyyyyyyyy) BusinessPartnerInternalID

A GDT BusinessPartnerInternalID 35800KU is a person, organization, orgroup of people/organizations in which a company has a businessinterest. An example (Instance) of the GDT BusinessPartnerInternalID35800KU is:

<BusinessPartnerInternalID>12345</BusinessPartnerInternalID>

The structure of GDT BusinessPartnerInternalID 35800KU is depicted inFIG. 358KU. For the GDT BusinessPartnerInternalID 35800KU, the ObjectClass term is Business Partner 35802KU, the Qualifier Property term isInternal 35804KU, the Property term is Identification 35806KU, theRepresentation/Association term is Identifier 35808KU, the Type term isGDT 35810KU, the Type Name term is BusinessPartnerID 35812KU, and theLength is from one to ten 35814KU. The GDT BusinessPartnerInternalID35800KU may be restricted 35816KU.

In some variationst, the GDT BusinessPartnerInternalID cab be used tomap the 10-character SAP-owned business partner numbers. This GDT maynot be used in messages. The GDT PartyInternalID or PartyID may beinstead. The scheme attributes have the following values: Map toPartyInternalID SchemeID “PartyID” SchemeAgencyID Business system inwhich the indicator was assigned. Map to PartyID SchemeID “PartyID”SchemeAgencyID Business system in which the indicator was assigned.schemeAgencyschemeAgencyID “ZZZ”

(zzzzzzzzzzzzzzzzzzzzz) BusinessPartnerPartnerGroupTypeCode

A GDT BusinessPartnerPartnerGroupTypeCode 35800KV is the code indicatingthe type of partner group that occurs as a business partner. By partygroup we mean persons or organizations that have merged. This merger canbe the result of a common purpose or the occurrence of an event. Partnergroups are mapped as business partners of the category group(GDTBusinessPartnerCategoryCode). An example (Instance) of the GDTBusinessPartnerPartnerGroupTypeCode 35800KV is:  <BusinessPartnerPartnerGroupTypeCode>1234</BusinessPartnerPartnerGroupTypeCode>

The GDT BusinessPartnerPartnerGroupTypeCode 35800KV is depicted in FIG.358KV. The GDT BusinessPartnerPartnerGroupTypeCode 35800KV include alistVersionID 35816KV, a listAgencyID 35832KV, a listAgencySchemeID35848KV, and a listAgencySchemeAgencyID 358064KV. For the GDTBusinessPartnerPartnerGroupTypeCode 35800KV, the object class term isBusinessPartner 35802KV, the Property Term is PartnerGroup 35804KV, theProperty term is 35806KV, the Representation/Association term is Code35808KV, the Type term is CCT 35810KV, the Type Name term is Code35812KV, and the Length is from one to four 35814KV. The GDTBusinessPartnerPartnerGroupTypeCode 35800KV may be a restricted GDT35815KV.

For the listVersionID 35816KV, the Category is Attribute 35818KV, theObject Class term is CodeList 35820KV, the Property term is Version35822KV, the Representation/Association term is Identifier 35824KV, theType term is xsd 35826KV, and the Type Name term is token 35828KV. Thecardinality between the listVersionID 35816KV and the GDTBusinessPartnerPartnerGroupTypeCode 35800KV is either zero or one35830KV.

For the listAgencyID 35832KV, the Category is Attribute 35834KV, theObject Class term is CodeListAgency 35836KV, the Property term isIdentification 35838KV, the Representation/Association term isIdentifier 35840KV, the Type term is xsd 35842KV, and the Type Name termis token 35844KV. The Cardinality between the listAgencyID 35832KV andthe GDT ProductUsageCode 35800KV is either zero or one 35846KV.

For the listVersionID 35848KV, the Category is Attribute 35850KV, theObject Class term is CodeList 35852KV, the Property term is Version35854KV, the Representation/Association term is Identifier 35856KV, theType term is xsd 35858KV, and the Type Name term is token 35860KV. Thecardinality between the listVersionID 35848KV and the GDTProductUsageCode 35800KV is either zero or one 35862KV.

For the listAgencySchemeID 35864KV, the Category is Attribute 35866KV,the Object Class term is CodeListAgency 35868KV, the Property term isScheme 35870KV, the Representation/Association term is Identifier35872KV, the Type term is xsd 35874KV, and the Type Name term is token35876KV. The cardinality between the listAgencySchemeID 35864KV and theGDT ProductUsageCode 35800KV is either zero or one 35878KV.

For the listAgencySchemeAgencyID 35880KV, the Category is Attribute35882KV, the Object Class term is CodeListAgency 35884KV, the Propertyterm is SchemeAgency 35886KV, the Representation/Association term isIdentifier 35888KV, the Type term is xsd 35890KV, and the Type Name termis token 35892KV. The cardinality between the listAgencySchemeAgencyID35880KV and the GDT ProductUsageCode 35800KV is either zero or one35894KV.

In some variations, the BusinessPartnerPartnerGroupTypeCode 35800KV maybe a customer-specific code list. For example, the attributes may beused as follows:

listID=“10092”

listAgencyID—The ID of the customer.

listVersionID—Version of the relevant code list.

listAgencySchemeID—The ID of the scheme by which the customer listed inthe listAgencyID is identified. This may be a particular identificationscheme for partners, businesses, and members (such as DUNS+4) and so on,from an administering organization (such as EAN, DUNS and SWIFT) that islisted in the ListAgencySchemeAgency ID.

ListAgencySchemeAgencyID—the ID of the administering organization (suchas DUNS, EAN or SWIFT) that is responsible for identifying theorganization listed in the ListAgencyID.

In one example, a possible semantics for codes is Household, which isthe partner group would be the persons living in a household. In anotherexample, a possible semantics for codes is Joint heirship, which is thepartner group would be the members of a joint heirship.

(aaaaaaaaaaaaaaaaaaaaaa)LiquidityItemBusinessTransactionDocumentStatusCategoryCode

The GDT LiquidityItemBusinessTransactionDocumentStatusCategoryCode35800KX is the coded representation of the category of a liquidity itemdepending on the status of the base document in a business transaction.Liquidity forecast items are realized or expected cash flows of acompany on which one or more (aggregation) operational businessprocesses are based. TheLiquidityItemBusinessTransactionDocumentStatusCategory represents theclassification of liquidity forecast items regarding the status of thebase document in a business transaction. An example of the GDTLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KX is:

<LiquidityItemBusinessTransactionDocumentStatusCategoryCode>1</LiquidityItemBusinessTransactionDocumentStatusCategoryCode>

The structure of GDTLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KX isdepicted in FIG. 358KX. The GDTLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KXincludes attributes listAgencyID 35814KX, listVersionID 35830KX,listAgencySchemeID 35846KX, and listAgencySchemeAgencyID 35862KX. Forthe GDT LiquidityItemBusinessTransactionDocumentStatusCategoryCode35800KX, the Object Class term is Liquidity Item 35802KX, theRepresentation/Association term is Business Transaction Document StatusCategory 35804KX, the Type term is xsd 35806KX, the Type term is token35808KX, the Type Name term is Code 35810KX, and the Length is from oneto three 35810KX. TheLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KX maybe restricted 35812KX.

For the listAgencyID 35814KX, the Category is Attribute 35816KX, theObject Class term is CodeListAgency 35818KX, the Property term isIdentification 35820KX, the Representation/Association term isIdentifier 35822KX, the Type term is xsd 35824KX, and the Type Name termis token 35826KX. The cardinality between the listAgencyID 35814KX andthe GDT LiquidityItemBusinessTransactionDocumentStatusCategoryCode35800KX is either zero or one 35828KX.

For the listVersionID 35830KX, the Category is Attribute 35832KX, theObject Class term is CodeList 35834KX, the Property term is Version35836KX, the Representation/Association term is Identifier 35838KX, theType term is xsd 35840KX, and the Type Name term is token 35842KX. Thecardinality between the listVersionID 35830KX and the GDTLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KX iseither zero or one 35844KX.

For the listAgencySchemeID 35846KX, the Category is Attribute 35848KX,the Object Class term is CodeListAgency 35850KX, the Property term isScheme 35852KX, the Representation/Association term is Identifier35854KX, the Type term is xsd 35856KX, and the Type Name term is token35858KX. The cardinality between the listAgencySchemeID 35862KX and theGDT LiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KXis either zero or one 35860KX.

For the listAgencySchemeAgencyID 35862KX, the Category is Attribute35864KX, the Object Class term is CodeListAgency 35866KX, the Propertyterm is Scheme 35868KX, the Representation/Association term isIdentifier 35870KX, the Type term is xsd 35872KX, and the Type Name termis token 35874KX. The cardinality between the listAgencySchemeAgencyID35862KX and the GDTLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KX iseither zero or one 35876KX.

In some variations, an extendable code list may be assigned to the GDTLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KX. Insome variations, customers can change this code list. In its unchangedstate, the SAP code list has the following attributes:

listID=10289

listAgencyID=“310”

listVersionID=Version of the relevant code list.

If a customer makes changes to the assigned code list, the valuesassigned to the attributes change as follows:

listAgencyID—ID of the SAP customer

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme

listAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID

In some variations, the GDTLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KX canbe used to classify liquidity forecast items using the status of thebase business transaction document (business object). In one example, asales order can be blocked because of doubts about the creditworthinessof the customer. In another example, a vendor invoice can be blockedbecause a smaller quantity than agreed has been delivered. The status ofboth business transaction documents (business object) named can beclassified in the GDTLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KX.

Some examples of customer-specific code semantics are “unclear,” meaningbusiness transactions where it is unclear when and whether they will becontinued in the value chain, and “dispute,” meaning a purchase orderwhere the credit card authorization failed.

An exemplary code list and its values are provided is: Code NameDescription 1 Standard The base process object is in standard processing2 Blocked The base process object has been blocked (such as paymentblock) 3 To be The base process object is waiting to be releasedreleased 4 Confirmed The base process object has been confirmed finally5 In Transfer The base process object is waiting to be transferred (suchas between presenting a bank transfer at the bank and debiting the bankaccount) 6 Planned The base process object has been planned

(bbbbbbbbbbbbbbbbbbbbbb) LiquidityItemGroupCode

The GDT LiquidityItemGroupCode 35800KY is the coded representation of agroup of liquidity items mapped according to business criteria.Liquidity items are realized or expected cash flows of a company onwhich one or more (aggregation) operational business processes arebased. An example of the GDT LiquidityItemGroupCode 35800KY is:

<LiquidityItemGroupCode>1</LiquidityItemGroupCode>

The GDT LiquidityItemBusinessTransactionDocumentStatusCategoryCode35800KX is the coded representation of the category of a liquidity itemdepending on the status of the base document in a business transaction.Liquidity forecast items are realized or expected cash flows of acompany on which one or more (aggregation) operational businessprocesses are based. TheLiquidityItemBusinessTransactionDocumentStatusCategory represents theclassification of liquidity forecast items regarding the status of thebase document in a business transaction. An example of the GDTLiquidityItemBusinessTransactionDocumentStatusCategoryCode 35800KX is:

<LiquidityItemBusinessTransactionDocumentStatusCategoryCode>1</LiquidityItemBusinessTransactionDocumentStatusCategoryCode>

The structure of GDT LiquidityItemGroupCode 35800KY is depicted in FIG.358KY. The GDT LiquidityItemGroupCode 35800KY includes attributeslistAgencyID 35814KY, listVersionID 35830KY, listAgencySchemeID 35846KY,and listAgencySchemeAgencyID 35862KY. For the GDT LiquidityItemGroupCode35800KY, the Object Class term is Liquidity Item Group 35802KY, theRepresentation/Association term is Business Transaction Document StatusCategory 35804KY, the Type term is xsd 35806KY, the Type term is token35808KY, the Type Name term is Code 35810KY, and the Length is from oneto four 35810KY. The LiquidityItemGroupCode 35800KY may be restricted35812KY.

For the listAgencyID 35814KY, the Category is Attribute 35816KY, theObject Class term is CodeListAgency 35818KY, the Property term isIdentification 35820KY, the Representation/Association term isIdentifier 35822KY, the Type term is xsd 35824KY, and the Type Name termis token 35826KY. The cardinality between the listAgencyID 35814KY andthe GDT LiquidityItemGroupCode 35800KY is either zero or one 35828KY.

For the listVersionID 35830KY, the Category is Attribute 35832KY, theObject Class term is CodeList 35834KY, the Property term is Version35836KY, the Representation/Association term is Identifier 35838KY, theType term is xsd 35840KY, and the Type Name term is token 35842KY. Thecardinality between the listVersionID 35830KY and the GDTLiquidityItemGroupCode 35800KY is either zero or one 35844KY.

For the listAgencySchemeID 35846KY, the Category is Attribute 35848KY,the Object Class term is CodeListAgency 35850KY, the Property term isScheme 35852KY, the Representation/Association term is Identifier35854KY, the Type term is xsd 35856KY, and the Type Name term is token35858KY. The cardinality between the listAgencySchemeID 35862KY and theGDT LiquidityItemGroupCode 35800KY is either zero or one 35860KY.

For the listAgencySchemeAgencyID 35862KY, the Category is Attribute35864KY, the Object Class term is CodeListAgency 35866KY, the Propertyterm is Scheme 35868KY, the Representation/Association term isIdentifier 35870KY, the Type term is xsd 35872KY, and the Type Name termis token 35874KY. The cardinality between the listAgencySchemeAgencyID35862KY and the GDT LiquidityItemGroupCode 35800KY is either zero or one35876KY.

In some variations, an extendable code list may be assigned to the GDTLiquidityItemGroupCode 35800KY. In some implementations, customers canchange this code list. In its unchanged state, the assigned code listhas the following attributes:

listID=10290

listAgencyID=“310”

listVersionID=Version of the relevant code list.

If a customer makes changes to the assigned code list, the valuesassigned to the attributes change as follows:

listAgencyID—ID of the SAP customer

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme

listAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID

The GDT LiquidityItemGroupCode 35800KY is used to group liquidity itemsusing relevant business criteria that the customer can define. In someimplementations, a LiquidityItem is in exactly one group.

An example for customer-specific code semantics is Kerosene. Thematerial kerosene is the most important item in the purchasing processfor an airline. The time-based fluctuations in price are much greaterthan the differences between different vendors. For this reason, thecategory “kerosene” could be much more important for liquidity analysesthan the categorization by vendors (such as domestic vendors, foreignvendors).

An exemplary assigned code list and its values are: Code NameDescription 1 Vendors Grouping of liquidity items by vendors 2 Domesticvendors Grouping of liquidity items by vendors with headquarters at home3 Foreign vendors Grouping of liquidity items by vendors withheadquarters abroad 4 Vendors: Affiliated Grouping of liquidity items byvendors that Company are affiliated with the company 5 CustomersGrouping of liquidity items by customers 6 Domestic customers Groupingof liquidity items by domestic customers 7 Foreign customers Grouping ofliquidity items by foreign customers 8 Customers: Grouping of liquidityitems by Affiliated Company customers that are affiliated with thecompany 9 Domestic banks Grouping of liquidity items by banks withheadquarters at home 10 Foreign banks Grouping of liquidity items bybanks with headquarters abroad

(cccccccccccccccccccccc) BusinessPartnerPaymentCardDetailsID

A GDT BusinessPartnerPaymentCardDetailsID 35800KZ is a unique identifierfor the business partner payment card details. PaymentCardDetailscontain the relationship of business partner with a payment or creditcard. Such a relationship includes a payment card and other details thatdescribe the significance of the payment card for the business partner.An example (Instance) of the GDT BusinessPartnerPaymentCardDetailsID35800KZ is:

<BusinessPartnerPaymentCardDetailsID>

123456</BusinessPartnerPaymentCardDetailsID>

The structure of GDT BusinessPartnerPaymentCardDetailsID 35800KZ isdepicted in FIG. 358KZ. For the GDT BusinessPartnerPaymentCardDetailsID35800KZ, the Object Class term is Business Partner Payment Card Details35802KZ, the Property term is Identification 35804KZ, theRepresentation/Association term is Identifier 35806KZ, the Type term isCCT 35808KZ, the Type Name term is Identifier 35810KZ, and the Length isfrom one to six 35812KZ. The GDT BusinessPartnerPaymentCardDetailsID35800KZ may be restricted 35814KZ.

In some variations, the GDT BusinessPartnerPaymentCardDetailsID 35800LZcan be used to identify the payment card details of a business partner.

(dddddddddddddddddddddd) LockModeCode

A GDT LockModeCode 35800LA is a coded representation of mode of anobject lock. For example, locks protect data in different modes (asshared or exclusive locks) from simultaneous access by multiple users.An example of GDT LockModeCode 35800LA is:

<LockModeCode>1</LockModeCode>

The structure of GDT LockModeCode 35800LA is depicted in FIG. 358LA. Forthe GDT LockModeCode 35800LA, the Property is Lock Mode 35806LA, theRepresentation/Association is Code 35808LA, the Type is CCT 35810LA, theType Name is Code 35812LA, and the Length is one 35814LA. The remark35818LA shows that the GDT LockModeCode 35800LA may be restricted.

A particular fixed code list is assigned to the LockModeCode. Theattributes have the following values: listID=10243, listAgencyID=310.The code list and its values are presented in the “Appendix—Code List”.

The LockModeCode defines whether a lock is a shared or an exclusivelock. A shared lock allows other users to set additional shared locksbut no concur-rent exclusive locks for the locked data. An exclusivelock, by contrast, locks an object exclusively and thus prevents otherusers from setting additional shared or exclusive locks for the lockeddata.

The data type GDT LockModeCode 35800LA may use the following codes: 1(i.e., a shared lock prevents other users from setting an exclusive lockto change the object for the duration of the shared lock. Additionalshared locks, however, are allowed), 2 (i.e., an exclusive lock locks anobject exclusively for one user. Other users can set neither shared norexclusive locks for that object).

(eeeeeeeeeeeeeeeeeeeeee) LogisticPackageContentTypeCode

A GDT LogisticPackageContentTypeCode 35800LB is a coded representationof the type of the content of a logistic package. An example of GDTLogisticPackageContentTypeCode 35800LB is:

<LogisticPackageContentTypeCode>1</LogisticPackageContentTypeCode>

The structure of GDT LogisticPackageContentTypeCode 35800LB is depictedin FIG. 358LB. For the GDT LogisticPackageContentTypeCode 35800LB, theObject Class is LogisticPackageContent 35804LB, the Property is Type35806LB, the Representation/Association is Code 35808LB, the Type is CCT35810LB, the Type Name is Code 35812LB, and the Length is from one totwo 35814LB. The remark 35818LB shows that the GDTLogisticPackageContentTypeCode 35800LB may be restricted.

The LogisticPackageContentTypeCode is a codelist with the implicitlygiven attributes listID=“10089”, and listAgencyID=“310”. The data typeGDT LogisticPackageContentTypeCode 35800LB may use the following codes:1 (i.e., the content of the logistic package is a material), 2 (i.e.,the content of the logistic package is a logistic unit.

(ffffffffffffffffffffff) LogisticsDeviationReasonCode

A GDT LogisticsDeviationReasonCode 35800LC is a coded representation ofthe reason for a deviation between the result of a logistics process andthe expected result. An example of GDT LogisticsDeviationReasonCode35800LC is:

<LogisticsDeviationReasonCode>1</LogisticsDeviationReasonCode>

The structure of GDT LogisticsDeviationReasonCode 35800LC is depicted inFIG. 358LC. For the GDT LogisticsDeviationReasonCode 35800LC, the ObjectClass is LogisticsDeviation 35802LC, the Property is Reason 35803LC, theRepresentation/Association is Code 35804LC, the Type is CCT 35805LC, theType Name is Code 35806LC, and the Length is from one to three 35807LC.The remark 35809LC shows that the GDT LogisticsDeviationReasonCode35800LC may be restricted.

For the ListAgencyID 35811LC, the Category is Attribute (A) 35812LC, theObject Class is CodeListAgency 35813LC, the Property is Identification35814LC, the Representation/Association is Identifier 35815LC, the Typeis XSD 35816LC, the Type Name is Token 35817LC, and the Cardinality iszero or one 35818LC.

For the ListVersionID 35821LC, the Category is Attribute (A) 35822LC,the Object Class is CodeList 35823LC, the Property is Version 35824LC,the Representation/Association is Identifier 35825LC, the Type is XSD35826LC, the Type Name is Token 35827LC, and the Cardinality is zero orone 35828LC.

For the ListAgency-SchemeID 35831 LC, the Category is Attribute (A)35832LC, the Object Class is CodeListAgency 35833LC, the Property isScheme 35834LC, the Representation/Association is Identifier 35835LC,the Type is XSD 35836LC, the Type Name is Token 35837LC, and theCardinality is zero or one 35838LC.

For the ListAgency-SchemeAgencyID 35841LC, the Category is Attribute (A)35842LC, the Object Class is CodeListAgency 35843LC, the Property isSchemeAgency 35844LC, the Representation/Association is Identifier35845LC, the Type is XSD 35846LC, the Type Name is Token 35847LC, andthe Cardinality is zero or one 35848LC.

A customer-specific code list is assigned to the code and the determinesthe codes in the code list. TheLogisticsDeviationReasonCodeSomethingName 35800LCNN is used to documentthe reason for a difference between expected and actual data reported ina logistics process (for example, in a production or a site logisticsprocess). The deviation reason may trigger a follow up action to resolvethe problem that caused the deviation. For example, a logisticsdeviation reason could be: Blocked Bin—Deviation is caused by a bin thatcannot be accessed, or Damaged Material—Deviation is caused by a damagedmaterial.

(gggggggggggggggggggggg) LogisticsPlanningDetailLevelCode

A GDT LogisticsPlanningDetailLevelCode 35800LD is a coded representationof the level of detail for planning in logistics. An example of GDTLogisticsPlanningDetailLevelCode 35800LD is:

<LogisticsPlanningDetailLevelCode>1</LogisticsPlanningDetailLevelCode>

The structure of GDT LogisticsPlanningDetailLevelCode 35800LD isdepicted in FIG. 358LD. For the GDT LogisticsPlanningDetailLevelCode35800LD, the Object Class is Logistics Planning 35804LD, the Property isDetail Level 35806LD, the Representation/Association is Code 35808LD,the Type is CCT 35810LD, the Type Name is Code 35812LD, and the Lengthis one 35814LD. The remark 35818LD shows that the GDTLogisticsPlanningDetailLevelCode 35800LD may be restricted.

A fixed code list has been assigned to the code. The attributes are asfollows: listID=“10276”, listAgencyID=“310”. The code list and itsvalues are provided in the “Appendix—Code List.” The data type GDTLogisticsPlanningDetailLevelCode 35800LD may use the following codes: 1(i.e., Low level of detail).

(hhhhhhhhhhhhhhhhhhhhhh) MailNonDeliveryReasonCode

A GDT MailNonDeliveryReasonCode 35800LE is a coded representation why apostal item could not be delivered. An example of GDTMailNonDeliveryReasonCode 35800LE is:

<MailNonDeliveryReasonCode>0001</MailNonDeliveryReasonCode>

The structure of GDT MailNonDeliveryReasonCode 35800LE is depicted inFIG. 358LE. For the GDT MailNonDeliveryReasonCode 35800LE, the ObjectClass is Address 35802LE, the Property is Mail Non Delivery Reason35803LE, the Representation/Association is Code 35804LE, the Type is CCT35805LE, the Type Name is Code 35806LE, and the Length is from one tofour 35807LE. The remark 35809LE shows that the GDTMailNonDeliveryReasonCode 35800LE may be restricted.

For the ListAgencyID 35811LE, the Category is Attribute (A) 35812LE, theObject Class is CodeListAgency 35813LE, the Property is Identification35814LE, the Representation/Association is Identifier 35815LE, the Typeis XSD 35816LE, the Type Name is Token 35817LE, and the Cardinality iszero or one 35818LE.

For the ListVersionID 35821LE, the Category is Attribute (A) 35822LE,the Object Class is CodeList 35823LE, the Property is Version 35824LE,the Representation/Association is Identifier 35825LE, the Type is XSD35826LE, the Type Name is Token 35827LE, and the Cardinality is zero orone 35828LE.

For the ListAgency-SchemeID 35831LE, the Category is Attribute (A)35832LE, the Object Class is CodeListAgency 35833LE, the Property isScheme 35834LE, the Representation/Association is Identifier 35835LE,the Type is XSD 35836LE, the Type Name is Token 35837LE, and theCardinality is zero or one 35838LE.

For the ListAgency-SchemeAgencyID 35841LE, the Category is Attribute (A)35842LE, the Object Class is CodeListAgency 35843LE, the Property isSchemeAgency 35844LE, the Representation/Association is Identifier35845LE, the Type is XSD 35846LE, the Type Name is Token 35847LE, andthe Cardinality is zero or one 35848LE.

An extendable code list is assigned to the MailNonDeliveryReasonCode.The customers may change this code list. In its unchanged state, thecode list has the following attributes: listID=“10175”,listAgencyID=“310”, and listVersionID=[Version of the relevant codelist]. The MailNonDeliveryReasonCode 35800LE may be used to specify whya postal item could not be delivered to an address. TheMailNonDeliveryReasonCode 35800LE may further be used for streetaddresses and PO Box addresses. The corresponding qualifiers are: nondelivery reason for a street address, and non delivery reason for a PObox address The data type GDT MailNonDeliveryReasonCode 35800LE may usethe following codes: 1 (i.e., the recipient is unknown), 2 (i.e., therecipient has moved away to an unknown address—a new address is notknown), 3 (i.e., the address is incomplete), 4 (i.e., the address isunreadable), 5 (i.e., there is no mailbox), 6 (i.e., the PO box is notavailable or locked), 7 (i.e., acceptance was refused)., 8 (i.e., therecipient is deceased), 9 (i.e., the recipient company no longerexists).

(iiiiiiiiiiiiiiiiiiiiii) MaterialFlowElementTypeCode

A GDT MaterialFlowElementTypeCode 35800LF is aMaterialFlowElementTypeCode is the coded representation of the type ofan element in the flow of materials. For example, the material flowdescribes how materials are passed on in a logistical process. Anexample of GDT MaterialFlowElementTypeCode 35800LF is:

<MaterialFlowElementTypeCode>1</MaterialFlowElementTypeCode>

The structure of GDT MaterialFlowElementTypeCode 35800LF is depicted inFIG. 358LF. For the GDT MaterialFlowElementTypeCode 35800LF, the ObjectClass is Material Flow Element 35804LF, the Property is Type 35806LF,the Representation/Association is Code 35808LF, the Type is CCT 35810LF,the Type Name is Code 35812LF, and the Length is from one to two35814LF. The remark 35818LF shows that the GDTMaterialFlowElementTypeCode 35800LF may be restricted.

Exactly one fixed code list has been assigned to the code. Theattributes are as follows: listID=10232, listAgencyID=310. The data typeGDT MaterialFlowElementTypeCode 35800LF may use the following codes: 1(i.e., operation), 2 (i.e., branching of a logistical process intoseveral processing paths), 3 (i.e., the rejoining of a previouslybranched logistical process back into one processing path), 4 (i.e.,item of stock), 5 (i.e., schedule line of a planned external procurementorder)., 6 (i.e., material output of a planned production order), 7(i.e., schedule line of a supply planning requirement), 8 (i.e.,material input of a planned production order), 9 (i.e., plannedindependent requirement).

(jjjjjjjjjjjjjjjjjjjjjj) MaterialInputGroupID

A GDT MaterialInputGroupID 35800LG is a unique ID for a group ofinterrelated material inputs. For example, a material input is aquantitative input of a material used in the execution of a productionactivity in a manufacturing process. A group of material inputsoriginates within the context of an instance of a business object (forexample, a ProductionRequest) as a result of the common reference of allaffected material inputs to a BOM item. An example of GDTMaterialInputGroupID 35800LG is:

<MaterialInputGroupID>4712</MaterialInputGroupID>

The structure of GDT MaterialInputGroupID 35800LG is depicted in FIG.358LG. For the GDT MaterialInputGroupID 35800LG, the Object Class isMaterial Input Group 35804LG, the Property is Identification 35806LG,the Representation/Association is Identifier 35808LG, the Type is CCT35810LG, the Type Name is Identifier 35812LG, and the Length is from oneto six 35814LG. The remark 35818LG shows that the GDTMaterialInputGroupID 35800LG may be restricted.

MaterialInputGroupID is unique within the context of an instance of abusiness object.

(kkkkkkkkkkkkkkkkkkkkkk) MaterialOutputGroupID

A GDT MaterialOutputGroupID 35800LH is a unique ID for a group ofinterrelated material outputs. For example, a material output is aquantitative output of a material that represents the desired result ofa manufacturing process. A group of material outputs originates withinthe context of an instance of a business object (for example, aProductionRequest) as a result of the common reference of all affectedmaterial outputs to a BOM item. An example of GDT MaterialOutputGroupID35800LH is:

<MaterialOutputGroupID>4711</MaterialOutputGroupID>

The structure of GDT MaterialOutputGroupID 35800LH is depicted in FIG.358LH. For the GDT MaterialOutputGroupID 35800LH, the Object Class isMaterial Output Group 35804LH, the Property is Identification 35806LH,the Representation/Association is Identifier 35808LH, the Type is CCT35810LH, the Type Name is Identifier 35812LH, and the Length is from oneto six 35814LH. The remark 35818LH shows that the GDTMaterialOutputGroupID 35800LH may be restricted. MaterialOutputGroupIDis unique within the context of an instance of a business object.

A GDT NumberValue 35800LI is a number. An example of GDT NumberValue35800LI is:

<NumberValue>42</NumberValue>

The structure of GDT NumberValue 35800LI is depicted in FIG. 358LI. Forthe GDT NumberValue 35800LI,, the Rep./Ass. Qual. is Number 35807LI, theRepresentation/Association is Value 35808LI, the Type is XSD 35810LI,the Type Name is nonNegativeInteger 35812LI, and the Length is from oneto nine 35814LI.

Only nonnegative integers that are less than one billion are allowed(0-999999999). NumberValue may be used, for example, to specify thenumber of objects contained in a list. NumberValue always appears in aspecific business role. In the element name, these roles may be given asqualifiers that are written as prefixes to the name “NumberValue”. Thefollowing roles are allowed: number of something that provides a basisfor something, number of days, number of digits in the representation ofa real number or a whole number, for example, the total number of digitsor the number of decimal places for decimal numbers, or the length ofthe mantissa for numbers with floating points, number of flat rates,maximum number of elements in a quantity, number of meals, number ofparticipants, number of passengers, number of receipts, number ofelements of a total number, and sample size (i.e., describes the numberof units to be taken in a sample test).

(mmmmmmmmmmmmmmmmmmmmmm) Operation

AlternativeID

A GDT OperationAlternativeID 35800LJ is a unique identifier of analternative operation in an operation. For example, an alternativeoperation defines default values for an alternative execution of anoperation. An example of GDT OperationAlternativeID 35800LJ is:

<OperationAlternativeID>10</OperationAlternativeID>

The structure of GDT OperationAlternativeID 35800LJ is depicted in FIG.358LJ. For the GDT OperationAlternativeID 35800LJ, the Object Class isOperationAlternative 35804LJ, the Property is Identification 35806LJ,the Representation/Association is Identifier 35808LJ, the Type is CCT35810LJ, the Type Name is Identifier 35812LJ, and the Length is from oneto five 35814LJ. The remark 35818LJ shows that the GDTOperationAlternativeID 35800LJ may be restricted. AnOperationAlternativeID is explicit in the context of an operation.

(nnnnnnnnnnnnnnnnnnnnn) OrganisationName

A GDT OrganisationName 35800LK is a name of an organization instructured form, including the form of address. An example of GDTOrganisationName 35800LK is: <OrganisationName>   <FirstLineName>SAPAG</FirstLineName>   <SecondLineName>GeschaftsstelleBerlin</SecondLineName> </OrganisationName>

The structure of GDT OrganisationName 35800LK is depicted in FIG. 358LK.For the GDT OrganisationName 35800LK, the Object Class is OrganisationName 35803LK, the Representation/Association is Details 35804LK, For theFormOfAddressCode 35811LK, the Category is Element (E) 35812LK, theObject Class is Organisation Name 35813LK, the Property is FormOfAddress35814LK, the Representation/Association is Code 35815LK, the Type is GDT35816LK, the Type Name is FormOfAddressCode 35816LK, , and theCardinality is zero or one 35818LK.

For the FirstLineName 35821LK, the Category is Element (E) 35822LK, theObject Class is OrganisationName-Agency 35823LK, the Property isFirstLine 35824LK, the Representation/Association is Name 35825LK, theType is GDT 35826LK, the Type Name is _MEDIUM_Name 35827LK, and theCardinality is zero or one 35828LK.

For the SecondLineName 35831LK, the Category is Element (E) 35832LK, theObject Class is OrganisationName-Agency 35833LK, the Property isSecondLine 35834LK, the Representation/Association is Name 35835LK, theType is GDT 35836LK, the Type Name is _MEDIUM_Name 35837LK, and theCardinality is zero or one 35838LK.

For the ThirdLineName 35841LK, the Category is Element (E) 35842LK, theObject Class is OrganisationName-Agency 35843LK, the Property isThirdLine 35844LK, the Representation/Association is Name 35845LK, theType is GDT 35846LK, the Type Name is _MEDIUM_Name 35847LK, and theCardinality is zero or one 35848LK.

For the FourthLineName 35851LK, the Category is Element (E) 35852LK, theObject Class is OrganisationName-Agency 35853LK, the Property isFourthLine 35854LK, the Representation/Association is Name 35855LK, theType is GDT 35856LK, the Type Name is _MEDIUM_Name 35857LK, and theCardinality is zero or one 35858LK.

OrganisationName 35800LK consists of the following subelements:FormOfAddressCode: The form of address of the organization,FirstLineName: The name components of the organization that appear inthe first name line in address formatting, SecondLineName: The namecomponents of the organization that appear in the second name line inaddress formatting, ThirdLineName: The name components of theorganization that appear in the third name line in address formatting,and FourthLineName: The name components of the organization that appearin the fourth name line in address formatting.

(oooooooooooooooooooooo) OverheadCostLedgerAccountTypeCode

A GDT OverheadCostLedgerAccountTypeCode 35800LL is a codedrepresentation of the type of an overhead cost ledger account based onthe cost object. For example, an overhead cost ledger account (businessobject OverheadCostLedgerAccount) Global Data Types—Definition is arecord of the costs incurred by the provision of resources. An exampleof GDT OverheadCostLedgerAccountTypeCode 35800LL is:

<OverheadCostLedgerAccountTypeCode>1</OverheadCostLedgerAccountTypeCode>

The structure of GDT OverheadCostLedgerAccountTypeCode 35800LL isdepicted in FIG. 358LL. For the GDT OverheadCostLedgerAccountTypeCode35800LL, the Object Class is Overhead Cost Ledger Account 35804LL, theProperty is Type 35806LL, the Representation/Association is Code35808LL, the Type is CCT 35810LL, the Type Name is Code 35812LL, and theLength is from one to two 35814LL. The remark 35818LL shows that the GDTOverheadCostLedgerAccountTypeCode 35800LL may be restricted.

A fixed SAP code list has been assigned toOverheadCostLedgerAccountTypeCode. The attributes are as follows:listID=“10206”, and listAgencyID=“310”.OverheadCostLedgerAccountTypeCode is used to differentiate betweendifferent types of overhead cost ledger accounts. These accounts aredifferentiated by the object that carries the overhead, such as a costcenter or project.

The data type GDT OverheadCostLedgerAccountTypeCode 35800LL may use thefollowing codes: 1 (i.e., overhead cost ledger account for a costcenter), 2 (i.e., overhead cost ledger account for a resource), 3 (i.e.,overhead cost ledger account for a project).

(pppppppppppppppppppppp) PackagingMaterialTypeCode

A GDT PackagingMaterialTypeCode 35800LM is a coded representation of thetype of a packaging material. For example, a packaging material is amaterial that is destined to surround or contain materials that are tobe packed. An example of GDT PackagingMaterialTypeCode 35800LM is:

<PackagingMaterialTypeCode>1</PackagingMaterialTypeCode>

The structure of GDT PackagingMaterialTypeCode 35800LM is depicted inFIG. 358LM. For the GDT PackagingMaterialTypeCode 35800LM, the ObjectClass is PackagingMaterial 35804LM, the Property is Type 35806LM, theRepresentation/Association is Code 35808LM, the Type is CCT 35810LM, theType Name is Code 35812LM, and the Length is from one 35814LM. Theremark 35818LM shows that the GDT PackagingMaterialTypeCode 35800LM maybe restricted.

The PackagingMaterialTypeCode may be a codelist with the implicitlygiven attributes listID=“10081”, listAgencyID=“310” andlistVersionID=“tbd”. The data type GDT PackagingMaterialTypeCode 35800LMmay use the following codes: 1 (i.e., a Load Carrier is a packagingmaterial in or on which all the content of a packing operation isfinally placed.), 2 (i.e., an Additional Packaging Material is apackaging material which is used to wrap or protect content of a packingoperation).

PackagingMaterialTypeCode may be used to differentiate between severalcategories of usage of packaging material items within the packagingoperation. PackagingMaterialTypeCode may further be used todifferentiate the packaging materials in a packing bill of materialwhere a packing bill of material is a complete and structured list ofcomponents that defines the packing structure of logistic units. Thepackaging material type codes Load Carrier and Additional PackagingMaterial correspond to the attributes of GDT HandlingUnit.

(qqqqqqqqqqqqqqqqqqqqqq) BusinessPartnerRelationshipSubCategoryCode

A GDT BusinessPartnerRelationshipSubCategoryCode 35800LN represents, inthe form of a code, a subcategory of a business partner relationshipcategory (BusinessPartnerRelationshipCategoryCode). The GDTBusinessPartnerRelationshipSubCategoryCode 35800LN represents arefinement of the business partner relationship category (GDTBusinessPartnerRelationshipCategoryCode). An example of the GDTBusinessPartnerRelationshipSubCategoryCode 35800LN is:

<BusinessPartnerRelationshipSubCategoryCode>1A3</BusinessPartnerRelationshipSubCategoryCode>

The structure of GDT BusinessPartnerRelationshipSubCategoryCode 35800LNis depicted in FIG. 358LN. The GDTBusinessPartnerRelationshipSubCategoryCode 35800LN includes attributeslistID 35816LN, listAgencyID 35832LN, listVersionID 35848LN,listAgencySchemeID 35864LN, and listAgencySchemeAgencyID 35880LN. Forthe GDT BusinessPartnerRelationshipSubCategoryCode 35800LN, the ObjectClass term is Business Partner Relationship 35802LN, the Property termis Sub Category 35804LN, the Representation/Association term is Code35806LN, the Type term is CCT 35808LN, the Type Name term is Code35810LN, and the Length is either one or four 35812LN. The GDTBusinessPartnerRelationshipSubCategoryCode 35800LN may be restricted35814LN.

For the listID 35816LN, the Category is Attribute 35818LN, the ObjectClass term is CodeList 35820LN, the Property term is Identification35822LN, the Representation/Association term is Identifier 35822LN, theType term is xsd 35826LN, and the Type Name term is token 35828LN. Thecardinality between the listID 35816LN and the GDTBusinessPartnerRelationshipSubCategoryCode 35800LN is either zero or one35830LN.

For the listAgencyID 35832LN, the Category is Attribute 35834LN, theObject Class term is CodeListAgency 35836LN, the Property term isIdentification 35838LN, the Representation/Association term isIdentifier 35840LN, the Type term is xsd 35842LN, and the Type Name termis token 35844LN. The Cardinality between the listAgencyID 35832LN andthe GDT BusinessPartnerRelationshipSubCategoryCode 35800LN is eitherzero or one 35846LN.

For the listVersionID 35848LN, the Category is Attribute 35850LN, theObject Class term is CodeList 35852LN, the Property term is Version35854LN, the Representation/Association term is Identifier 35856LN, theType term is xsd 35858LN, and the Type Name term is token 35860LN. Thecardinality between the listVersionID 35848LN and the GDTBusinessPartnerRelationshipSubCategoryCode 35800LN is either zero or one35862LN.

For the listAgencySchemeID 35864LN, the Category is Attribute 35866LN,the Object Class term is CodeListAgency 35868LN, the Property term isScheme 35870LN, the Representation/Association term is Identifier35872LN, the Type term is xsd 35874LN, and the Type Name term is token35876LN. The cardinality between the listAgencySchemeID 35864LN and theGDT BusinessPartnerRelationshipSubCategoryCode 35800LN is either zero orone 35878LN.

For the listAgencySchemeAgencyID 35880LN, the Category is Attribute35882LN, the Object Class term is CodeListAgency 35884LN, the Propertyterm is SchemeAgency 35886LN, the Representation/Association term isIdentifier 35888LN, the Type term is xsd 35890LN, and the Type Name termis token 35892LN. The cardinality between the listAgencySchemeAgencyID35880LN and the GDT BusinessPartnerRelationshipSubCategoryCode 35800LNis either zero or one 35894LN.

Only alternative code lists exist that differ at configuration and/orruntime.

The BusinessPartnerRelationshipSubCategoryCode is a customer-specificcode list. The attributes are used as follows:

listID=“10327”

listAgencyID—The ID of the customer. An ID assigned by an organizationlisted in the DE 3055 must be used (such as the business IDs assigned byDUNS, EAN and SWIFT).

listVersionID—Version of the relevant code list. This is assigned andadministered by the customer listed in the listAgencyID.

listAgencySchemeID—The ID of the scheme by which the customer listed inthe listAgencyID is identified. This is a particular identificationscheme for partners, businesses, and members (such as DUNS+4) and so on,from an administering organization (such as EAN, DUNS and SWIFT) that islisted in the ListAgencySchemeAgency ID.

ListAgencySchemeAgencyID—the ID of the administering organization (suchas DUNS, EAN or SWIFT) that is responsible for identifying theorganization listed in the ListAgencyID. This must be listed in DE 3055.

Integrity Conditions

1) A code value of BusinessPartnerRelationshipSubCategoryCode must beassigned to a code value of BusinessPartnerRelationshipCategoryCode.

2) A code value of BusinessPartnerRelationshipSubCategoryCode can onlybe assigned to a code value of BusinessPartnerRelationshipCategoryCode.

In some variations, the GDT BusinessPartnerRelationshipSubCategoryCode35800LO can be used to differentiate a business partner relationshipcategory in more detail. However, a subcategory does not necessarilyhave to be assigned to a business partner relationship category. Someexamples of possible semantics for codes are:

Minority shareholding The shareholder relationship is based on minorityshareholding

Majority shareholding The shareholder relationship is based on majorityshareholding

Reciprocal shareholding The shareholder relationship is based onreciprocal shareholding

Co-guardianship The guardianship relationship is based onco-guardianship; meaning that guardianship is carried out jointly withanother guardian

For example, a type of supervisory guardianship that exists in Germanlaw, Gegenvormundschaft. The guardianship relationship is based onsupervisory guardianship; meaning that the purpose of this guardianshipis to monitor how the guardian does his job.

(rrrrrrrrrrrrrrrrrrrrrr) ChartOfAccountsItemID

A GDT ChartOfAccountsItemID 35800LO is an identifier for an item in thechart of accounts. A chart of accounts item groups together assets,payables, stockholders' equity, revenues, or expenses and is used toenter and represent for accounting purposes any changes to these valuesresulting from business transactions. An example of the GDTChartOfAccountsItemID 35800LO is:

<ChartOfAccountsItemID>400000</ChartOfAccountsItemID>

The structure of GDT ChartOfAccountsItemID 35800LO is depicted in FIG.358LO. For the GDT ChartOfAccountsItemID 35800LO, the Object Class termis Chart Of Accounts Item 35802LO, the Property term is Identification35804LO, the Representation/Association term is Identifier 35806LO, theType term is CCT 35808LO, the Type Name term is Identifier 35810LO, andthe Length is from one to ten 35812LO. The GDT ChartOfAccountsItemID35800LO may be restricted 35814LO.

A chart of accounts item is identified uniquely by specifying aChartOfAccountsID and a ChartOfAccountsItemID 35800LO. Note, therefore,that the ChartOfAccountsItemID 35800LO is only unique in the context ofthe chart of accounts. For this reason, the GDT ChartOfAccountsItemKeyshould usually be used to identify a chart of accounts item because itcontains both elements.

If, however, the chart of accounts is known from the context (such asfrom a superordinate element), a chart of accounts item can also beidentified solely by specifying the ChartOfAccountsItemID 35800LO.

(ssssssssssssssssssssss) ChequeID

A GDT ChequeID 35800LP is a unique identifier for a check. A check is aninstruction to a bank to debit the amount named from the check issuer'saccount when the check is presented and to pay it to the check recipientor credit the check recipient's account. An example of the GDT ChequeID35800LP is:

<ChequeID>0000550766555</ChequeID>

The structure of GDT ChequeID 35800LP is depicted in FIG. 358LP. For theGDT ChequeID 35800LP, the Object Class term is Cheque Item 35802LP, theProperty term is Identification 35804LP, the Representation/Associationterm is Identifier 35806LP, the Type term is CCT 35808LP, the Type Nameterm is Identifier 35810LP, and the Length is from one to twenty35812LP.

A check number identifies a check uniquely if the bank and the bankaccount number are known in the context. In some variations, the GDTChequeID 35800LP can be used, for example, to identify incoming bankchecks with which invoices can be paid.

(tttttttttttttttttttttt) CompanyLegalFormCode

A GDT CompanyLegalFormCode 35800LQ is a code that indicates the legalform of a company. The legal form defines the legal framework of acompany that operates commercially in one form or another. An example ofthe GDT CompanyLegalFormCode 35800LQ is:

<CompanyLegalFormCode>1</CompanyLegalFormCode>

The structure of GDT CompanyLegalFormCode 35800LQ is depicted in FIG.358LQ. The GDT CompanyLegalFormCode 35800LQ includes attributes listID35816LQ, listAgencyID 35832LQ, listVersionID 35848LQ, listAgencySchemeID35864LQ, and listAgencySchemeAgencyID 35880LQ. For the GDTCompanyLegalFormCode 35800LQ, the Property Qualifier term is Company35802LQ, the Property term is Legal Form 35804LQ, theRepresentation/Association term is Code 35806LQ, the Type term is CCT35808LQ, the Type Name term is Code 35810LQ, and the Length is eitherone or four 35812LQ. The GDT CompanyLegalFormCode 35800LQ may berestricted 35814LQ.

For the listID 35816LQ, the Category is Attribute 35818LQ, the ObjectClass term is CodeList 35820LQ, the Property term is Identification35822LQ, the Representation/Association term is Identifier 35822LQ, theType term is xsd 35826LQ, and the Type Name term is token 35828LQ. Thecardinality between the listID 35816LQ and the GDT CompanyLegalFormCode35800LQ is either zero or one 35830LQ.

For the listAgencyID 35832LQ, the Category is Attribute 35834LQ, theObject Class term is CodeListAgency 35836LQ, the Property term isIdentification 35838LQ, the Representation/Association term isIdentifier 35840LQ, the Type term is xsd 35842LQ, and the Type Name termis token 35844LQ. The Cardinality between the listAgencyID 35832LQ andthe GDT CompanyLegalFormCode 35800LQ is either zero or one 35846LQ.

For the listVersionID 35848LQ, the Category is Attribute 35850LQ, theObject Class term is CodeList 35852LQ, the Property term is Version35854LQ, the Representation/Association term is Identifier 35856LQ, theType term is xsd 35858LQ, and the Type Name term is token 35860LQ. Thecardinality between the listVersionID 35848LQ and the GDTCompanyLegalFormCode 35800LQ is either zero or one 35862LQ.

For the listAgencySchemeID 35864LQ, the Category is Attribute 35866LQ,the Object Class term is CodeListAgency 35868LQ, the Property term isScheme 35870LQ, the Representation/Association term is Identifier35872LQ, the Type term is xsd 35874LQ, and the Type Name term is token35876LQ. The cardinality between the listAgencySchemeID 35864LQ and theGDT CompanyLegalFormCode 35800LQ is either zero or one 35878LQ.

For the listAgencySchemeAgencyID 35880LQ, the Category is Attribute35882LQ, the Object Class term is CodeListAgency 35884LQ, the Propertyterm is SchemeAgency 35886LQ, the Representation/Association term isIdentifier 35888LQ, the Type term is xsd 35890LQ, and the Type Name termis token 35892LQ. The cardinality between the listAgencySchemeAgencyID35880LQ and the GDT CompanyLegalFormCode 35800LQ is either zero or one35894LQ.

There are only alternative code lists that differ at configurationand/or runtime.

The GDT CompanyLegalFormCode 35800LQ is a customer-specific code list.In some variations, the attributes are used as follows:

listID=“10332”

listAgencyID—The ID of the customer. An ID assigned by an organizationlisted in the DE 3055 must be used (such as the business IDs assigned byDUNS, EAN and SWIFT).

listVersionID—Version of the relevant code list.

listAgencySchemeID—The ID of the scheme by which the customer listed inthe listAgencyID is identified. This is a particular identificationscheme for partners, businesses, and members (such as DUNS+4) and so on,from an administering organization (such as EAN, DUNS and SWIFT) that islisted in the ListAgencySchemeAgency ID.

ListAgencySchemeAgencyID—the ID of the administering organization (suchas DUNS, EAN or SWIFT) that is responsible for identifying theorganization listed in the ListAgencyID.

Some examples of possible semantics for codes are: PLC The legal form isthat of a public limited company. Ltd The legal form is that of acompany with limited liability.

(uuuuuuuuuuuuuuuuuuuuuu) CustomerGroupCode

A GDT CustomerGroupCode 35800LR is the coded representation of a groupof customers. An example of the GDT CustomerGroupCode 35800LR is:

<CustomerGroupCode>1</CustomerGroupCode>

The structure of GDT CompanyLegalFormCode 35800LR is depicted in FIG.358LR. The GDT CompanyLegalFormCode 35800LR includes attributes listID35816LR, listAgencyID 35832LR, listVersionID 35848LR, listAgencySchemeID35864LR, and listAgencySchemeAgencyID 35880LR. For the GDTCompanyLegalFormCode 35800LR, the Object Class term is Customer Group35802LR, the Representation/Association term is Code 35806LR, the Typeterm is CCT 35808LR, the Type Name term is Code 35810LR, and the Lengthis either one or two 35812LR.

For the listID 35816LR, the Category is Attribute 35818LR, the ObjectClass term is CodeList 35820LR, the Property term is Identification35822LR, the Representation/Association term is Identifier 35822LR, theType term is xsd 35826LR, and the Type Name term is token 35828LR. Thecardinality between the listID 35816LR and the GDT CompanyLegalFormCode35800LR is either zero or one 35830LR.

For the listAgencyID 35832LR, the Category is Attribute 35834LR, theObject Class term is CodeListAgency 35836LR, the Property term isIdentification 35838LR, the Representation/Association term isIdentifier 35840LR, the Type term is xsd 35842LR, and the Type Name termis token 35844LR. The Cardinality between the listAgencyID 35832LR andthe GDT CompanyLegalFormCode 35800LR is either zero or one 35846LR.

For the listVersionID 35848LR, the Category is Attribute 35850LR, theObject Class term is CodeList 35852LR, the Property term is Version35854LR, the Representation/Association term is Identifier 35856LR, theType term is xsd 35858LR, and the Type Name term is token 35860LR. Thecardinality between the listVersionID 35848LR and the GDTCompanyLegalFormCode 35800LR is either zero or one 35862LR.

For the listAgencySchemeID 35864LR, the Category is Attribute 35866LR,the Object Class term is CodeListAgency 35868LR, the Property term isScheme 35870LR, the Representation/Association term is Identifier35872LR, the Type term is xsd 35874LR, and the Type Name term is token35876LR. The cardinality between the listAgencySchemeID 35864LR and theGDT CompanyLegalFormCode 35800LR is either zero or one 35878LR.

For the listAgencySchemeAgencyID 35880LR, the Category is Attribute35882LR, the Object Class term is CodeListAgency 35884LR, the Propertyterm is SchemeAgency 35886LR, the Representation/Association term isIdentifier 35888LR, the Type term is xsd 35890LR, and the Type Name termis token 35892LR. The cardinality between the listAgencySchemeAgencyID35880LR and the GDT CompanyLegalFormCode 35800LR is either zero or one35894LR.

In some variations, a customer-specific code list can be assigned to thecode. A customer determines the codes in the code list. For example, theattributes of the code are assigned the following values:

listID=“10335”

listAgencyID—ID of the SAP customer (ID from DE 3055, if listed there)

listVersionID—version of the particular code list. Assigned and managedby the SAP customer

listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055

listAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme

In some implementations, the GDT CustomerGroupCode 35800LR can be used,for example, in the sales order for pricing and statistics purposes.Some examples of the possible semantics of the codes are an Industrialenterprise, which is aCustomer group that includes industrialenterprises, a Commercial enterprise, which is a Customer group thatincludes commercial enterprises, and a Private customer, which is aCustomer group that includes private customers.

(vvvvvvvvvvvvvvvvvvvvvv) DueTypeCode

A GDT DueTypeCode 35800LS is the coded representation of the type of dueitem. A due item is a receivable or a payable.

<DueTypeCode>PAYMT</DueTypeCode>

The structure of GDT DueTypeCode 35800LS is depicted in FIG. 358LS. TheGDT DueTypeCode 35800LS includes attributes listID 35816LS, listAgencyID35832LS, listVersionID 35848LS, listAgencySchemeID 35864LS, andlistAgencySchemeAgencyID 35880LS. For the GDT DueTypeCode 35800LS, theObject Class term is Due 35802LS, the Property term is TYpe 35804LS, theRepresentation/Association term is Code 35806LS, the Type term is CCT35808LS, the Type Name term is Code 35810LS, and the Length is from oneto five 35812LS.

For the listID 35816LS, the Category is Attribute 35818LS, the ObjectClass term is CodeList 35820LS, the Property term is Identification35822LS, the Representation/Association term is Identifier 35822LS, theType term is xsd 35826LS, and the Type Name term is token 35828LS. Thecardinality between the listID 35816LS and the GDT DueTypeCode 35800LSis either zero or one 35830LS.

For the listAgencyID 35832LS, the Category is Attribute 35834LS, theObject Class term is CodeListAgency 35836LS, the Property term isIdentification 35838LS, the Representation/Association term isIdentifier 35840LS, the Type term is xsd 35842LS, and the Type Name termis token 35844LS. The Cardinality between the listAgencyID 35832LS andthe GDT DueTypeCode 35800LS is either zero or one 35846LS.

For the listVersionID 35848LS, the Category is Attribute 35850LS, theObject Class term is CodeList 35852LS, the Property term is Version35854LS, the Representation/Association term is Identifier 35856LS, theType term is xsd 35858LS, and the Type Name term is token 35860LS. Thecardinality between the listVersionID 35848LS and the GDT DueTypeCode35800LS is either zero or one 35862LS.

For the listAgencySchemeID 35864LS, the Category is Attribute 35866LS,the Object Class term is CodeListAgency 35868LS, the Property term isScheme 35870LS, the Representation/Association term is Identifier35872LS, the Type term is xsd 35874LS, and the Type Name term is token35876LS. The cardinality between the listAgencySchemeID 35864LS and theGDT DueTypeCode 35800LS is either zero or one 35878LS.

For the listAgencySchemeAgencyID 35880LS, the Category is Attribute35882LS, the Object Class term is CodeListAgency 35884LS, the Propertyterm is SchemeAgency 35886LS, the Representation/Association term isIdentifier 35888LS, the Type term is xsd 35890LS, and the Type Name termis token 35892LS. The cardinality between the listAgencySchemeAgencyID35880LS and the GDT DueTypeCode 35800LS is either zero or one 35894LS.

In some variations, the GDT DueTypeCode 35800LS is a customer-specificcode. Only one code list is permitted for each administrativeorganization (agency).

The attributes listID (=“10338”), listAgencyID, listVersionID,listAgencySchemeID, listAgencySchemeAgencyID are filled during runtimewith constant values that are customer-specific.

In some variations, the GDT DueTypeCode 35800LS is used to distinguishbetween different types of trade payables and receivables. This makes itpossible to have different views of the due items in the system. Thedifferentiation generated in this way can be used in FinancialAccounting to display the due items for specific G/L accounts. The legalrequirements of the respective country determine for which DueTypeCodesit is necessary to display the due items for specific G/L accounts. Thisis then specified in the configuration.

Some examples of the possible semantics of the codes are:

Invoice due item. An invoice due item is a due item that results from aninvoice.

Payment due item. A payment due item is a due item that results from apayment.

Down payment due item. A down payment due item is a due item thatresults from a down payment (payment made before the service isprovided).

Security retention amount. A security retention amount is a due itemresulting from an invoice of which a specific part cannot be paid to thepayee and must be retained (due to legal regulations).

(wwwwwwwwwwwwwwwwwwwwww) DurationRoleCode

A GDT DurationRoleCode 35800LT is a coded representation of the businessrole of a duration. An example of the GDT DurationRoleCode 35800LT is:

<DurationRoleCode>1</DurationRoleCode>

The structure of GDT DurationRoleCode 35800LT is depicted in FIG. 358LT.The GDT DurationRoleCode 35800LT includes attributes listAgencyID35814LT, listVersionID 35830LT, listAgencySchemeID 35846LT, andlistAgencySchemeAgencyID 35862LT. For the GDT DurationRoleCode 35800LT,the Property term is Duration Role 35802LT, theRepresentation/Association term is Code 35804LT, the Type term is xsd35806LT, the Type term is token 35808LT, the Type Name term is Code35810LT, and the Length is from one to three 35810LT. TheDurationRoleCode 35800LT may be restricted 35812LT.

For the listAgencyID 35814LT, the Category is Attribute 35816LT, theObject Class term is CodeListAgency 35818LT, the Property term isIdentification 35820LT, the Representation/Association term isIdentifier 35822LT, the Type term is xsd 35824LT, and the Type Name termis token 35826LT. The cardinality between the listAgencyID 35814LT andthe GDT DurationRoleCode 35800LT is either zero or one 35828LT.

For the listVersionID 35830LT, the Category is Attribute 35832LT, theObject Class term is CodeList 35834LT, the Property term is Version35836LT, the Representation/Association term is Identifier 35838LT, theType term is xsd 35840LT, and the Type Name term is token 35842LT. Thecardinality between the listVersionID 35830LT and the GDTDurationRoleCode 35800LT is either zero or one 35844LT.

For the listAgencySchemeID 35846LT, the Category is Attribute 35848LT,the Object Class term is CodeListAgency 35850LT, the Property term isScheme 35852LT, the Representation/Association term is Identifier35854LT, the Type term is xsd 35856LT, and the Type Name term is token35858LT. The cardinality between the listAgencySchemeID 35862LT and theGDT DurationRoleCode 35800LT is either zero or one 35860LT.

For the listAgencySchemeAgencyID 35862LT, the Category is Attribute35864LT, the Object Class term is CodeListAgency 35866LT, the Propertyterm is Scheme 35868LT, the Representation/Association term isIdentifier 35870LT, the Type term is xsd 35872LT, and the Type Name termis token 35874LT. The cardinality between the listAgencySchemeAgencyID35862LT and the GDT DurationRoleCode 35800LT is either zero or one35876LT.

In some variations, an extensible code list can be assigned to the code.A customer can replace this SAP code list with his own one. If theassigned code list remains unchanged, the attributes are assigned thefollowing values:

listID=“10396”

listAgencyID=“310”

listVersionID=version of the particular code list

If a customer creates his own code list, the values assigned to theattributes change as follows:

listAgencyID—ID of the SAP customer (ID from DE 3055, if listed there)

listVersionID—version of the particular code list. Assigned and managedby the customer

listAgencySchemeID—ID of the scheme if the listAgencyID does not comefrom DE 3055

listAgencySchemeAgencyID—ID of the organization from DE 3055 thatmanages the listAgencySchemeID scheme

The DurationRoleCode 35800LT is used to specify the semantic of aduration during runtime. Durations are typed with Duration or Quantity.

The DurationRoleCodes 35800LT cover all the business semantics ofdurations. As a result, the codes do also include all qualifiers of GDTDurations and those qualifiers of Quantity that are used for a timeduration. The DurationRoleCode 35800LT does not include the type name; arestriction to a subset of the available time-point types is notpossible. Identical Qualifiers and RoleCodes must have the same businesssemantic. As an example, the follow code may be used: Code NameDescription 1 ArrearsDuration 2 AverageDuration 3 ConfirmDuration 4ConfirmedDuration 5 DefaultDuration 6 DeliveryDuration 7 FixedDuration 8FloatDuration 9 IssueDuration 10 LagDuration 11 LeadTimeDuration 12LockDuration 13 MaximumDuration 14 MinimumDuration 15 NetDuration 16OrderToPickupDuration 17 PersonnelTimeDuration 18 PlannedDuration 19ProbationPeriodDuration 20 ProcessingDuration 21 ProductionDuration 22ReceiptDuration 23 ShippingDuration 24 TotalDuration 25TotalConfirmedDuration 26 VariableDuration

(xxxxxxxxxxxxxxxxxxxxxx) PaymentAllocationItemTypeCode

A GDT PaymentAllocationItemTypeCode 35800LU is a coded representation ofthe type of a PaymentAllocationItem. For example, aPaymentAllocationItem may be the allocation of part of a paymentregister item (an Item of the business object PaymentRegister) to apayment reason on the basis of which part of the payment register itemoccurred. A payment register item (an Item of the business objectPaymentRegister) may be a payment from a base payment businesstransaction that can consist of multiple parts with different paymentreasons. An example of GDT PaymentAllocationItemTypeCode 35800LU is:

<PaymentAllocationItemTypeCode>1</PaymentAllocationItemTypeCode>.

The structure of GDT PaymentAllocationItemTypeCode 35800LU is depictedin FIG. 358LU. For the GDT PaymentAllocationItemTypeCode 35800LU, theObject Class is PaymentAllocationItem 35804LU, the Property is Type35806LU, the Representation/Association is Code 35808LU, the Type is CCT35810LU, the Type Name is Code 35812LU, and the Length is from one totwo 35814LU. The remark 35818LU shows that the GDTPaymentAllocationItemTypeCode 35800LU may be restricted.

The data type GDT PaymentAllocationItemTypeCode 35800LU may have thefollowing attributes: listID (10095), listAgencyID (310), listVersionID(version of the relevant code list; assigned and managed by SAP AG).

The data type GDT PaymentAllocationItemTypeCode 35800LU may use thefollowing codes: 1 (i.e., partial deliveries are allowed), 2 (i.e., onlyone delivery on the requested delivery date/time is allowed), 3 (i.e.,only a complete delivery (the entire quantity) is allowed), 4 (i.e., orthe order only a complete delivery (the entire quantity) is allowed), 5(i.e., for the order only one delivery on the requested deliverydate/time is allowed), 6 (i.e., for the item only one delivery on therequested delivery date/time is allowed; partial deliveries for theorder are allowed), 7 (i.e., for the item only a complete delivery (theentire quantity) is allowed; partial deliveries for the order areallowed).

(yyyyyyyyyyyyyyyyyyyyyy) PaymentExplanationItemID

A GDT PaymentExplanationItemID 35800LV may be a unique identifier for anitem of a payment explanation. For example, an item of a paymentexplanation could contain the payment amount and information used toidentify a business document (such as, contract, invoice, credit memo,or sales order) that has initiated the payment transaction. An exampleof GDT PaymentExplanationItemID 35800LV is:

<PaymentExplanationItemID>001</PaymentExplanationItemID>

The structure of GDT PaymentExplanationItemID 35800LV is depicted inFIG. 358LV. For the GDT PaymentExplanationItemID 35800LV, the ObjectClass is PaymentExplanationItem 35804LV, the Property is Identification35806LV, the Representation/Association is Identifier 35808LV, the Typeis CCT 35810LV, the Type Name is Identifier 35812LV, and the Length isfrom one to three 35814LV. The remark 35818LV shows that the GDTPaymentExplanationItemID 35800LV may be restricted.

The data type GDT PaymentExplanationItemID 35800LV may uniquely identifyan item of a payment explanation together with the ID of thehigher-level object (contract, invoice, credit memo, or sales order) orthe payment ID.

(zzzzzzzzzzzzzzzzzzzzzz) PaymentMediumFormatSpecificFieldValue

A GDT PaymentMediumFormatSpecificFieldValue 35800LW is the value of apayment medium format-specific field that is not contained in the scopeof the fields provided by default for payment mediums. An example of GDTPaymentMediumFormatSpecificFieldValue 35800LW is:

<PaymentMediumFormatSpecificFieldValue><Code>SPRI

</Code></PaymentMediumFormatSpecificFieldValue>

The structure of GDT PaymentMediumFormatSpecificFieldValue 35800LW isdepicted in FIG. 358LW. For the GDTPaymentMediumFormatSpecificFieldValue 35800LW, the Object Class isPaymentMediumFormatSpecificFieldValue 35801LW, theRepresentation/Association is Details.

For the Code 35808LW, the Category is E 35809LW, the Object Class isPaymentMediumFormatSpecificFieldValue 35810LW, the Property is Code35811LW, the Representation/Association is Code 35812LW, the Type is GDT35813LW, the Type Name is PaymentMediumFormatSpecificFieldValueCode35814LW, and the Cardinality is zero or one 35815LW.

For the ID 35817LW, the Category is Attribute(E) 35818LW, the ObjectClass is PaymentMediumFormatSpecificFieldValue 35819LW, the Property isIdentification 35820LW, the Representation/Association is Identifier35821 LW, the Type is GDT 35822LW, the Type Name isPaymentMediumFormatSpecificFieldValueID 35823LW, and the Cardinality iszero or one 35824LW.

For the Text 35826LW, the Category is Attribute(E) 35827LW, the ObjectClass is PaymentMediumFormatSpecificFieldValue 35828LW, the Property isText 35829LW, the Representation/Association is Text 35830LW, the Typeis GDT 35831LW, the Type Name is PaymentMediumFormatSpecificFieldValueID35832LW, and the Cardinality is zero or one 35833LW.

For the IntegerValue 35835LW, the Category is Attribute(E) 35836LW, theObject Class is PaymentMediumFormatSpecificFieldValue 35837LW, theProperty is Integer Value 35838LW, the Representation/Association isValue 35839LW, the Type is GDT 35840LW, the Type Name is Integer Value35841LW, and the Cardinality is zero or one 35842LW.

For the Date 35844LW, the Category is Attribute(E) 35845LW, the ObjectClass is PaymentMediumFormatSpecificFieldValue 35846LW, the Property isDate 35847LW, the Representation/Association is Date 35848LW, the Typeis GDT 35849LW, the Type Name is Date 35850LW, and the Cardinality iszero or one 35851LW.

For the Time 35853LW, the Category is Attribute(E) 35854LW, the ObjectClass is PaymentMediumFormatSpecificFieldValue 35855LW, the Property isTime 35856LW, the Representation/Association is Time 35857LW, the Typeis GDT 35858LW, the Type Name is Time 35859LW, and the Cardinality iszero or one 35860LW.

For the Indicator 35862LW, the Category is Attribute(E) 35863LW, theObject Class is PaymentMediumFormatSpecificFieldValue 35864LW, theProperty is Indicator 35865LW, the Representation/Association isIndicator 35866LW, the Type is GDT 35867LW, the Type Name is Indicator35868LW, and the Cardinality is zero or one 35869LW.

The data type GDT PaymentMediumFormatSpecificFieldValue 35800LW may usethe following codes: Code(entry of a coded representation of an issue),ID(entry of an identification of an object), Text (text entry),IntegerValue (entry of an integral value), Date (entry of a calendarday), Time (entry of an exact time in seconds), Indicator (entry of abinary logical value), Amount (amount entry) Exactly one element fromthe quantity Code, ID, Text, IntegerValue, Date, Time, Indicator, orAmount must be entered.

The GDT PaymentMediumFormatSpecificFieldValue 35800LWNN is used togetherwith PaymentMediumFormatSpecificFieldID to make special entries requiredfor creating a valid payment medium. This fills fields in the paymentmedium that are required depending on the respective data medium formatand that have different semantics. This means that they cannot bestandardized due to the number of different semantics (such as the entryof the service level in an electronic bank transfer in S.W.I.F.T. MT 103format).

(aaaaaaaaaaaaaaaaaaaaaaa) PaymentMediumFormatSpecificFieldValueCode

A GDT PaymentMediumFormatSpecificFieldValueCode 35800LX is a codedrepresentation of any issue as a value of a payment mediumformat-specific field. An example of GDTPaymentMediumFormatSpecificFieldValueCode 35800LX is:

<PaymentMediumFormatSpecificFieldValueCode>SPRI

</PaymentMediumFormatSpecificFieldValueCode>

The structure of GDT PaymentMediumFormatSpecificFieldValueCode 35800LXis depicted in FIG. 358LX. For the GDTPaymentMediumFormatSpecificFieldValueCode 35800LX, the Object Class isPayment Medium Format Specific Field Value 35804LX, theRepresentation/Association is Code 35808LX, the Type is CCT 35810LX, theType Name is Code 35812LX, and the Length is from one to thirty 35814LX.The remark 35818LX shows that the GDTPaymentMediumFormatSpecificFieldValueCode 35800LX may be restricted.

The data type GDT PaymentMediumFormatSpecificFieldValueCode 35800LX maybe used to represent a coded issue that is required according to paymentmedium format specification to create a valid payment medium. However,it is not contained in the default elements of the business objectBankPaymentOrder.

(bbbbbbbbbbbbbbbbbbbbbbb) PaymentMedium

FormatSpecificFieldValueID

A GDT PaymentMediumFormatSpecificFieldValueID 35800LY is a uniqueidentifier for any issue as a value of a payment medium format-specificfield. For example, S.W.I.F.T. code of a bank to which a S.W.I.F.T.payment message should be forwarded. An example of GDTPaymentMediumFormatSpecificFieldValueID 35800LY is:

-   -   <PaymentMediumFormatSpecificFieldValueID>

COBADE01</PaymentMediumFormatSpecificFieldValueID>

The structure of GDT PaymentMediumFormatSpecificFieldValueID 35800LY isdepicted in FIG. 358LY. For the GDTPaymentMediumFormatSpecificFieldValueID 35800LY, the Object Class isPayment Medium Format Specific Field Value 35804LY, the Property isIdentification 35806LY, the Representation/Association is Identifier35808LY, the Type is CCT 35810LY, the Type Name is Identifier 35812LY,and the Length is from one to thirty-five 35814LY. The remark 35818LYshows that the GDT PaymentMediumFormatSpecificFieldValueID 35800LY maybe restricted.

The data type GDT PaymentMediumFormatSpecificFieldValueID 35800LY mayonly be used in the GDT PaymentMediumFormatSpecificFieldValue 35800LW.

The data type GDT PaymentMediumFormatSpecificFieldValueID 35800LY may beused to identify an issue that is required according to payment mediumformation specification to create a valid payment medium. However, it isnot contained in the default elements of the business objectBankPaymentOrder.

(ccccccccccccccccccccccc) RoomID

A GDT RoomID 35800LZ is a unique identifier of a room within a buildingor complex. An example of GDT RoomID 35800LZ is:

-   -   <RoomID>K2.01</RoomID>

The structure of GDT RoomID 35800LZ is depicted in FIG. 358LZ. For theGDT RoomID 35800LZ, the Object Class is Room 35804LZ, the Property isIdentification 35806LZ, the Representation/Association is Identifier35808LZ, the Type is CCT 35810LZ, the Type Name is Identifier 35812LZ,and the Length is from one to ten 35814LZ. The remark 35818LZ shows thatthe GDT RoomID 35800LZ may be restricted.

The data type GDT RoomID 35800LZ may be used in addresses.

(ddddddddddddddddddddddd) SamplingSchemeCode

A GDT SamplingSchemeCode 35800MA is a coded representation of a samplingscheme. For example, a sampling scheme is a collection of samplingplans. The sampling plan defines the sample size and the acceptance andrejection numbers. In doing so, it takes the total quantity to beinspected, the inspection severity (InspectionSeverityCode), and theAcceptable Quality Level (AQL) into consideration. An example of GDTSamplingSchemeCode 35800MA is:

-   -   <SamplingSchemeCode>S_PLAN01_(—)2859-1</SamplingSchemeCode>

The structure of GDT SamplingSchemeCode 35800MA is depicted in FIG.358MA. For the GDT SamplingSchemeCode 35800MA, the Object Class isSampling Scheme 35801MA, the Representation/Association is Code 35804MA,the Type is CCT 35805MA, the Type Name is Code 35806MA, and the Lengthis from one to fifteen 35807MA. The remark 35809MA shows that the GDTSamplingSchemeCode 35800MA may be restricted.

For the listAgencyID 35810MA, the Category is Attribute (A) 35811MA, theObject Class is CodeListAgency 35812MA, the Property is Identification35813MA, the Representation/Association is Identifier 35814MA, the Typeis XSD 35815MA, the Type Name is Token 35816MA, and the Cardinality iszero or one 35818MA.

For the ListVersionID 35820MA, the Category is Attribute (A) 35821MA,the Object Class is CodeListAgency 35822MA, the Property isIdentification 35823MA, the Representation/Association is Identifier35824MA, the Type is XSD 35825MA, the Type Name is Token 35826MA, andthe Cardinality is zero or one 35828MA.

For the ListVersionID 35830MA, the Category is Attribute (A) 35831MA,the Object Class is CodeList 35832MA, the Property is Version 35833MA,the Representation/Association is Identifier 35834MA, the Type is XSD35835MA, the Type Name is Token 35836MA, and the Cardinality is zero orone 35838MA.

For the ListAgency-SchemeID 35840MA, the Category is Attribute (A) 35841MA, the Object Class is CodeListAgency 35842MA, the Property is Scheme35843MA, the Representation/Association is Identifier 35844MA, the Typeis XSD 35845MA, the Type Name is Token 35846MA, and the Cardinality iszero or one 35848MA.

For the ListAgency-SchemeAgencyID 35850MA, the Category is Attribute (A)35851MA, the Object Class is CodeListAgency 35852MA, the Property isSchemeAgency 35853MA, the Representation/Association is Identifier35854MA, the Type is XSD 35855MA, the Type Name is Token 35856MA, andthe Cardinality is zero or one 35858MA.

The data type GDT SamplingSchemeCode 35800MA may use the followingcodes: listID (“10165”), listAgencyID (ID of the SAP customer (ID fromDE 3055 if listed there)), listVersionID (assigned and managed by theSAP customer), listAgencySchemeID (ID of the scheme if the listAgencyIDis not taken from DE 3055), listAgencySchemeAgencyID (ID of theorganization (taken from DE 3055) that manages the scheme of thelistAgencySchemeID).

For a sampling inspection using a sampling scheme, the data type GDTSamplingSchemeCode 35800MA contains the sampling scheme that is to beused.

(eeeeeeeeeeeeeeeeeeeeeee) ScheduleActivityEndDateTimeConstraintTypeCode

A GDT ScheduleActivityEndDateTimeConstraintTypeCode 35800MB is a codedrepresentation of the constraint for the end date/time of an activity.For example, an activity may be a task in a network or an operation in abill of operations. It has a defined start and a defined end.Types wouldthen be allocated according to the way in which a reference date/timerestricts the end date/time. An example of GDTScheduleActivityEndDateTimeConstraintTypeCode 35800MB is:  <ScheduleActivityEndDateTimeConstraintTypeCode>1</ScheduleActivityEndDateTimeConstraintTypeCode>

The structure of GDT ScheduleActivityEndDateTimeConstraintTypeCode35800MB is depicted in FIG. 358MB. For the GDTScheduleActivityEndDateTimeConstraintTypeCode 35800MB, the Object Classis ScheduleActivity 35804MB, the Property is EndDateTimeConstraintType35806MB, the Representation/Association is Code 35808MB, the Type is CCT35810MB, the Type Name is Code 35812MB, and the Length is one 35814MB.The remark 35818MB shows that the GDTScheduleActivityEndDateTimeConstraintTypeCode 35800MB may be restricted.

The value range of the data type GDT

ScheduleActivityEndDateTimeConstraintTypeCode 35800MBCT is anSAP-specific code list with fixed predefined values. The attributes ofthe CCT code are filled implicitly with the following values: listID(“10286”), listAgencyID (310), listVersionID (version of the relevantcode list assigned and managed by SAP AG).

The data type GDT ScheduleActivityEndDateTimeConstraintTypeCode 35800MBmay use the following codes: 1 (i.e., the end date/time must occur on/atthe latest possible date/time), 2 (i.e., the end date/time ispredefined), 3 (i.e., the end date/time may not occur before apredefined date/time), 4 (i.e., the end date/time may not occur after apredefined date/time).

(fffffffffffffffffffffff)ScheduleActivityStartDateTimeConstraintTypeCode

A GDT ScheduleActivityStartDateTimeConstraintTypeCode 35800MC is a codedrepresentation of the type of constraint for the start date/time of anactivity For example, an activity is a task in a network or an operationin a bill of operations. It has a defined start and a defined end. Typesare allocated according to the way in which a reference date/timerestricts the start date/time. An example of GDTScheduleActivityStartDateTimeConstraintTypeCode 35800MC is:  <ScheduleActivityStartDateTimeConstraintTypeCode>1</ScheduleActivityStartDateTimeConstraintTypeCode>

The structure of GDT ScheduleActivityStartDateTimeConstraintTypeCode35800MC is depicted in FIG. 358MC. For the GDTScheduleActivityStartDateTimeConstraintTypeCode 35800MC, the ObjectClass is ScheduleActivity 35804MC, the Property isStartDateTimeConstraintType 35806MC, the Representation/Association isCode 35808MC, the Type is CCT 35810MC, the Type Name is Code 35812MC,and the Length is one 35814MC. The remark 35818MC shows that the GDTScheduleActivityStartDateTimeConstraintTypeCode 35800MC may berestricted.

The value range of GDT ScheduleActivityStartDateTimeConstraintTypeCode35800MC is an SAP-specific code list with fixed predefined values. Theattributes of the CCT code are filled implicitly with the followingvalues: listID (“10285”), listAgencyID (310), listVersionID (version ofthe relevant code list).

The data type GDT ScheduleActivityStartDateTimeConstraintTypeCode35800MC may use the following codes: 1 (i.e., the start date/time mustoccur on/at the earliest possible date/time.), 2 (i.e., the startdate/time is predefined), 3 (i.e., the start date/time may not occurbefore a predefined date/time), 4 (i.e., the start date/time may notoccur after a predefined date/time).

(ggggggggggggggggggggggg) ServiceProductBasedValuationIndicator

Accounting is informed about internal service provisions so that it canvaluate and document them for the purposes of proper bookkeeping. Thisvaluation is normally based on the resource consumption, but it can alsobe based on the service product provided.

The ServiceProductBasedValuationIndicator is used in the line items ofthe accounting record regarding business transactions involving overheadcosts (business object OverheadCostLedgerAccount). It is set during thecreation of accounting documents and has no control function, serving toexplain the valuation in the document.

(hhhhhhhhhhhhhhhhhhhhhhh) SkipIndicator

The SkipIndicator can be used to display whether a material inspectionis to be skipped.

(iiiiiiiiiiiiiiiiiiiiiii) SkippedIndicator

The SkippedIndicator can be used to show that a quality inspection hasbeen skipped.

(jjjjjjjjjjjjjjjjjjjjjj) SetOfBooksCode

A GDT SetOfBooksCode 35800MD is a coded representation of a set ofbooks. For example, a set of books mat be a complete, self-contained,and consistent set of accounting figures within accounting. Completemeans that postings and relevant information on items in the balancesheet and profit and loss statement are included. Self-contained meansthat no external reference to other posted information in accounting isneeded to explain the content of a set of books. Consistent means thatthe posted data of a set of books are comparable as regards thestructure (fiscal year variant, currency, chart of accounts) and thesemantics (that is, based on an accounting principle or other rules orexceptions). An example of GDT SetOfBooksCode 35800MD is:

<SetOfBooksCode>L0</SetOfBooksCode>

The structure of GDT SetOfBooksCode 35800MD is depicted in FIG. 358MD.For the GDT SetOfBooksCode 35800MD, the Object Class is SetOfBooks35801MD, the Representation/Association is Code 35804MD, the Type is CCT35805MD, the Type Name is Code 35806MD, and the Length is from one tofour 35807MD. The remark 35809MD shows that the GDT SetOfBooksCode35800MD may be restricted.

For the ListID 35810MD, the, Category is Attribute (A) 35811MD, theObject Class is CodeList 35812MD, the Property is Identification35813MD, the Representation/Association is Identifier 35814MD, the Typeis XSD 35815MD, the Type Name is Token 35816MD, and the Cardinality iszero or one 35818MD.

For the ListAgencyID 35820MD, the Category is Attribute (A) 35821MD, theObject Class is CodeListAgency 35822MD, the Property is Identification35823MD, the Representation/Association is Identifier 35824MD, the Typeis XSD 35825MD, the Type Name is Token 35826MD, and the Cardinality iszero or one 35828MD.

For the ListVersionID 35830MD, the Category is Attribute (A) 35831MD,the Object Class is CodeList 35832MD, the Property is Version 35833MD,the Representation/Association is Identifier 35834MD, the Type is XSD35835MD, the Type Name is Token 35836MD, and the Cardinality is zero orone 35838MD.

For the ListAgency-SchemeID 35840MD, the Category is Attribute (A)35841MD, the Object Class is CodeListAgency 35842MD, the Property isScheme 35843MD, the Representation/Association is Identifier 35844MD,the Type is XSD 35845MD, the Type Name is Token 35846MD, and theCardinality is zero or one 35848MD.

For the ListAgency-SchemeAgencyID 35850MD, the Category is Attribute (A)35851MD, the Object Class is CodeListAgency 35852MD, the Property isSchemeAgency 35853MD, the Representation/Association is Identifier35854MD, the Type is XSD 35855MD, the Type Name is Token 35856MD, andthe Cardinality is zero or one 35858MD.

SetOfBooksCode is a customer-defined code list. The attributes are usedas follows:

The listID is an ID of the relevant code list. This is assigned andadministered by the organization responsible for the code list, which isnot listed in DE 3055. GDT owner must obtain the exact ID from theorganization responsible. If no unique ID is available, the name of therelevant code list or code type used in the corresponding standard,specification, or scheme of the responsible organization must beentered.

The listAgencyID is an ID of the administrative organization of the codelist. This ID is provided by the organization and is taken from DE 3055.(For exam-ple, the DUNS number or EAN number of a company). GDT ownermust obtain the relevant ID from the organization responsible.

The listVersionID is a version of the relevant code list. This isassigned and administered by the organization listed in thelistAgencyID. GDT owner must obtain the relevant versions ID from theorganization responsible. If no version has been issued for the codelist, the version of the standard, the specification, or the scheme mustbe used.

The listAgencySchemeID is the identification of the scheme once theorganization listed in the listAgencyID is identified. It is aparticular identification scheme for partners, businesses, and members(such as DUNS+4), and so on, of an administering organization (such asEAN, DUNS, and SWIFT) that is listed in the listAgencySchemeAgencyID.

The listAgencySchemeAgencyID is the ID of the managing organization (forexample, DUNS, EAN, SWIFT) that is responsible for identification of theorganization listed in the listAgencyID. It has to be listed in DE 3055.

In some implementations, the SetOfBooksCode may only be used in businessobjects and A2A messages. The set of books supports the integrationbetween the general ledger and the subledgers as well as cost accountingand profitability analysis. The subledgers, cost accounting, andprofitability analysis may be known to the set of books, and documentsmay be assigned to a single set of books.

The data type GDT SetOfBooksCode 35800MD may use the following codes:Tax Close (i.e., Set of books for tax purposes), Local Close (i.e., Setof books in compliance with local laws).

(kkkkkkkkkkkkkkkkkkkkkk) SourceOfSupplyBaseObjectTypeCode

A GDT SourceOfSupplyBaseObjectTypeCode 35800ME is a coded representationof the object a SourceOfSupply is based on. For example, aSourceOfSupply may be based on a business object or the part of abusiness object that is considered as source of supply in source ofsupply determination. The SourceOfSupply may copy the information thatis relevant for source of supply determination from the business objector from the part of the business object that it is based on. An exampleof GDT SourceOfSupplyBaseObjectTypeCode 35800ME is:

<SourceOfSupplyBaseObjectTypeCode>1</SourceOfSupplyBaseObjectTypeCode>

The structure of GDT SourceOfSupplyBaseObjectTypeCode 35800ME isdepicted in FIG. 358ME. For the GDT SourceOfSupplyBaseObjectTypeCode35800ME, the Object Class is Source Of Supply_Base Object 35804ME, theProperty is Type 35806ME, the Representation/Association is Code35808ME, the Type is CCT 35810ME, the Type Name is Code 35812ME, and theLength is from one to two 35814ME. The remark 35818ME shows that the GDTSourceOfSupplyBaseObjectTypeCode 35800ME may be restricted.

The attributes of the data type GDT SourceOfSupplyBaseObjectTypeCode35800ME are as follows: listID of “10401”, listAgencyID of “310”, andlistVersionID is a version of the relevant code list. The data type GDTSourceOfSupplyBaseObjectTypeCode 35800ME may use the following codes: 1(i.e., The source of supply is based on the valid materials of atransportation lane.), 2 (i.e., The source of supply is based on an itemof a purchasing contract.), 3 (i.e., The source of supply is based on apurchasing contract.), 4 (i.e., The source of supply is based on aproduction model.), 5 (i.e., The source of supply is based on a releasedplanning production model.).

(llllllllllllllllllllll) SourcesOfSupplySpecificationDetailLevelCode

A GDT SourcesOfSupplySpecificationDetailLevelCode 35800MF is a codedrepresentation of the level of detail of data for sources of supply.Whether a certain source of supply or a group of sources of supply isspecified depends on the level of detail. For example, something. Anexample of GDT SourcesOfSupplySpecificationDetailLevelCode 35800MF is:  <SourcesOfSupplySpecificationDetailLevelCode>1</SourcesOfSupplySpecificationDetailLevelCode>

The structure of GDT SourcesOfSupplySpecificationDetailLevelCode 35800MFis depicted in FIG. 358MF. For the GDTSourcesOfSupplySpecificationDetailLevelCode 35800MF, the Object Class isSources Of Supply Specification 35804MF, the Property is Detail Level35806MF, the Representation/Association is Code 35808MF, the Type is CCT35810MF, the Type Name is Code 35812MF, and the Length is one 35814MF.The remark 35818MF shows that the GDTSourcesOfSupplySpecificationDetailLevelCode 35800MF may be restricted.

A SupplyQuotaArrangement can be defined for a logistical relationship ofa source of supply, for a specific source of supply, for all sources ofsupply that belong to a particular location or for all sources of supplythat belong to a particular party. TheSourcesOfSupplySpecificationLevelCode can for example be used to definethis relationship.

The attributes of the data type GDTSourcesOfSupplySpecificationDetailLevelCode 35800MF are as follows:listID of “10399”, listAgencyID of “310”, and listVersionID is a versionof the particular code list. The data type GDTSourcesOfSupplySpecificationDetailLevelCode 35800MF may use thefollowing codes: 1 (i.e., A logistical relationship of a source ofsupply is specified. A logistical relationship is a relationship betweentwo locations that is used to procure and produce products. It defineslogistical characteristics.), 2 (i.e., A particular source of supply isspecified.), 3 (i.e., All sources of supply are specified based on alocation.), 4 (i.e., All sources of supply are specified based on aparty.).

(mmmmmmmmmmmmmmmmmmmmmmm) StreetName

A GDT StreetName 35800MG is a word or combination of words thatdescribe(s) a street name. An example of GDT StreetName 35800MG is:

<StreetName>Dietmar-Hopp-Allee</StreetName>

The structure of GDT StreetName 35800MG is depicted in FIG. 358MG. Forthe GDT StreetName 35800MG, the Property is Street 35806MG, theRepresentation/Association is Name 35808MG, the Type is GDT 35810MG, theType Name is Name 35812MG, the Length is from one to sixty 35814MG, thecardinality is zero or one 35816MG. The remark 35818MG shows that theGDT StreetName 35800MG may be restricted.

StreetName is not language dependent. The data type StreetName is usedin postal addresses.

(nnnnnnnnnnnnnnnnnnnnnn) SubledgerAccountChargeTypeCode

A GDT SubledgerAccountChargeTypeCode 35800MH is a coded representationof the type of debit or credit of a subledger account. An example of GDTSubledgerAccountChargeTypeCode 35800MH is:

<SubledgerAccountChargeTypeCode>1</SubledgerAccountChargeTypeCode>

The structure of GDT SubledgerAccountChargeTypeCode 35800MH is depictedin FIG. 358MH. For the GDT SubledgerAccountChargeTypeCode 35800MH, theObject Class is Subledger Account 35804MH, the Property is Charge_Type35806MH, the Representation/Association is Code 35808MH, the Type is CCT35810MH, the Type Name is Code 35812MH, and the Length is from one tothree 35814MH. The remark 35818MH shows that the GDTSubledgerAccountChargeTypeCode 35800MH may be restricted.

SubledgerAccountChargeTypeCode is used to describe the type of debit orcredit in different subledger accounts. The attributes of the data typeGDT SubledgerAccountChargeTypeCode 35800MH are as follows: listID of“10112”, listAgencyID of “310”, and listVersionID is the version of therelevant code list. The data type GDT SubledgerAccountChargeTypeCode35800MH may use the following codes: 1 (i.e., A credit on the subledgeraccount that is not one of the types described by the other codes.), 2(i.e., A debit on the subledger account.), 3 (i.e., A credit on thesubledger account that resulted from a goods receipt.), 4 (i.e., Acredit on the subledger account that resulted from a clearing run.).

(ooooooooooooooooooooooo) SupplyPlanningCostFunctionCode

A GDT SupplyPlanningCostFunctionCode 35800MI is a coded representationof a cost function in procurement planning. For example, the businesscost function in procurement planning may group abstract costs for aparticular quantity of a product. An example of GDTSupplyPlanningCostFunctionCode 35800MI is:

<SupplyPlanningCostFunctionCode>1</SupplyPlanningCostFunctionCode>

The structure of GDT SupplyPlanningCostFunctionCode 35800MI is depictedin FIG. 358MI. For the GDT SupplyPlanningCostFunctionCode 35800MI, theObject Class is Supply Planning_Cost Function 35801MI, theRepresentation/Association is Code 35804MI, the Type is CCT 35805MI, theType Name is Code 35806MI, and the Length is from one to two 35807MI.The remark 35809MI shows that the GDT SupplyPlanningCostFunctionCode35800MI may be restricted.

For the ListAgencyID 35810MI, the Category is Attribute (A) 35811MI, theObject Class is CodeListAgency 35812MI, the Property is Identification35813MI, the Representation/Association is Identifier 35814MI, the Typeis XSD 35815MI, the Type Name is Token 35816MI, and the Cardinality iszero or one 35818MI.

For the ListVersionID 35820MI, the Category is Attribute (A) 35821MI,the Object Class is CodeList 35822MI, the Property is Version 35823MI,the Representation/Association is Identifier 35824MI, the Type is XSD35825MI, the Type Name is Token 35826MI, and the Cardinality is zero orone 35828MI.

For the ListAgency-SchemeID 35830MI, the Category is Attribute (A)35831MI, the Object Class is CodeListAgency 35832MI, the Property isScheme 35833MI, the Representation/Association is Identifier 35834MI,the Type is XSD 35835MI, the Type Name is Token 35836MI, and theCardinality is zero or one 35838MI.

A customer-specific code list is assigned to the Code. The customerdefines the codes in the code list. The attributes of Code are assignedvalues as follows: listID of 10393, listAgencyID of the ID of the SAPcustomer (ID from DE 3055 if listed there), listVersionID is assignedand managed by the customer, listAgencySchemeID is the ID of the schemeif the listAgencyID is not taken from DE 3055, listAgencySchemeAgencyIDis the ID of the organization (taken from DE 3055) that manages thescheme of the listAgencySchemeID. In procurement planning, abstractcosts can be assigned to sources of supply in order to weight thesesources of supply. During source of supply determination, sources ofsupply can be selected on the basis of these costs. In the businessconfiguration settings, cost function can be defined for the materialsthat are to be procured, for example. The SupplyPlanningCostFunctionCodeis used to identify cost functions of this type. These costs are costsin an abstract sense. They are not costs from financial accounting orcontrolling. The data type GDT SupplyPlanningCostFunctionCode 35800MImay use the following codes: TransportMaterial A (i.e., Cost functionfor the transport of material A).

(Ppppppppppppppppppppppp) TaxDeclarationTypeCode

A GDT TaxDeclarationTypeCode 35800MJ is a coded representation of thetype of a tax declaration. For example, a tax declaration may be thedeclaration to a tax authority of tax payables and tax receivables of acompany. An example of GDT TaxDeclarationTypeCode 35800MJ is:

<TaxDeclarationTypeCode listID=21401>1</TaxDeclarationTypeCode>

The structure of GDT TaxDeclarationTypeCode 35800MJ is depicted in FIG.358MJ. For the GDT TaxDeclarationTypeCode 35800MJ, the Object Class isTax Declaration 35801MJ, the Property is Type 35803MJ, theRepresentation/Association is Code 35804MJ, the Type is CCT 35805MJ, theType Name is Code 35806MJ, and the Length is from one to three 35807MJ.The remark 35809MJ shows that the GDT TaxDeclarationTypeCode 35800MJ maybe restricted.

For the ListID 35810MJ, the Category is Attribute (A) 35811MJ, theObject Class is CodeList 35812MJ, the Property is Identification35813MJ, the Representation/Association is Identifier 35814MJ, the Typeis XSD 35815MJ, the Type Name is Token 35816MJ, and the Cardinality iszero or one 35818MJ.

Several fixed, country-specific code lists that are distinguished atruntime are assigned to the TaxDeclarationTypeCode. The two-charactercountry code according to ISO-3166-1 is used in the code list name. ThelistAgencyID=“310” (according to DE 3055) must be specified. TheTaxDeclarationTypeCode specifies the type of tax declaration, and inthis way defines implicitly which information is required and must bereported to the tax authority.

For DE, listID of “21401”, and listAgencyID of “310”, the data type GDTTaxDeclarationTypeCode 35800MJ may use the following codes: 1 (i.e.,Periodic VAT declaration), 2 (i.e., Annual VAT declaration), 3 (i.e.,Declaration of supplies to other EU Member States of goods that aresubject to VAT), 4 (i.e., Declaration of withholding tax that must bewithheld immediately on payment).

For US, listID of “21402”, and listAgencyID of “310”, the data type GDTTaxDeclarationTypeCode 35800MJ may use the following codes: 1 (i.e.,Declaration of sales tax to the US state tax authorities), 2 (i.e.,Income according to form “1099 Misc”), 3 (i.e., Income according to form“1042S”), 4 (i.e., Income according to form “10991NT”), 5 (i.e., Incomeaccording to form “1099G”).

TaxDeclarationTypeCodeContextElements define a dependency or anenvironment in which the TaxDeclarationTypeCode appears. The environmentis described by context categories. With the context categories inTaxDeclarationTypeCodeContext the valid set of code values ofTaxDeclarationTypeCode is restricted according to an environment duringuse. The Country Code is a context category that defines the contextcountry. This determines the valid code values for a specific country.The TaxTypeCode is a context category that defines the context tax type.This determines the valid code values for a specific tax type.

(qqqqqqqqqqqqqqqqqqqqqqq) TaxExemption

A GDT TaxExemption 35800MK is a party's complete or partial exemptionfrom a tax. An example of GDT TaxExemption 35800MK is: <TaxExemption><CertificateID >49314159123</ CertificateID > <ValidityPeriod ><StartDate>2005-01-01</StartDate> <EndDate>2005-12-31</EndDate></ValidityPeriod > </TaxExemption>

The structure of GDT TaxExemption 35800MK is depicted in FIG. 358MK. Forthe GDT TaxExemption 35800MK, the Object Class is Tax Exemption 35801MKand the Representation/Association is Details 35804MK.

For the CertificateID 35810MK, the Category is Element (E) 35811MK, theObject Class is Tax Exemption 35812MK, the Property Qualifier isCertificate 35817MK, the Property is Identification 35813MK, theRepresentation/Association is Identifier 35814MK, the Type is GDT35815MK, the Type Name is TaxExemptionCertificateID 35816MK, and theCardinality is one 35818MK.

For the ValidityPeriod 35820MK, the Category is Element (E) 35821MK, theObject Class is Tax Exemption 35822MK, the Property Qualifier isValidity 35827MK, the Property is Period 35823MK, theRepresentation/Association is DateTimePeriod 35824MK, the Type is GDT35825MK, the Type Name is DateTimePeriod 35826MK, and the Cardinality iszero or one 35828MK.

For the Percent 35830MK, the Category is Element (E) 35831MK, the ObjectClass is Tax Exemption 35832MK, the Property is Exempt Amount 35833MK,the Representation/Association is Percent 35834MK, the Type is GDT35835MK, the Type Name is Percent 35836MK, and the Cardinality is zeroor one 35839MK.

For the Amount 35840MK, the Category is Element (E) 35841MK, the ObjectClass is Tax Exemption 35842MK, the Property is Exempt 35843MK, theRepresentation/Association is Amount 35844MK, the Type is GDT 35845MK,the Type Name is Amount 35846MK, and the Cardinality is zero or one35848MK.

TaxExemption contains the following elements: CertificateID is theidentifier of the tax exemption certificate provided by the taxauthority, ValidityPeriod is the validity period of the tax exemption,Percent is the portion of the tax base rate that is exempt from tax andexpressed as a percent, Amount is the portion of the tax base rate thatis exempt from tax and expressed as an amount. Since tax exemption isbased on a certain tax type, the tax type may result from the context inwhich the GDT is used. The GDT TaxExemption is used to report a taxexemption that may exist after tax determination. This GDT is also usedfor tax exemption at the business partner.

(rrrrrrrrrrrrrrrrrrrrrr) TaxExemptionCertificateID

A GDT TaxExemptionCertificateID 35800ML is a unique identifier for a taxexemption certificate. For example, a tax exemption certificate may be acertificate that a tax authority issues for a certain party to grantthis party a tax exemption. An example of GDT TaxExemptionCertificateID35800ML is:

<TaxExemptionCertificateID>49314159123</TaxExemptionCertificateID>

The structure of GDT TaxExemptionCertificateID 35800ML is depicted inFIG. 358ML. For the GDT TaxExemptionCertificateID 35800ML, the ObjectClass is Tax Exemption Certificate 35804ML, the Property isIdentification 35806ML, the Representation/Association is Identifier35808ML, the Type is CCT 35810ML, the Type Name is Identifier 35812ML,and the Length is from one to thirty 35814ML.

Since a tax authority is responsible for issuing the identifier, thisidentifier is unique for a particular tax type within a specificcountry. The country and the tax type may be derived from the context inwhich the GDT is used. If necessary, the issuing tax authority may beidentified. A company that is exempted from tax sends the tax exemptioncertificate to its suppliers, who then take this tax exemption intoconsideration when they invoice the company. In some countries theTaxExemptionCertificateID may be printed on invoices with tax exemption.

(sssssssssssssssssssssss) TaxExemptionReasonCode

A GDT TaxExemptionReasonCode 35800MM is a coded representation of thereason for a tax exemption. For example, something. An example of GDTTaxExemptionReasonCode 35800MM is: <TaxExemptionReasonCodelistID=“21501” listAgencyID=“310“> 01 </TaxExemptionReasonCode>

The structure of GDT TaxExemptionReasonCode 35800MM is depicted in FIG.358MM. For the GDT TaxExemptionReasonCode 35800MM, the Object Class isTax Exemption 35801MM, the Property is Reason 35803MM, theRepresentation/Association is Code 35804MM, the Type is CCT 35805MM, theType Name is Code 35806MM, and the Length is from one to three 35807MM.The remark 35809MM shows that the GDT TaxExemptionReasonCode 35800MM maybe restricted.

For the ListID 35810MM, the Category is Attribute (A) 35811MM, theObject Class is CodeList 35812MM, the Property is Identification35813MM, the Representation/Association is Identifier 35814MM, the Typeis XSD 35815MM, the Type Name is Token 35816MM, the Length is from oneto forty 35817MM, and the Cardinality is one 35818MM.

For the ListAgencyID 35820MM, the Category is Attribute (A) 35821MM, theObject Class is CodeListAgency 35822MM, the Property is Identification35823MM, the Representation/Association is Identifier 35824MM, the Typeis XSD 35825MM, the Type Name is Token 35826MM, the Length is from oneto three 35827MM, and the Cardinality is zero or one 35828MM.

Several fixed, country-specific code lists that are distinguished atruntime are assigned to the TaxExemptionReasonCode. Information on thereason for the tax exemption may be needed for certain legally requiredtax declarations, for example. The code lists can contain official,legally specified codes and other codes. For the US tax authority IRS(US, listID of “21501”, listAgencyID of “310”) the data type GDTTaxExemptionReasonCode 35800MM may use the following legally requiredcodes: 1 (i.e., Income effectively connected with a U.S. trade orbusiness), 2 (i.e., Exempt under an Internal Revenue Code section,income other than portfolio interest), 3 (i.e., Income is not from U.S.sources), 4 (i.e., Exempt under tax treaty), 5 (i.e., Portfolio interestexempt under an Internal Revenue Code section), 6 (i.e., Qualifiedintermediary that assumes primary withholding responsibility), 7 (i.e.;Withholding foreign partnership or withholding foreign trust), 8 (i.e.,U.S. branch treated as a U.S. person), 9 (i.e., Qualified intermediaryrepresents income is exempt), 99 (i.e., Special), 00 (i.e., Special).

(tttttttttttttttttttttt) ExpenseReportLocationCategoryCode

A GDT ExpenseReportLocationCategoryCode 35800MN is the codedrepresentation of the category of a location based on its meaning in anexpense report. An example of the GDT ExpenseReportLocationCategoryCode35800MN is:

<ExpenseReportLocationCategoryCode>1</ExpenseReportLocationCategoryCode>

The structure of GDT ExpenseReportLocationCategoryCode 35800MN isdepicted in FIG. 358MN. For the GDT ExpenseReportLocationCategoryCode35800MN, the Object Class term is Expense Report Location 35802MN, theProperty term is Category 35804MN, the Representation/Association termis Code 35808MN, the Type term is CCT 35808MN, the Type Name term isCode 35810MN, and the Length is from one to fifteen 35812MN. TheExpenseReportLocationCategoryCode 35800MN may be restricted 35814MN.

In some variations, the value range of ExpenseReportLocationCategoryCode(listID=“10169”) can consist of a customer-specific code list. In someimplementations, the ExpenseReportLocationCategoryCode 35800MN cancurrently be used only in business objects. Some examples ofExpenseReportLocationCategoryCodes 35800MN are at home, representing acity of the residence of the expense reporter, and work center,representing a city of the permanent work center of the expensereporter.

(uuuuuuuuuuuuuuuuuuuuuuu)TradeReceivablesPayablesRegisterGroupingCriterionCode

A GDT TradeReceivablesPayablesRegisterGroupingCriterionCode 35800MO is acoded representation of a criterion to group trade receivables andpayables from goods and services. An example of GDTTradeReceivablesPayablesRegisterGroupingCriterionCode 35800MO is:

<TradeReceivablesPayablesRegisterGroupingCriterionCode>1</TradeReceivablesPayablesRegisterGroupingCriterionCode>

The structure of GDTTradeReceivablesPayablesRegisterGroupingCriterionCode 35800MO isdepicted in FIG. 358MO. For the GDTTradeReceivablesPayablesRegisterGroupingCriterionCode 35800MO, theObject Class is Trade Receivables Payables Register 35801MO, theProperty is Grouping Criterion 35803MO, the Representation/Associationis Code 35804MO, the Type is CCT 35805MO, the Type Name is Code 35806MO,and the Length is from one to two 35807MO. The remark 35809MO shows thatthe GDT TradeReceivablesPayablesRegisterGroupingCriterionCode 35800MOmay be restricted.

For the ListAgencyID 35810MO, the Category is Attribute (A) 35811MO, theObject Class is CodeListAgency 35812MO, the Property is Identification35813MO, the Representation/Association is Identifier 35814MO, the Typeis XSD 35815MO, the Type Name is Token 35816MO, and the Cardinality iszero or one 35818MO.

For the ListVersionID 35820MO, the Category is Attribute (A) 35821MO,the Object Class is CodeList 35822MO, the Property is Version 35823MO,the Representation/Association is Identifier 35824MO, the Type is XSD35825MO, the Type Name is Token 35826MO, and the Cardinality is zero orone 35828MO.

For the ListAgency-SchemeID 35830MO, the Category is Attribute (A)35831MO, the Object Class is CodeListAgency 35832MO, the Property isScheme 35833MO, the Representation/Association is Identifier 35834MO,the Type is XSD 35835MO, the Type Name is Token 35836MO, and theCardinality is zero or one 35838MO.

For the ListAgency-SchemeAgencyID 35840MO, the Category is Attribute (A)35841MO, the Object Class is CodeListAgency 35842MO, the Property isSchemeAgency 35843MO, the Representation/Association is Identifier35844MO, the Type is XSD 35845MO, the Type Name is Token 35846MO, andthe Cardinality is zero or one 35848MO.

An extendable code list is assigned to theTradeReceivablesPayablesRegisterGroupingCriterionCode. Customers canchange this code list. In its unchanged state, the code list has thefollowing attributes: listID of “10252”, listAgencyID of “310”,listVersionID is a version of the relevant code list. If a customermakes changes to the code list, the values assigned to the attributeschange as follows: listAgencyID is the ID of the customer (ID from DE3055 if listed there), listVersionID is assigned and managed by thecustomer, listAgencySchemeID is the ID of the scheme if the listAgencyIDis not taken from DE 3055, listAgencySchemeAgencyID is the ID of theorganization (taken from DE 3055) that manages the scheme of thelistAgencySchemeID.

A TradeReceivablesPayablesRegisterGroupingCriterionCode is used todefine further grouping criteria in addition to the process-specificgrouping criteria for open items. Existing attributes of the businessobject TradeReceivablesPayablesRegister can be used. Process-specificgrouping criteria are grouping criteria that may be considered within abusiness process for a grouping. Examples of process-specific groupingcriteria with an open item are payment recipient and payment sender.During the grouping of open items, open items that match in groupingcriteria are summarized. There can be a defaultTradeReceivablesPayablesRegisterGroupingCriterionCode in a company. Analternative TradeReceivablesPayablesRegisterGroupingCriterionCode can beentered for individual business partners (for example, a grouping bycontracts at specific customers).

The data type GDT TradeReceivablesPayablesRegisterGroupingCriterionCode35800MO may use the following codes: 1 (i.e., Grouping by contract).

(vvvvvvvvvvvvvvvvvvvvvvv) TransportationZoneID

A GDT TransportationZoneID 35800MP is a unique identifier for aTransportationZone. For example, a TransportationZone may be a zonecontaining geographical locations that may be considered collectivelyfor modelling or planning transportation routes or transportations. Anexample of GDT TransportationZoneID 35800MP is:

<TransportationZoneID>DE-POSTAL3-691XX</TransportationZoneID>

The structure of GDT TransportationZoneID 35800MP is depicted in FIG.358MP. For the GDT TransportationZoneID 35800MP, the Object Class isTransportationZone 35804MP, the Property is Identification 35806MP, theRepresentation/Association is Identifier 35808MP, the Type is CCT35810MP, the Type Name is Identifier 35812MP, and the Length is from oneto twenty 35814MP. The remark 35818MP shows that the GDTTransportationZoneID 35800MP may be restricted.

(wwwwwwwwwwwwwwwwwwwwwww) WorkAgreementTypeCode

A GDT WorkAgreementTypeCode 35800MQ is a coded representation of thetype of a work agreement, differentiated by the rights and obligationsof the employer and the employee. An example of GDTWorkAgreementTypeCode 35800MQ is:

<WorkAgreementTypeCode>5</WorkAgreementTypeCode>

The structure of GDT WorkAgreementTypeCode 35800MQ is depicted in FIG.358MQ. For the GDT WorkAgreementTypeCode 35800MQ, the Object Class isWorkAgreement 35804MQ, the Property is Type 35806MQ, theRepresentation/Association is Code 35808MQ, the Type is CCT 35810MQ, theType Name is Code 35812MQ, and the Length is from one to four 35814MQ.The remark 35818MQ shows that the GDT WorkAgreementTypeCode 35800MQ maybe restricted.

The classification of work agreements into work agreement types isrequired, for example, for headcount recording purposes. TheWorkAgreementTypeCode is a code list with fixed predefined values:listID of “10091”, listAgencyID of “310”, and listVersionID is a versionof the relevant code list. The data type GDT WorkAgreementTypeCode35800MQ may use the following codes: 1 (i.e., A permanent work agreemententered into by employer and employee. The agreement terminates uponnotice, dismissal, death, or retirement.), 2 (i.e., A work contractentered into by employer and employee for a fixed term.), 3 (i.e., Theexecutive contract regulates the internal terms of service between thesenior executive and the company, in other words, the conditions of theemployment relationship.), 4 (i.e., The training agreement regulates thecompany traineeship and is entered into by the company and thetrainee.), 5 (i.e., This agreement regulates the rights and obligationsof student workers, including students of vocational schools. Aprerequisite for a student worker agreement is that the student is afull-time student and only a part-time worker.), 6 (i.e., The retirementagreement regulates the benefits provided by the employer to theemployee on reaching retirement age.).

(xxxxxxxxxxxxxxxxxxxxxxx) WorkingDayCalendarcode

A GDT WorkingDayCalendarCode 35800MR is a coded representation of aworking day calendar. For example, a working day calendar may specifythe working and non workings days in a region or country. It mayconsider public holidays and general working days in a week. An exampleof GDT WorkingDayCalendarCode 35800MR is:

<WorkingDayCalendarCode>1</WorkingDayCalendarCode>

The structure of GDT WorkingDayCalendarCode 35800MR is depicted in FIG.358MR. For the GDT WorkingDayCalendarCode 35800MR, the Object Class isWorkingDayCalendar 35801MR, the Representation/Association is Code35804MR, the Type is CCT 35805MR, the Type Name is Code 35806MR, and theLength is from one to six 35807MR. The remark 35809MR shows that the GDTWorkingDayCalendarCode 35800MR may be restricted.

For the ListID 35810MR, the Category is Attribute (A) 3581 1MR, theObject Class is CodeList 35812MR, the Property is Identification35813MR, the Representation/Association is Identifier 35814MR, the Typeis XSD 35815MR, the Type Name is Token 35816MR, and the Cardinality iszero or one 35818MR.

For the ListAgencyID 35820MR, the Category is Attribute (A) 35821MR, theObject Class is CodeListAgency 35822MR, the Property is Identification35823MR, the Representation/Association is Identifier 35824MR, the Typeis XSD 35825MR, the Type Name is Token 35826MR, and the Cardinality iszero or one 35828MR.

For the ListVersionID 35830MR, the Category is Attribute (A) 35831MR,the Object Class is CodeList 35832MR, the Property is Version 35833MR,the Representation/Association is Identifier 35834MR, the Type is XSD35835MR, the Type Name is Token 35836MR, and the Cardinality is zero orone 35838MR.

For the ListAgency-SchemeID 35840MR, the Category is Attribute (A)35841MR, the Object Class is CodeListAgency 35842MR, the Property isScheme 35843MR, the Representation/Association is Identifier 35844MR,the Type is XSD 35845MR, the Type Name is Token 35846MR, and theCardinality is zero or one 35848MR.

For the ListAgency-SchemeAgencyID 35850MR, the Category is Attribute (A)35851MR, the Object Class is CodeListAgency 35852MR, the Property isSchemeAgency 35853MR, the Representation/Association is Identifier35854MR, the Type is XSD 35855MR, the Type Name is Token 35856MR, andthe Cardinality is zero or one 35858MR.

The attribute listAgencySchemeID and listAgencySchemeAgencyID can beomitted if the publishers of the code lists are listed in DE 3055. Theattribute listVersionID can be omitted if the code lists are notversioned. An extensible code list is assigned to the code. A customercan replace this code list with their own. If the code list remainsunchanged, the attributes are assigned the following values: listID isthe ID of the particular code list assigned by the Coaching Team,listAgencyID of “310”, listVersionID is the version of the particularcode list. If a customer creates their own code list, the valuesassigned to the attributes change as follows: listAgencyID is the ID ofthe customer (ID from DE 3055, if listed there), listVersionID is theversion of the particular code list,

listAgencySchemeID is the ID of the scheme if the listAgencyID does notcome from DE 3055, listAgencySchemeAgencyID is the ID of theorganization from DE 3055 that manages the listAgencySchemeID scheme.

WorkingDayCalendarCode is used when the handling of working and nonworking days is needed. The WorkingDayCalendarCode is used to identifythe definition of a working day calendar as well as the runtime objectthat allows performing calculations. In some Systems the Working DayCalendar identifies a Factory Calendar.

The data type GDT WorkingDayCalendarCode 35800MR may use the followingcodes: US (i.e., Working days are Mon-Fri, not on US public holidays).

(yyyyyyyyyyyyyyyyyyyyyyy) ExpenseTypeExpenseReporterGroupCode

A GDT ExpenseTypeExpenseReporterGroupCode 35800MV is the codedrepresentation of a group of expense reporters, whereby the group isbased on the expense types allowed for the expense report. An example ofthe GDT ExpenseTypeExpenseReporterGroupCode 35800MV is:

<ExpenseTypeExpenseReporterGroupCode>1</ExpenseTypeExpenseReporterGroupCode>

The structure of GDT ExpenseTypeExpenseReporterGroupCode 35800MV isdepicted in FIG. 358MV. For the GDT ExpenseTypeExpenseReporterGroupCode35800MV, the Object Class term is Expense Type Expense Reporter Group35802MV, the Representation/Association term is Code 35804MV, the Typeterm is CCT 35806MV, the Type Name term is Code 35808MV, and the Lengthis one 35810MV. The ExpenseTypeExpenseReporterGroupCode 35800MV may berestricted 35812MV.

In some implementations, a customer-specific code list can be assignedto the ExpenseTypeExpenseReporterGroupCode 35800MV. A customer candefine the codes in the code list.

As an example, the customer can set the Attribute of the GDTExpenseTypeExpenseReporterGroupCode 35800MV to be:

listID=10282

listAgencyID—ID of the customer

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme

listAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID

In some variations, the ExpenseTypeExpenseReporterGroupCode 35800MV cancurrently be used only in business objects. Some examples ofExpenseTypeExpenseReporterGroupCodes are expense reporters who are notallowed to submit entertainment receipts, and expense reporters who areallowed to submit receipts of all expense types.

(zzzzzzzzzzzzzzzzzzzzzzz) FindingTypeCode

A GDT FindingTypeCode 35800MW is a coded representation of the type of afinding. A finding is the result of an examination in the context of aninspection. The inspection can, for example, be a material inspection.An example of the GDT FindingTypeCode 35800MW is:

<FindingTypeCode>2</FindingTypeCode>

The structure of GDT FindingTypeCode 35800MW is depicted in FIG. 358MW.For the GDT FindingTypeCode 35800MW, the Object Class term is Finding35802MW, the Property term is Type 35804MW, theRepresentation/Association term is Code 35806MW, the Type term is CCT35808MW, the Type Name term is Code 35810MW, and the Length is from oneto fifteen 35812MW. The GDT FindingTypeCode 35800MW may be restricted35814MW.

In some variations, the GDT FindingTypeCode 35800MW can be acustomer-specific code list. Examples of the possible semantics ofcodes, as well as an example code list are contained in section 1.1.7Use. The attributes listID (“10162”), listAgencyID, listVersionID,listAgencySchemeID, listAgencySchemeAgencyID are missing from thestructure, as they were reserved for customer-specific values during theruntime.

In some variations, the FindingTypeCode 35800MW can be used for thedefinition and delimitation of a finding type. It describes theproperties required to record findings. These properties include theassignment of a code list or a number range assignment. Some examples ofpossible code values are Goods receipt finding, representing finding fora goods receipt inspection for delivered materials, Invoice finding,representing finding for cases where there is a discrepancy in aninvoice, and complaint finding, representing finding for a customercomplaint due to a defect in a product.

(aaaaaaaaaaaaaaaaaaaaaaaa) FixedAssetCalculationPeriodID

A GDT FixedAssetCalculationPeriodID 35800MX is a unique ID for acalculation period in Asset Accounting within a fiscal year. TheFixedAssetCalculationPeriodID 35800MX is used to divide the fiscal yearinto calculation periods for value calculation in Asset Accounting. Thecalculation periods can be different to the posting periods of FinancialAccounting. An example (Instance) of the GDTFixedAssetCalculationPeriodID 35800MX is:

<FixedAssetCalculationPeriodID>123</FixedAssetCalculationPeriodID>

The structure of GDT FixedAssetCalculationPeriodID 35800MX is depictedin FIG. 358MX. For the GDT FixedAssetCalculationPeriodID 35800MX, theObject Class term is Fixed Asset Calculation Period 35802MX, theProperty term is Identification 35804MX, the Representation/Associationterm is Identifier 35806MX, the Type term is CCT 35808MX, the Type Nameterm is Identifier 35810MX, and the Length is from one to three 35812MX.The GDT FixedAssetCalculationPeriodID 35800MX may be restricted 35814MX.

In some variations, the GDT FixedAssetCalculationPeriodID 35800MX may berepresented by a positive three-digit number. For example, the valuerange is from 1 to 366. The GDT FixedAssetCalculationPeriodID 35800MXcan currently be used only in business objects.

(bbbbbbbbbbbbbbbbbbbbbbbb) FixedAssetClassCode

A GDT FixedAssetClassCode 35800NA is the coded representation of a fixedasset class. The fixed asset class is a classification of fixed assets(FixedAssets) according to their type of valuation using fixed assetvaluation views (FixedAssetValuationViews). This is the main criterionin the grouping of fixed assets in accordance with business criteria andlegal requirements. An example of the GDT FixedAssetClassCode 35800NAis:

<FixedAssetClassCode>3000</FixedAssetClassCode>The structure of GDTFixedAssetClassCode 35800NA is depicted in FIG. 358NA. For the GDTFixedAssetClassCode 35800NA, the Object Class term is Fixed Asset35802NA, the Property term is Class 35804NA, theRepresentation/Association term is Code 35806NA, the Type term is CCT35808NA, the Type Name term is Code 35810NA, and the Length is from oneto eight 35812NA. The GDT FixedAssetClassCode 35800NA may be restricted35814NA.

In some implementations, a customer-specific code list can be assignedto the FixedAssetClassCode 35800NA. A customer can define the codes inthe code list.

The attributes of the FixedAssetValuationViewCode 35800NA are notrequired because they would be assigned to constant values in a customersystem at runtime. For example, they can be implicitly assigned in thefollowing way:

listID=“10142”

In some implementations, the FixedAssetClassCode can be used only inBusiness Object models. Some examples of possible codes are Buildings,Data processing/hardware, and Machines with the declining-balance methodof depreciation.

(cccccccccccccccccccccccc) FixedAssetID

A GDT FixedAssetID 35800NB is an ID for a fixed asset in the fixedassets of a company (Company). A fixed asset that is a view, defined forthe purposes of Financial Accounting, of usually one or more physicalobject, rights or other economic goods belonging to a company. These arein long-term use, are recognized in the financial statements at closing,and must be individually identifiable. It also includes the recording ofthe values for this view. An example (Instance) of the GDT FixedAssetID35800NB is:

<FixedAssetID>1</FixedAssetID>

The structure of GDT FixedAssetID 35800NB is depicted in FIG. 358NB. Forthe GDT FixedAssetID 35800NB, the Object Class term is Fixed Asset35802NB, the Property term is Identification 35804NB, theRepresentation/Association term is Identifier 35806NB, the Type term isCCT 35808NB, the Type Name term is Identifier 35810NB, and the Length isfrom one to four 35812NB. The GDT FixedAssetID 35800NB may be restricted35814NB.

In some variations, the FixedAssetID 35800NB can be uniquely identifiedby the MasterFixedAssetID from one or several fixed assets in thecontext of the company (Company) and of a business unit. The fixed assethas a unique number in a company (Company). This number has two parts—amain part and a sub-part (MasterFixedAssetID and FixedAssetID) The usercan use these parts to group fixed assets semantically. Using theFixedAssetID 35800NB it is possible to manage subsequent acquisitionsfor a fixed asset separately represent comprehensive complex fixedassets using sub-assets.

(dddddddddddddddddddddddd) FixedAssetValuationViewCode

A GDT FixedAssetValuationViewCode 35800NC is the coded representation ofa fixed asset valuation view. A fixed asset valuation view is a legallystipulated or calculation for cost accounting view for the valuation ofa part of fixed assets in a set of books. An example (Instance) of theGDT FixedAssetValuationViewCode 35800NC is:

<FixedAssetValuationViewCode>1</FixedAssetValuationViewCode>

The structure of GDT FixedAssetValuationViewCode 35800NC is depicted inFIG. 358NC. For the GDT FixedAssetValuationViewCode 35800NC, the ObjectClass term is Fixed Asset 35802NC, the Property term is Valuation View35804NC, the Representation/Association term is Code 35806NC, the Typeterm is CCT 35808NC, the Type Name term is Code 35810NC, and the Lengthis from one to six 35812NC. The GDT FixedAssetValuationViewCode 35800NCmay be restricted 35814NC.

In some variations, a customer-specific code list can be assigned to theFixedAssetValuationViewCode 35800NC. A customer can define the codes inthe code list. The attributes of the FixedAssetValuationViewCode 35800NCmay not be required because they would be assigned to constant values ina customer system at runtime. They are implicitly assigned in thefollowing way:

listID=“10143”

The FixedAssetValuationViewCode 35800NC is used only in the businessobject models and in configuration. Some examples of possible codes are:

GCC—valuation view for fixed assets in accordance with the GermanCommercial Code (GCC).

GCC Tax—valuation view for fixed assets in accordance with the GermanyCommercial Code (GCC) taking account of the tax law.

GCC Calc—calculation for cost accounting valuation view for internalAccounting.

IAS Group Valuation—valuation view for fixed assets in accordance withthe International Accounting Standard (IAS) for parallel valuation.

In many countries, in the local set of books, in addition to balancesheet-relevant reporting of fixed assets, another type of reporting isrequired for tax purposes. This is based on the same acquisition andproduction costs, however there are different depreciation methods. Asthese are local requirements and the identification of the acquisitionand production costs is necessary for the local financial statements,this data must be managed in the same set of books and is distinguishedby the fixed asset valuation view.

(eeeeeeeeeeeeeeeeeeeeeeee) FromOfAddressCode

A GDT FromOfAddressCode 35800ND is the coded representation of a form ofaddress. An example of the GDT FromOfAddressCode 35800ND is:

<FormOfAdressCode listAgencyID=310>0001</FormOfAdressCode>

The structure of GDT FormOfAddressCode 35800ND is depicted in FIG.358ND. The GDT FormOfAddressCode 35800ND includes attributes listID35816ND, listAgencyID 35832ND, listVersionID 35848ND, listAgencySchemeID35864ND, and listAgencySchemeAgencyID 35880ND. For the GDTFormOfAddressCode 35800ND, the Object Class term is Person 35802ND, theProperty term is Form of Address 35804ND, the Representation/Associationterm is Code 35806ND, the Type term is CCT 35808ND, the Type Name termis Code 35810ND, and the Length is either one or four 35812ND.

For the listID 35816ND, the Category is Attribute 35818ND, the ObjectClass term is CodeList 35820ND, the Property term is Identification35822ND, the Representation/Association term is Identifier 35822ND, theType term is xsd 35826ND, and the Type Name term is token 35828ND. Thecardinality between the listID 35816ND and the GDT ProductUsageCode35800ND is either zero or one 35830ND.

For the listAgencyID 35832ND, the Category is Attribute 35834ND, theObject Class term is CodeListAgency 35836ND, the Property term isIdentification 35838ND, the Representation/Association term isIdentifier 35840ND, the Type term is xsd 35842ND, and the Type Name termis token 35844ND. The Cardinality between the listAgencyID 35832ND andthe GDT FormOfAddressCode 35800ND is either zero or one 35846ND.

For the listVersionID 35848ND, the Category is Attribute 35850ND, theObject Class term is CodeList 35852ND, the Property term is Version35854ND, the Representation/Association term is Identifier 35856ND, theType term is xsd 35858ND, and the Type Name term is token 35860ND. Thecardinality between the listVersionID 35848ND and the GDTFormOfAddressCode 35800ND is either zero or one 35862ND.

For the listAgencySchemeID 35864ND, the Category is Attribute 35866ND,the Object Class term is CodeListAgency 35868ND, the Property term isScheme 35870ND, the Representation/Association term is Identifier35872ND, the Type term is xsd 35874ND, and the Type Name term is token35876ND. The cardinality between the listAgencySchemeID 35864ND and theGDT FormOfAddressCode 35800ND is either zero or one 35878ND.

For the listAgencySchemeAgencyID 35880ND, the Category is Attribute35882ND, the Object Class term is CodeListAgency 35884ND, the Propertyterm is SchemeAgency 35886ND, the Representation/Association term isIdentifier 35888ND, the Type term is xsd 35890ND, and the Type Name termis token 35892ND. The cardinality between the listAgencySchemeAgencyID35880ND and the GDT FormOfAddressCode 35800ND is either zero or one35894ND.

In some variations, an extendable code list can be assigned to theFormOfAddressCode 35800ND. Customers can change this code list. In itsunchanged state, the code list may have, for example, the followingattributes:

listID=“10120”

listAgencyID=“310”

listVersionID=Version of the relevant code list

If a customer makes changes to the assigned code list, the values of theattributes are changed as follows:

listAgencyID—ID of the SAP customer (ID from DE 3055 if listed there)

listVersionID—Assigned and managed by the SAP customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of the organization (taken from DE 3055)that manages the scheme of the listAgencySchemeID

In some variations, the GDT FormOfAdressCode 35800ND can be used for theform of address of a person, organization or group in addresses andbusiness partners. Code Name Description 0001 Ms. Ms. 0002 Mr. Mr. 0003Company Company 0004 Mr. and Mrs. Mr. and Mrs.

(ffffffffffffffffffffffff) GeneralLedgerAccountTypeCode

A GDT GeneralLedgerAccountTypeCode 35800NE is the coded representationof the type of a G/L account. A G/L account is a structure for storingchanges in value relating to assets, payables, stockholders' equity,revenues, or expenses of a company. A G/L account relates to exactly oneitem in a chart of accounts. G/L accounts are used essentially in thecreation of financial statements. Examples of G/L accounts: Tradereceivables or cumulated depreciation on buildings. An example of theGDT GeneralLedgerAccountTypeCode 35800NE is:

<GeneralLedgerAccountTypeCode>110</GeneralLedgerAccountTypeCode>

The structure of GDT GeneralLedgerAccountTypeCode 35800NE is depicted inFIG. 358NE. For the GDT GeneralLedgerAccountTypeCode 35800NE, the ObjectClass term is General Ledger Account 35802NE, the Property term is Type35804NE, the Representation/Association term is Code 35806NE, the Typeterm is CCT 35808NE, the Type Name term is Code 35810NE, and the Lengthis from one to six 35812NE. The GDT GeneralLedgerAccountTypeCode 35800NEmay be restricted 35814NE.

In some variations, he GeneralLedgerAccountTypeCode may be acustomer-specific code list. Additinally, the attribute “listID” may befilled implicitly, for example, with “10110”. TheGeneralLedgerAccountTypeCode 35800NE is currently only used in businessobjects.

Some examples of the possible semantics of the codes are: Fixed AssetAccount for fixed assets Inventory Account for material inventoriesLoans taken Account for loans taken Overhead Costs Account for overheadcosts

The GeneralLedgerAccountTypeCode 35800NE can be used to subdivide thegeneral ledger, such as into fixed asset accounts, accounts for materialinventories, or accounts for overhead costs. The subdivision is morerefined that the division into balance sheet accounts and accounts forthe profit and loss statement. A GeneralLedgerAccountTypeCode 35800NEcan be used to derive whether an account is an assets account or aliability account in the balance sheet or whether it is an expenseaccount or a revenue account in the profit and loss statement.

(gggggggggggggggggggggggg) GeneralLedgerAccountID

A GDT GeneralLedgerAccountID 35800NF is an identifier for a G/L account.

A G/L account is a structure for storing changes in value relating toassets, payables, stockholders' equity, revenues, or expenses of acompany. A G/L account relates to exactly one item in a chart ofaccounts. G/L accounts are used essentially in the creation of financialstatements. Some examples of G/L accounts are Trade receivables orcumulated depreciation on buildings. An example (Instance) of the GDTGeneralLedgerAccountID 35800NF is:

<GeneralLedgerAccountID>400000</GeneralLedgerAccountID>

The structure of GDT GeneralLedgerAccountID 35800NF is depicted in FIG.358NF. For the GDT GeneralLedgerAccountID 35800NF, the Object Class termis General Ledger Account 35802NF, the Property term is Type 35804NF,the Representation/Association term is Code 35806NF, the Type term isCCT 35808NF, the Type Name term is Code 35810NF, and the Length is fromone to ten 35812NF. The GDT GeneralLedgerAccountID 35800NF may berestricted 35814NF.

In some implementations, a GeneralLedgerAccountID may be a characterstring not exceeding ten characters. A G/L account is identifieduniquely by specifying, for example, a ChartOfAccountsID and aGeneralLedgerAccountID. Note, therefore, that the GeneralLedgerAccountID35800NF is only unique in the context of the chart of accounts. For thisreason, the GDT GeneralLedgerAccountReference containing both elementsshould usually be used to identify a G/L account.

If, however, the chart of accounts is known from the context (such asfrom a superordinate element), a G/L account can also be identified byspecifying the GDT GeneralLedgerAccountID 35800NF on its own.

(hhhhhhhhhhhhhhhhhhhhhhhh) GeneralLedgerMovementTypeCode

A GDT GeneralLedgerMovementTypeCode 35800NG is the coded representationof the type of movement on a G/L account within General LedgerAccounting.

<GeneralLedgerMovementTypeCode></GeneralLedgerMovementTypeCode>

The structure of GDT GeneralLedgerMovementTypeCode 35800NG is depictedin FIG. 358NG. For the GDT GeneralLedgerMovementTypeCode 35800NG, theObject Class term is General Ledger Account 35802NG, the Property termis Type 35804NG, the Representation/Association term is Code 35806NG,the Type term is CCT 35808NG, the Type Name term is Code 35810NG, andthe Length is from one six 35812NG. The GDTGeneralLedgerMovementTypeCode 35800NG may be restricted 35814NG.

In some variations, the GDT GeneralLedgerMovementTypeCode 35800NG(listID=“10394”) can be a customer-specific code list.

The GDT GeneralLedgerMovementTypeCode 35800NG may currently only be usedin business objects and A2A messages. Reporting requirements make itnecessary for changes to the balance of certain G/L accounts to berepresented at a greater level of refinement than as debit and credit.General ledger movement types describe movements from and to a G/Laccount in greater detail. Such details are required for the explanationof the difference between the opening balance and the closing balance ofa given period. General ledger movement types always relate to themovement of the individual item of a business transaction and cantherefore differ from one item to another item. Some examples of thepossible semantics of the codes are: Increase The inventory valueincreases due to an operational business transaction. Decrease Theinventory value decreases due to an operational business transaction.Write-up The inventory value increases due to a valuation in accounting.

The GDT GeneralLedgerMovementTypeCodes 35800 NG are related toDebitCreditTypeCodes (debit and credit) but are not subordinated to themhierarchically. Depending on the account to which the posting is made,increases/write-ups are usually posted in credit or debit, anddecreases/depreciation are posted on the opposite side of the account.Furthermore, some legal requirements for specifying theDebitCreditTypeCodes may switch this relationship in some cases.

(iiiiiiiiiiiiiiiiiiiiiii) DueTypeCode

A GDT DueTypeCode 35800NH is the coded representation of the type of dueitem. A due item is a receivable or a payable. An example of the GDTDueTypeCode 35800NH is:

<DueTypeCode>PAYMT</DueTypeCode>

The structure of GDT DueTypeCode 35800NH is depicted in FIG. 358NH. TheGDT DueTypeCode 35800NH includes attributes listID 35816NH, listAgencyID35832NH, listVersionID 35848NH, listAgencySchemeID 35864NH, andlistAgencySchemeAgencyID 35880NH. For the GDT DueTypeCode 35800NH, theObject Class term is Due 35802NH, the Property term is Type of Address35804NH, the Representation/Association term is Code 35806NH, the Typeterm is CCT 35808NH, the Type Name term is Code 35810NH, and the Lengthis either one or four 35812NH.

For the listID 35816NH, the Category is Attribute 35818NH, the ObjectClass term is CodeList 35820NH, the Property term is Identification35822NH, the Representation/Association term is Identifier 35822NH, theType term is xsd 35826NH, and the Type Name term is token 35828NH. Thecardinality between the listID 35816NH and the GDT ProductUsageCode35800NH is either zero or one 35830NH.

For the listAgencyID 35832NH, the Category is Attribute 35834NH, theObject Class term is CodeListAgency 35836NH, the Property term isIdentification 35838NH, the Representation/Association term isIdentifier 35840NH, the Type term is xsd 35842NH, and the Type Name termis token 35844NH. The Cardinality between the listAgencyID 35832NH andthe GDT DueTypeCode 35800NH is either zero or one 35846NH.

For the listVersionID 35848NH, the Category is Attribute 35850NH, theObject Class term is CodeList 35852NH, the Property term is Version35854NH, the Representation/Association term is Identifier 35856NH, theType term is xsd 35858NH, and the Type Name term is token 35860NH. Thecardinality between the listVersionID 35848NH and the GDT DueTypeCode35800NH is either zero or one 35862NH.

For the listAgencySchemeID 35864NH, the Category is Attribute 35866NH,the Object Class term is CodeListAgency 35868NH, the Property term isScheme 35870NH, the Representation/Association term is Identifier35872NH, the Type term is xsd 35874NH, and the Type Name term is token35876NH. The cardinality between the listAgencySchemeID 35864NH and theGDT DueTypeCode 35800NH is either zero or one 35878NH.

For the listAgencySchemeAgencyID 35880NH, the Category is Attribute35882NH, the Object Class term is CodeListAgency 35884NH, the Propertyterm is SchemeAgency 35886NH, the Representation/Association term isIdentifier 35888NH, the Type term is xsd 35890NH, and the Type Name termis token 35892NH. The cardinality between the listAgencySchemeAgencyID35880NH and the GDT DueTypeCode 35800NH is either zero or one 35894NH.

In some variations, the DueTypeCode 35800NH is a customer-specific code.Only one code list is permitted for each administrative organization(agency). The attributes listID (=“10338”), listAgencyID, listVersionID,listAgencySchemeID, listAgencySchemeAgencyID are filled during runtimewith constant values that are customer-specific. The DueTypeCode 35800NHis used to distinguish between different types of trade payables andreceivables. This makes it possible to have different views of the dueitems in the system.

The differentiation generated in this way can be used in FinancialAccounting to display the due items for specific G/L accounts. The legalrequirements of the respective country determine for which theDueTypeCodes 35800NH it is necessary to display the due items forspecific GIL accounts. This is then specified in the configuration. Someexamples of the possible semantics of the codes are an Invoice due item,which is an invoice due item is a due item that results from an invoice,a Payment due item, which is a payment due item is a due item thatresults from a payment, a Down payment due item, which is a down paymentdue item is a due item that results from a down payment (payment madebefore the service is provided), and a Security retention amount, whichis a security retention amount is a due item resulting from an invoiceof which a specific part cannot be paid to the payee and must beretained (due to legal regulations).

(jjjjjjjjjjjjjjjjjjjjjjjj) IdentityID

A GDT IdentityID 35800NI is an identifier for an Identity. An Identityis the combination of all user accounts of a person in a systemlandscape as well as of the settings required for system access and theassociated user rights and restrictions. An example of the GDTIdentityID 35800NI is:

<IdentityID>ACHIMMUELLER</IdentityID>

The structure of GDT IdentityID 35800NI is depicted in FIG. 358NI. TheGDT IdentityID 35800NI includes attributes SchemeID 35816NI,SchemeVersionID 35834NI, SchemeAgencyID 35852NI, schemeAgencySchemeID35870NI, and SchemeAgencySchemeAgencyID 35886NI. For the GDT IdentityID35800NI, the Object Class term is Identity 35802NI, the Property term isIdentification 35804NI, the Representation/Association term isIdentifier 35806NI, the Type term is CCT 35808NI, the Type Name term isIdentifier 35810NI, the TypeName term is Identifier 35012NI, and theLength is from one to fourty 35812NI. The GDT IdentityID 35800NI may berestricted 35814NI.

For the schemeID 35816NI, the Category is Attribute 35818NI, the ObjectClass term is IdentificationScheme 35820NI, the Property term isIdentification 35822NI, the Representation/Association term isIdentifier 35824NI, the Type term is xsd 35826NI, and the Type Name termis Token 35828NI, and the Length is from one to sixty 35830NI. Thecardinality between the schemeID 35816NI and the GDT IdentityID 35800NIis either zero or one 35832NI.

For the schemeVersionID 35834NI, the Category is Attribute 35836NI, theObject Class term is IdentificationScheme 35838NI, the Property term isVersion 35840NI, the Representation/Association term is Identifier35842NI, the Type term is xsd 35844NI, and the Type Name term is Token35846NI, and the Length is from one to fifteen 35848NI. The cardinalitybetween the schemeVersionID 35834NI and the GDT IdentityID 35800NI iseither zero or one 35850NI.

For the schemeAgencyID 35852NI, the Category is Attribute 35854NI, theObject Class term is IdentificationSchemeAgency 35856NI, the Propertyterm is Identification 35858NI, the Representation/Association term isIdentifier 35860NI, the Type term is xsd 35862NI, and the Type Name termis Token 35864NI, and the Length is from one to sixty 35866NI. Thecardinality between the schemeAgencyID 35852NI and the GDT IdentityID35800NI is either zero or one 35868NI.

For the schemeAgencySchemeID 35870NI, the Category is Attribute 35872NI,the Object Class term is IdentificationSchemeAgency 35874NI, theProperty term is Scheme 35876NI, the Representation/Association term isIdentifier 35878NI, the Type term is xsd 35880NI, and the Type Name termis Token 35882NI, and the Length is from one to three 35883NI. Thecardinality between the schemeAgencySchemeID 35870NI and the GDTIdentityID 35800NI is either zero or one 35884NI.

For the schemeAgencySchemeAgencyID 35886NI, the Category is Attribute35888NI, the Object Class term is IdentificationSchemeAgency 35890NI,the Property term is Scheme Agency 35892NI, theRepresentation/Association term is Identifier 35894NI, the Type term isxsd 35896NI, and the Type Name term is Token 35897NI, and the Length isfrom one to three 35898NI. The cardinality between theschemeAgencySchemeAgencyID 35886NI and the GDT IdentityID 35800NI iseither zero or one 35899NI.

In some variations, the values of the attributes of IdentityID 35800NIare assigned as follows:

schemeID—ID of the ID scheme. Released and maintained by the responsibleorganization of the ID scheme. The GDT owner must retrieve the correctID from the responsible organization. If there is no unique IDavailable, the name of the identifier or identifier type must beentered, which is used in the corresponding standard, specification, orscheme of the responsible organization.

schemeVersionID—Version of the ID scheme. Released and maintained by theorganization, which is named in schemeAgencyID. The owner must retrievethe relevant version ID from the responsible organization. If there isno version for the ID scheme, the version of the standard, thespecification, or the scheme is used.

schemeAgencyID—ID of the organization maintaining the ID scheme. Thisidentification is released by an organization contained in, for example,DE 3055 (e.g. DUNS, EAN . . . ).

schemeAgencySchemeID—the identification of the schema which identifiesthe organization named in schemeAgencyID. It's a certain scheme ID ofpartners, companies, members etc. (e.g. DUNS+4) of an organization namedin schemeAgencySchemeAgencyID (Bsp. EAN, DUNS, SWIFT, etc.)

schemeAgencySchemeAgencyID—identification of the maintainingorganization (e.g. DUNS, EAN, SWIFT, etc.) which is responsible for theidentification of the organization named in schemeAgencyID.

An IdentityID 35800NI is used for logging on to internet transactions.It is optional and valid across several systems.

(kkkkkkkkkkkkkkkkkkkkkkkk) Incoterms

A GDT Incoterms 35800NJ are typical contract formulations for deliveryconditions that correspond to the rules defined by the InternationalChamber of Commerce (ICC). An example of the GDT Incoterms 35800NJ is:<Incoterms> <ClassificationCode>FOB</ClassificationCode ><TransferLocationName>Hamburg</TransferLocationName> </Incoterms>

The structure of GDT Incoterms 35800NJ is depicted in FIG. 358NJ. TheGDT Incoterms 35800NJ includes elements Classification Code 35806NJ andTransferLocation 35822NJ. For the GDT Incoterms 35800NJ, the ObjectClass term is Incoterms 35802NJ and the Representation/Association termis Details 35804NJ.

For the Classification Code 35806NJ, the Category is element 35808NJ,the Object Class term is Incoterms 35810NJ, the Property isClassification 35812NJ, the Representation/Association term is Code35814NJ, the Type term is Code 35816NJ, and the Type Name term isIncoterms Classification Code 35818NJ. The Cardinality between theClassification Code 35806NJ and the GDT Incoterms 35800NJ is one35820NJ. The Classification Code 35806NJ may be restricted 35821NJ.

For the TransferLocation 35822NJ, the Category is element 35824NJ, theObject Class term is Incoterms 35826NJ, the Property is TransferLocation35828NJ, the Representation/Association term is Name 35830NJ, the Typeterm is GDT 35832NJ, the Type Name term is Incoterms Transfer LocationName 35834NJ, and the Length is from one to twenty-eight 35836NJ. TheCardinality between the Classification Code 35822NJ and the GDTIncoterms 35800NJ is from zero or one 35838NJ. The Classification Code35806NJ may be restricted 35840NJ.

In some variations, the ClassificationCode may a coded representation ofthe internationally used abbreviation for characterizing deliveryconditions, and the TransferLocationName may be Place (place, port ofshipment, port of destination, place of destination) to which the abovecode refers, for example, the port of shipment in the case of FOB.

In some variations, the GDT Incoterms 35800NJ can be used when apurchase order is transferred, in order to specify delivery conditionsto which the business partners have agreed.

(llllllllllllllllllllllll) IndividualMaterialInventoryID

A GDT IndividualMaterialInventoryID 35800NK is a unique ID for anindividual material that is stocked as physical inventory. Not allindividual material has to be stocked as inventory and have an inventorynumber. An example of the GDT IndividualMateriallnventoryID 35800NK is:

<IndividualMateriallnventoryID>669-ICK#15</IndividualMateriallnventoryID>

The structure of GDT IndividualMateriallnventoryID 35800NK is depictedin FIG. 358NK. For the GDT IndividualMaterialInventoryID 35800NK, theObject Class term is Individual Material 35802NK, the Property term isInventory Identification 35804NK, the Representation/Association term isIdentifier 35806NK, the Type term is CCT 35808NK, the Type Name term isCode 35810NK, and the Length is from one to twenty-five 35812NK. The GDTIndividualMateriallnventoryID 35800NK may be restricted 35814NK.

The IndividualMateriallnventoryID 35800NK is used only in BusinessObjects. In one example, the GDT IndividualMaterialInventoryID 35800NKmay be used in inventory to report on the current stock (amounts andvalues) of the inventory. In another example, the GDTIndividualMaterialInventoryID 35800NK may be used in the Business ObjectIndividual Material in addition to the ProductID as an alternative ID toshow that it is stocked in the inventory.

(mmmmmmmmmmmmmmmmmmmmmmmm) ActivityGroupCode

A GDT ActivityGroupCode 35800NM is a group of activities grouped usingsubjective criteria. An activity is used in Activity Management, todocument interactions with external business partners. Activitiesinclude receiving telephone calls, sending e-mails, and agreeing dates.An example of GDT ActivityGroupCode 35800NM is:

<ActivityGroupCode listAgencyld=“310”>1</ActivityGroupCode>

The structure of GDT ActivityGroupCode 35800NM is depicted in FIG.358NM. For the GDT ActivityGroupCode 35800NM, the Object Class isAcitivity 35801NM, the Property is Group 35802NM, theRepresentation/Association is Code 35803NM, the Type is CCT 35804NM, theType Name is Code 35805NM, and the Length is from one to four 35806NM.For listID, the category is A (Attribute) 35811NM, the object class isCodeList 35812NM, the property is Identification 35813NM, theRepresentation/Association is Identifier 35814NM, the type is xsd35815NM, the type name is token 35816NM, and the cardinality is fromzero to one 35818NM. For listAgencyID 35820NM, the category is A35811NM, the object class is CodeListAgency 35822NM, the property isIdentification 35823NM, the Representation/Association is Identifier35824NM, the type is xsd 35825NM, the type name is token 35826NM, andthe cardinality is from zero to one 35828NM. For listVersionID 35830NM,the category is A35831NM, the object class is CodeList35832NM, theproperty is Version 35833NM, the Representation/Association isIdentifier 35834NM, the type is xsd 35835NM, the type name is token35836NM, and the cardinality is from zero to one 35838NM. ForlistAgencySchemeID 35840NM, the category is A 35841NM, the object classis CodeListAgency 35842NM, the property is Scheme 35843NM, theRepresentation/Association is Identifier 35844NM, the type is xsd35845NM, the type name is token 35846NM, and the cardinality is fromzero to one 35848NM. For listAgencySchemeAgencyID 35850NM, the categoryis A 35851NM, the object class is CodeListAgency 35852NM, the propertyis SchemeAgency 35853NM, the Representation/Association is Identifier35854NM, the type is xsd 35855NM, the type name is token 35856NM, andthe cardinality is from zero to one 35858NM.

The data type GDT ActivityGroupCode 35800NM may use the following codes:1 Miscellaneous (i.e. Other information), 2 Customer Care (i.e.Activities for maintaining existing customers) and 3 New Business (i.e.Activities for acquiring new customers). The attributes are used asfollows:

listID—ID of corresponding code list assigned and managed by theorganization responsible for the code list, which is not listed in DE3055. The exact ID must be obtained by the GDT owner from theresponsible organization;

listAgencyID—ID of the organization managing the code list. This ID isassigned by the organization based on DE 3055 (for example, a company'sDUNS or EAN number). The relevant ID must be obtained by the GDT ownerfrom the responsible organization;

listID—Version of corresponding code list assigned and managed by theorganization specified in the listAgencyID. The relevant version ID mustbe obtained by the GDT owner from the responsible organization;

listAgencySchemeID—The scheme ID used to identify the organizationspecified in the listAgencyID; and

listAgencySchemeAgencyID—The ID of the managing organization—forexample, DUNS, EAN, SWIFT—that is responsible for identifying theorganization specified in the listAgencyID.

The data type ActivityGroupCode is primarily used in reporting. TheActivityGroupCode should not be used for coding communication channels.A number of business objects are available to this end. A Miscellaneouscategory should be defined in addition to the defined categories.

An example for the possible semantics of customer-specific code is KeyCustomer where the ActivityGroupCode groups activities according to keycustomers. This code is based on the Category property of RFC2445.

(nnnnnnnnnnnnnnnnnnnnnnnn) InspectionDynamicModificationRuleCode

A GDT InspectionDynamicModificationRuleCode 35800NN is a codedrepresentation of a dynamic modification rule. For example, the dynamicmodification rule contains the rules that regulate the dynamicmodification of a particular inspection process. It contains all of thepossible inspection stages for this process. Dynamic modification isused to reduce the scope of inspections and thereby reduce costs relatedto quality assurance. An example of the GDTInspectionDynamicModificationRuleCode 35800NN is:  <InspectionDynamicModificationRuleCode>3</InspectionDynamicModificationRuleCode>

The structure of GDT InspectionDynamicModificationRuleCode 35800NN isdepicted in FIG. 358NN. For the GDTInspectionDynamicModificationRuleCode 35800NN, the Object Class isInspection Dynamic Modification Rule 35804NN, theRepresentation/Association is Code 35808NN, the Type is CCT 35810NN, theType Name is Code 35812NN, and the Length is from one to fifteen35814NN. The remark 35818NN shows that the GDTInspectionDynamicModificationRuleCode 35800NN may be restricted.

A customer-specific code list may be assigned to the GDTInspectionDynamicModificationCriterionCode 35800NN. A customer maydefine the codes in the code list. The attributes of the GDTInspectionDynamicModificationCriterionCode 35800NN may be assignedvalues as follows: listID=“10146”, listAgencyID—ID of the custome,listVersionID—Assigned and managed by customer, listAgencySchemeID—ID ofthe scheme, and listAgencySchemeAgencyID—ID of the organization thatmanaged the scheme of the listAgencySchemeID.

(oooooooooooooooooooooooo) InspectionSampleSizeDeterminationTypeCode

A GDT InspectionSampleSizeDeterminationTypeCode 35800NO is a codedrepresentation of a type of determination used to determine the samplesize for an inspection. An example of the GDTInspectionSampleSizeDeterminationTypeCode 35800NO is:  <InspectionSampleSizeDeterminationTypeCode>2</InspectionSampleSizeDeterminationTypeCode>

The structure of the GDT InspectionSampleSizeDeterminationTypeCode35800NO is depicted in FIG. 358NO. For the GDTInspectionSampleSizeDeterminationTypeCode 35800NO, the Object Class isInspection Sample Size Determination 35804NO, the Property is Type35806NO, the Representation/Association is Code 35808NO, the Type is CCT35810NO, the Type Name is Code 35812NO, and the Length is one 35814NO.The remark 35818NO shows that the GDTInspectionSampleSizeDeterminationTypeCode 35800NO may be restricted.

The GDT InspectionSampleSizeDeterminationTypeCode 35800NOCT consists ofone fixed code list. The attributes contain the following values:listID=“10096”, listAgencyID=“310”, listVersionID—Version of therelevant code list. The InspectionSampleSizeDeterminationTypeCode35800NOCT is used in the context of an inspection and providesinformation about how the sample size is determined.

The data type GDT InspectionSampleSizeDeterminationTypeCode 35800NO mayuse the following codes: 1 (i.e., the sample size is predefined with afixed value), 2 (i.e., the sample size is calculated as a percentage ofthe inspection quantity), 3 (i.e., the sample size that is to bedetermined based on the sampling scheme), and 4 (i.e., the sample sizeis determined individually by the customer).

(pppppppppppppppppppppppp) InspectionSubsetTypeCode

A GDT InspectionSubsetTypeCode 35800NP is a coded representation of thetype of a subset in the context of an inspection. An example of the GDTInspectionSubsetTypeCode 35800NP is:

<InspectionSubsetTypeCode>1</InspectionSubsetTypeCode>

The structure of the GDT InspectionSubsetTypeCode 35800NP is depicted inFIG. 358NP. For the GDT InspectionSubsetTypeCode 35800NP, the ObjectClass is InspectionSubsetType 35801NP the Representation/Association isCode 35804NP, the Type is XSD35805NP, the Type Name is Token 35806NP,and the Length is from one to three 35807NP. The remark 35809NP showsthat the GDT InspectionSubsetTypeCode 35800NP may be restricted.

For the ListAgencyID 35810NP, the Category is Attribute (A) 35811NP, theObject Class is CodeListAgency 35812NP, the Property is Identification35813NP, the Representation/Association is Identifier 35814NP, the Typeis XSD 35815NP, the Type Name is Token 35816NP, and the Cardinality iszero or one 35818NP.

For the ListVersionID 35820NP, the Category is Attribute (A) 35821NP,the Object Class is CodeList 35822NP, the Property is Version 35823NP,the Representation/Association is Identifier 35824NP, the Type is XSD35825NP, the Type Name is Token 35826NP, and the Cardinality is zero orone 35828NP.

For the ListAgency-SchemeID 35830NP, the Category is Attribute (A)35831NP, the Object Class is CodeListAgency 35832NP, the Property isScheme 35833NP, the Representation/Association is Identifier 35834NP,the Type is XSD 35835NP, the Type Name is Token 35836NP, and theCardinality is zero or one 35838NP.

For the ListAgency-SchemeAgencyID 35840NP, the Category is Attribute (A)35841NP, the Object Class is CodeListAgency 35842NP, the Property isSchemeAgency 35843NP, the Representation/Association is Identifier35844NP, the Type is XSD 35845NP, the Type Name is Token 35846NP, andthe Cardinality is zero or one 35848NP.

An extendable code list may be assigned to the code. The customers mayreplace lists with their own. In its unchanged state, the code list hasthe following attributes: listID=“10406”, listAgencyID=“310”,listVersionID=[Version of the relevant code list. If the customercreates a code list, the attributes change as follows: listAgencyID—IDof the customer, listVersionID—Assigned and managed by the customer,listAgencySchemeID—ID of the scheme, listAgencySchemeAgencyID—ID of theorganization that manages the scheme of the listAgencySchemeID. TheInspectionSubsetTypeCode describes the process in which the inspectionquantity is to be divided into subsets and where this process takesplace. In the context of a material inspection, for example, subsets maybe formed in the goods receipt or goods issue processes.

The data type GDT InspectionSubsetTypeCode 35800NP may use the followingcodes: 1 (i.e., subsets are formed in the material inspection in thegoods receipt process), and 2 (i.e., subsets are formed in the materialinspection in the goods issue process).

(qqqqqqqqqqqqqqqqqqqqqqqq) LeadQualificationLevelCode

A GDT LeadQualificationLevelCode 35800NQ is a coded representation ofthe qualification level of a Lead. For example, a Lead is a businesstransaction that describes the potential or projected business interestsof a business partner and the interactions based on this over a periodof time. A qualification level is the result of the qualificationprocess. The qualification process is the determination of the businesspartner's interest in a product, or the business partner's willingnessto purchase a product; this takes place on the basis of collectedinformation and different interactions with the business partner. Anexample of the GDT LeadQualificationLevelCode 35800NQ is:

<LeadQualificationLevelCode>1</LeadQualificationLevelCode>

The structure of the GDT LeadQualificationLevelCode 35800NQ is depictedin FIG. 358NQ. For the GDT LeadQualificationLevelCode 35800NQ, theObject Class is Lead 35804NQ, the Property is QualificationLevel35806NQ, the Representation/Association is Code 35808NQ, the Type is CCT35810NQ, the Type Name is Code 35812NQ, and the Length is from one totwo 35814NQ. The remark 35818NQ shows that the GDTLeadQualificationLevelCode 35800NQ may be restricted.

A fixed code list may be assigned to the GDT LeadQualificationLevelCode35800NQ. The attributes may be as follows: listID=“10297”,listAgencyID=“310”. The data type GDT LeadQualificationLevelCode 35800NQmay use the following codes: 1 (i.e., the customer has little potentialinterest), 2 (i.e., the customer has a potential interest), and 3 (i.e.,the customer has a great potential interest).

(rrrrrrrrrrrrrrrrrrrrrrrr) LegallyRequiredPhraseText

A GDT LegallyRequiredPhraseText 35800NR is a legally required phrasethat must be printed on the invoice. An example of the GDTLegallyRequiredPhraseText 35800NR is:

<LegallyRequiredPhraseText>eine Phrase </LegallyRequiredPhraseText>

The structure of the GDT LegallyRequiredPhraseText 35800NR is depictedin FIG. 358NR. For the GDT LegallyRequiredPhraseText 35800NR, theRep./Ass.Qual. is Legally Required Phrase 35806NR, theRepresentation/Association is Type 35808NR, the Type is GDT 35810NR, theType Name is Text 35812NR, and the Length is from one to two hundredfifty five 35814NR.

The GDT LegallyRequiredPhraseText 35800NR may only be used within theGDT ProductTax.

(ssssssssssssssssssssssss) LocationRoleCategoryCode

A GDT LocationRoleCategoryCode 35800NS is a coded representation of aLocationRoleCategory. For example, a LocationRoleCategory is a divisionof LocationRoles according to process-controlling criteria. ALocationRole with the same name exists for each LocationRoleCategory. Anexample of the GDT LocationRoleCategoryCode 35800NS is:

<LocationRoleCategoryCode>1</LocationRoleCategoryCode>

The structure of the GDT LocationRoleCategoryCode 35800NS is depicted inFIG. 358NS. For the GDT LocationRoleCategoryCode 35800NS, the ObjectClass is Location 35804NS, the Property is Role 35806NS, theRepresentation/Association is Code 35808NS, the Type is CCT 35810NS, theType Name is Code 35812NS, and the Length is from one to three 35814NS.

A fixed code list may be assigned to the GDT LocationRoleCategoryCode35800NS. The attributes may be as follows: listID=“10300”,listAgencyID=“310”, and listVersionID=Version of the relevant code list.

The data type GDT LocationRoleCategoryCode 35800NS may use the followingcodes: 1 (i.e., a ShipToLocation is a location to which the goods are tobe delivered (in particular B2B communication)), 2 (i.e., aShipFromLocation is a location from which the goods are to be delivered(in particular B2B communication)), 3 (i.e., a MeetingPlace is alocation that specifies a meeting point), 4 (i.e., a ReceivingLocationis a location to which the goods are to be delivered (from amacro-logistic perspective)), 5 (i.e., a SendingLocation is a locationfrom which the goods are to be delivered (from a macro-logisticperspective)), and 8 (i.e., a ServicePoint is a location at which aservice is provided).

(tttttttttttttttttttttttt) LocationRoleCode

A GDT LocationRoleCode 35800NT is a coded representation of aLocationRole. For example, a LocationRole specifies the significance ofthe Location for a business objectGlobal Data Types—Definitionen andcorresponding processes. A LocationRole is assigned to exactly oneLocationRoleCategory and refines its semantics. An example of the GDTLocationRoleCode 35800NT is:

<LocationRoleCode>1</LocationRoleCode>

The structure of the GDT LocationRoleCode 35800NT is depicted in FIG.358NT. For the GDT LocationRoleCode 35800NT, the Object Class isLocation 35801NT, the Property is Role 35803NT, theRepresentation/Association is Code 35804NT, the Type is CCT 35805NT, theType Name is Code 35806NT, and the Length is from one to ten 35807NT.The remark 35809NT shows that the GDT LocationRoleCode 35800NT may berestricted.

For the ListAgencyID 35810NT, the Category is Attribute (A) 35811NT, theObject Class is CodeListAgency 35812NT, the Property is Identification35813NT, the Representation/Association is Identifier 35814NT, the Typeis XSD 35815NT, the Type Name is Token 35816NT, and the Cardinality iszero or one 35818NT.

For the ListVersionID 35820NT, the Category is Attribute (A) 35821NT,the Object Class is CodeList 35822NT, the Property is Version 35823NT,the Representation/Association is Identifier 35824NT, the Type is XSD35825NT, the Type Name is Token 35826NT, and the Cardinality is zero orone 35828NT.

For the ListAgency-SchemeID 35830NT, the Category is Attribute (A)35831NT, the Object Class is CodeListAgency 35832NT, the Property isScheme 35833NT, the Representation/Association is Identifier 35834NT,the Type is XSD 35835NT, the Type Name is Token 35836NT, and theCardinality is zero or one 35838NT.

For the ListAgency-SchemeAgencyID 35840NT, the Category is Attribute (A)35841NT, the Object Class is CodeListAgency 35842NT, the Property isSchemeAgency 35843NT, the Representation/Association is Identifier35844NT, the Type is XSD 35845NT, the Type Name is Token 35846NT, andthe Cardinality is zero or one 35848NT.

An extendable code list may be assigned to the GDT LocationRoleCode35800NT. The customers may replace the lists with their own. In itsunchanged state, the code list may have the following attributes:listID=10301, listAgencyID=“310”, llistVersionID=[Version of therelevant code list]. If a customer creates a code list, the attributeschange as follows: listAgencyID—ID of the customer,listVersionID—Assigned and managed by the customer,listAgencySchemeID—ID of the scheme, and listAgencySchemeAgencyID—ID ofthe organization that manages the scheme of the listAgencySchemeID.

The data type GDT LocationRoleCode 35800NT may use the following codes:1 (i.e., a ShipToLocation is a location to which a good is to bedelivered), 2 (i.e., a ShipFromLocation is a location from which a goodis to be delivered), 3 (i.e., a MeetingPlace is a location thatspecifies a meeting point), 4 (i.e., a ReceivingLocation is a locationto which the goods are to be delivered (from a macro-logisticperspective)), 5 (i.e., A SendingLocation is a location from which thegoods are to be delivered (from a macro-logistic perspective)), and 8(i.e., a ServicePoint is a location at which a service is provided).

(uuuuuuuuuuuuuuuuuuuuuuuu) MasterFixedAssetID

A GDT MasterFixedAssetID 35800NU identifies a business unit within acompany from one or several fixed assets that are depreciatedindividually, but it must be possible to represent their values togetherand maintain their data together. The first fixed asset has a specialrole. The master data is maintained in it. This data can be copied toadditional corresponding fixed assets. For example, a fixed asset thatis a view, defined for the purposes of Financial Accounting, of usuallyone or more physical object, rights or other economic goods belonging toa company. These are in long-term use, are recognized in the financialstatements at closing, and must be individually identifiable. It alsoincludes the recording of the values for this view. An example of theGDT MasterFixedAssetID 35800NU is:

<MasterFixedAssetID>1</MasterFixedAssetID>

The structure of the GDT MasterFixedAssetID 35800NU is depicted in FIG.358NU. For the GDT MasterFixedAssetID 35800NU, the Object Class isMaster Fixed Asset 35804NU, the Property is Identification 35806NU, theRepresentation/Association is Identifier 35808NU, the Type is CCT35810NU, the Type Name is Identifier 35812NU, and the Length is from oneto twelve 35814NU. The remark 35818NU shows that the GDTMasterFixedAssetID 35800NU may be restricted.

The fixed asset has a unique number in a company (Company). This numbermay have two parts—a main part and a sub-part (MasterFixedAssetID35800NU and FixedAssetID). The user may use these parts to group fixedassets semantically.

(vvvvvvvvvvvvvvvvvvvvvvvv) MaternityProtectionDeliveryTypeCode

A GDT MatemityProtectionDeliveryTypeCode 35800NV is a codedrepresentation of the type of a delivery of a child according tomaternity protection regulations. An example of the GDTMaternityProtectionDeliveryTypeCode 35800NV is:

<MaternityProtectionDeliveryTypeCode>1</MaternityProtectionDeliveryTypeCode>

The structure of the GDT MatemityProtectionDeliveryTypeCode 35800NV isdepicted in FIG. 358NV. For the GDT MatemityProtectionDeliveryTypeCode35800NV, the Object Class is Maternity Protection 35801NV, the Propertyis Delivery Type 35803NV, the Representation/Association is Code35804NV, the Type is CCT 35805NV, the Type Name is Code 35806NV, and theLength is from one to two 35807NV. The remark 35809NV shows that the GDTMatemityProtectionDeliveryTypeCode 35800NV may be restricted.

For the ListID 35810NV, the Category is Attribute (A) 35811NV, theObject Class is CodeList 35812NV, the Property is Identification35813NV, the Representation/Association is Identifier 35814NV, the Typeis XSD 35815NV, the Type Name is Token 35816NV, and the Cardinality iszero or one 35818NV.

For the ListAgencyID 35820NV, the Category is Attribute (A) 35821NV, theObject Class is CodeListAgency 35822NV, the Property is Identification35823NV, the Representation/Association is Identifier 35824NV, the Typeis XSD 35825NV, the Type Name is Token 35826NV, and the Cardinality iszero or one 35828NV.

For the ListVersionID 35830NV, the Category is Attribute (A) 35831NV,the Object Class is CodeList 35832NV, the Property is Version 35833NV,the Representation/Association is Identifier 35834NV, the Type is XSD35835NV, the Type Name is Token 35836NV, and the Cardinality is zero orone 35838NV.

For the ListAgency-SchemeID 35840NV, the Category is Attribute (A)35841NV, the Object Class is CodeListAgency 35842NV, the Property isScheme 35843NV, the Representation/Association is Identifier 35844NV,the Type is XSD 35845NV, the Type Name is Token 35846NV, and theCardinality is zero or one 35848NV.

For the ListAgency-SchemeAgencyID 35850NV, the Category is Attribute (A)35851NV, the Object Class is CodeListAgency 35852NV, the Property isSchemeAgency 35853NV, the Representation/Association is Identifier35854NV, the Type is XSD 35855NV, the Type Name is Token 35856NV, andthe Cardinality is zero or one 35858NV.

Several fixed, country-specific code lists, which are different atruntime, are assigned to the GDT MatemityProtectionDeliveryTypeCode35800NV. The GDT MatemityProtectionDeliveryTypeCode 35800NV can be used,for example, in the calculation of the Maternity Protection periodaccording to various delivery types. The Maternity Protection period canbe calculated differently (as provided by the national law) for thevarious delivery types.

The GDT MaternityProtectionDeliveryTypeCode 35800NV for ‘DE’ (Germany):listID=“10090”, listAgencyID=“310”. The data type GDTMaternityProtectionDeliveryTypeCode 35800NV may use the following codes:1 (i.e., the normal delivery of a child (It should not be premature orStill birth)), and 2 (i.e., the premature birth (The premature stillbirth will be considered as still birth not a premature), and 3 (i.e.,the still birth (child is born dead).

(wwwwwwwwwwwwwwwwwwwwwwww) PartyIdentifierCategoryCode

A GDT PartyIdentifierCategoryCode 35800NW is a code of a category for anidentifier of a party. An example of the GDT PartyIdentifierCategoryCode35800NW is:

<PartyIdentifierCategoryCode>11</PartyIdentifierCategoryCode>

The structure of the GDT PartyldentifierCategoryCode 35800NW is depictedin FIG. 358NW. For the GDT PartyldentifierCategoryCode 35800NW, theCategory is Party 35801NW, the Object Class is Identifier 35801NW, theProperty is Category 35803NW, the Representation/Association is Code35804NW, the Type is CCT 35805NW, the Type Name is Code 35806NW, and theLength is from one to six 35807NW. The remark 35809NW shows that the GDTPartyldentifierCategoryCode 35800NW may be restricted.

For the ListID 35810NW, the Category is Attribute (A) 35811NW, theObject Class is CodeList 35812NW, the Property is Identification35813NW, the Representation/Association is Identifier 35814NW, the Typeis XSD 35815NW, the Type Name is Token 35816NW, and the Cardinality iszero or one 35818NW.

For the ListAgencyID 35820NW, the Category is Attribute (A) 35821NW, theObject Class is CodeListAgency 35822NW, the Property is Identification35823NW, the Representation/Association is Identifier 35824NW, the Typeis XSD 35825NW, the Type Name is Token 35826NW, and the Cardinality iszero or one 35828NW.

For the ListVersionID 35830NW, the Category is Attribute (A) 35831NW,the Object Class is CodeList 35832NW, the Property is Version 35833NW,the Representation/Association is Identifier 35834NW, the Type is XSD35835NW, the Type Name is Token 35836NW, and the Cardinality is zero orone 35838NW.

For the ListAgency-SchemeID 35840NW, the Category is Attribute (A)35841NW, the Object Class is CodeListAgency 35842NW, the Property isScheme 35843NW, the Representation/Association is Identifier 35844NW,the Type is XSD 35845NW, the Type Name is Token 35846NW, and theCardinality is zero or one 35848NW.

For the ListAgency-SchemeAgencyID 35850NW, the Category is Attribute (A)35851NW, the Object Class is CodeListAgency 35852NW, the Property isSchemeAgency 35853NW, the Representation/Association is Identifier35854NW, the Type is XSD 35855NW, the Type Name is Token 35856NW, andthe Cardinality is zero or one 35858NW.

An extendable code list may be assigned to the GDTPartyIdentifierCategoryCode 35800NW. The customers amy only extend thiscode list. In its unchanged state, the code list has the followingattributes: listID=“10283”, listAgencyID=“310”, listVersionID=[Versionof the relevant code list]. If a customer makes changes to the codelist, the values assigned to the attributes change as follows:listAgencyID—ID of the customer, listVersionID—Assigned and managed bythe customer, listAgencySchemeID—ID of the scheme,listAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID.

One or more PartyldentifierTypes can be assigned to aPartyldentifierCategory. However, only one PartyIdentifierCategory canbe assigned to a PartyldentifierType. The GDTPartyIdentifierCategoryCode can be used to determine with which categoryof identification papers a person can identify him- or herself. Examplesof the possible semantics of the codes are: Officialdocument—Identification using official documents (such as passport,diplomatic passport or identity card), Photoidentification—Identification using a photo ID. The following dictionaryobjects are assigned to this GDT insystems: Data element:BU_ID_CATEGORY, and Domain: BU_ID_CATEGORY.

The data type GDT PartyldentifierCategoryCode 35800NW may use thefollowing codes: BUP001 (i.e., identification using Dun & Bradstreetnumber), BUP002 (i.e., identification using commercial register number),BUP003 (i.e., identification using register of associations number),BUP004 (i.e., identification using public register of cooperativesnumber), BUP005 (i.e., identification using a Global Location Number(GLN)), BUP006 (i.e., identification using a Standard Carrier AlphaCode), FS000 (i.e., identification using an ID card), and FS0002 (i.e.,identification using a passport).

(xxxxxxxxxxxxxxxxxxxxxxxx) PartyldentifierTypeCode

A GDT PartyIdentifierTypeCode 35800NX is a code for a type of partyidentifier. An example of the GDT PartyIdentifierTypeCode 35800NX is:

<PartyIdentifierTypeCode>11</PartyIdentifierTypeCode>

The structure of the GDT PartyIdentifierTypeCode 35800NX is depicted inFIG. 358NX. For the GDT PartyIdentifierTypeCode 35800NX, the ObjectClass Qualifier is Party 35801NX, the Object Class is Identifier35802NX, the Property is Type 35803NX, the Representation/Association isCode 35804NX, the Type is CCT 35805NX, the Type Name is Code 35806NX,and the Length is from one to six 35807NX. The remark 35809NX shows thatthe GDT PartyldentifierTypeCode 35800NX may be restricted.

For the ListAgencyID 35810NX, the Category is Attribute (A) 35811NX, theObject Class is CodeListAgency 35812NX, the Property is Identification35813NX, the Representation/Association is Identifier 35814NX, the Typeis XSD 35815NX, the Type Name is Token 35816NX, and the Cardinality iszero or one 35818NX.

For the ListVersionID 35820NX, the Category is Attribute (A) 35821NX,the Object Class is CodeList 35822NX, the Property is Version 35823NX,the Representation/Association is Identifier 35824NX, the Type is XSD35825NX, the Type Name is Token 35826NX, and the Cardinality is zero orone 35828NX.

For the ListAgency-SchemeID 35830NX, the Category is Attribute (A)35831NX, the Object Class is CodeListAgency 35832NX, the Property isScheme 35833NX, the Representation/Association is Identifier 35834NX,the Type is XSD 35835NX, the Type Name is Token 35836NX, and theCardinality is zero or one 35838NX.

For the ListAgency-SchemeAgencyID 35840NX, the Category is Attribute (A)35841NX, the Object Class is CodeListAgency 35842NX, the Property isSchemeAgency 35843NX, the Representation/Association is Identifier35844NX, the Type is XSD 35845NX, the Type Name is Token 35846NX, andthe Cardinality is zero or one 35848NX.

An extendable code list may be assigned to the GDTPartyldentifierTypeCode 35800NX. The customers may change this codelist. In its unchanged state, the code list has the followingattributes: listID=“10118”, listAgencyID=“310”, andlistVersionID=[Version of the relevant code list]. If acustomer makeschanges to the code list, the values assigned to the attributes changeas follows: listAgencyID—ID of the customer, listVersionID—Assigned andmanaged by the customer, listAgencySchemeID—ID of the scheme if thelistAgencyID, and listAgencySchemeAgencyID—ID of the organization thatmanages the scheme of the listAgencySchemeID.

If the instance value of the GDT PartyldentifierTypeCode 35800NXrepresents a standardized identification scheme (such as DUNS), theSchemeAttributes can be derived for an instance of the GDT PartyID. Oneor more PartyldentifierTypes can be assigned to aPartyIdentifierCategory. However, only one PartyIdentifierCategory canbe assigned to a PartyldentifierType.

The data type GDT PartyIdentifierCategoryCode 35800NW may use thefollowing codes: BUP001 (i.e., identification using Dun & Bradstreetnumber), BUP002 (i.e., identification using commercial register number),BUP003 (i.e., identification using register of associations number),BUP004 (i.e., identification using public register of cooperativesnumber), BUP005 (i.e., identification using a Global Location Number(GLN)), BUP006 (i.e., identification using a Standard Carrier AlphaCode), FS0001 (i.e., identification using an ID card), and FS0002 (i.e.,identification using a passport).

(yyyyyyyyyyyyyyyyyyyyyyyy) PartyRoleCategoryCode

A GDT PartyRoleCategoryCode 35800NY is a coded representation of aPartyRoleCategory. For example, a PartyRoleCategory is a grouping ofPartyRoles according to process-controlling critieria. A PartyRole withthe same name exists for each PartyRoleCategory. An example of the GDTPartyRoleCategoryCode 35800NY is:

<PartyRoleCategoryCode>12</PartyRoleCategoryCode>

The structure of the GDT PartyRoleCategoryCode 35800NY is depicted inFIG. 358NY. For the GDT PartyRoleCategoryCode 35800NY, the Object Classis Party 35804NY, the Property is Role Category 35806NY, theRepresentation/Association is Code 35808NY, the Type is CCT 35810NY, theType Name is Code 35812NY, and the Length is from two to three 35814NY.A fixed code list/standard code list may be assigned to thePartyRoleCode. The attributes are as follows: listID=“10014”, andlistAgencyID=“310”.

BusinessPartnerRoleCategoryCodes andOrganisationalCentreBusinessCharacterCodes are assigned to the GDTPartyRoleCategoryCode 35800NY. The party must have at least onecorresponding business partner role types and/orOrganisationCentreBusinessCharacter.

The data type GDT PartyRoleCategoryCode 35800NY may use the followingcodes: 1 (i.e., a BuyerParty is a party that buys goods or services), 2(i.e., a SellerParty is a party that sells goods or services), 3 (i.e.,a CreditorParty is a party that is authorized to require a service as aresult of an obligation), 4 (i.e., a DebitorParty is a party that isrequired to provide a service as a result of an obligation), 5 (i.e., aProductRecipientParty is a party to which goods are delivered or forwhom services are provided), 6 (i.e., a VendorParty is a party thatdelivers goods or provides services), 7 (i.e., a ManufacturerParty is aparty that manufactures goods), 8 (i.e., a PayerParty is a party thatpays for goods or services), 9 (i.e., a PayeeParty is a party thatreceives payment for goods or services provided), 10 (i.e., aBillToParty is a party to which the invoice for goods or services issent), 11 (i.e., a BillFromParty is a party that issues an invoice forgoods or services providedt), 12 (i.e., a CarrierParty is a party thatprovides the transport goods), 13 (i.e., a RequestorParty is a partythat requests the procurement of goods or services), 14 (i.e., aPortalProviderParty is a party that runs a portal that brings businesspartners together for a business transaction), 15 (i.e., aCatalogueProviderParty is a party that compiles a catalog), 16 (i.e., aBidderParty is a party that bids for goods or services), 17 (i.e., anOwnerParty is a party that owns tangible or intangible goods), 18 (i.e.,a TaxPayerParty is a party that is subject to taxation), 19 (i.e., aTaxOperatorParty is a party that takes care of tax issues for aTaxPayerParty), 20 (i.e., a ContractReleaseAuthorisedParty is a partthat is authorized to release goods or services from a contract.), 21(i.e., a BorrowerParty is a party that takes out a loan), 22 (i.e., aLenderParty is a party that grants a loan), 23 (i.e., a BrokerParty is aparty that is a facilitator in a business transaction), 24 (i.e., aBailsmanParty is a party that provides a debt guarantee for a loan), 25(i.e., a CopyMessageToParty is a party that receives a copy of amessage), 26 (i.e., a BlindCopyMessageToParty is a party that receives acopy of a message, without other recipients being informed of this), 27(i.e., a QualityInspectionProcessorParty is a party that carries out aquality check), 28 (i.e., a ServiceSupportTeamParty is a party that isresponsible for the processing of service requests and customercomplaints as well as the planning and preparation of service orders),29 (i.e., a SalesPartnerParty is a party that initiates and implementsbusiness transactions for another company), 30 (i.e., a CompetitorPartyis a party that is a competitor in terms of business), and 31 (i.e., aProspectParty is a party that has a business interest or that issuspected of having a business interest).

(zzzzzzzzzzzzzzzzzzzzzzzz) PartyRoleCode

A GDT PartyRoleCode 35800NZ is a coded representation of a PartyRole.For example, a PartyRole specifies which rights and obligations theParty has regarding the business objectGlobal Data Types—Definitionenand corresponding processes. A PartyRole is assigned to exactly onePartyRoleCategory and refines its semantics. An example of the GDTPartyRoleCode 35800NZ is:

<PartyRoleCode>14</PartyRoleCode>

The structure of the GDT PartyRoleCode 35800NZ is depicted in FIG.358NZ. For the GDT PartyRoleCode 35800NZ, the Object Class is Party35804NZ, the Property is Role 35806NZ, the Representation/Association isCode 35808NZ, the Type is CCT 35810NZ, the Type Name is Code 35812NZ,and the Length is from one to ten 35814NZ.

An extendable code list is assigned to the GDT PartyRoleCode 35800NZ.The customers may change this code list. In its unchanged state, thecode list has the following attributes: listID=“10034”,listAgencyID=“310”, and listVersionID=[Version of the relevant codelist]. If a customer makes changes to the code list, the values assignedto the attributes change as follows: listAgencyID—ID of the customer,listVersionID—Assigned and managed by the customer,listAgencySchemeID—ID of the scheme, and listAgencySchemeAgencyID—ID ofthe organization that manages the scheme of the listAgencySchemeID.

Use is primarily the differentiation of a PartyRoleCategory in variousprocesses. For example, the PartyRole “ServiceRecipient” can be used forthe PartyRoleCategory “ProductRecipient” in a service process, and“GoodsRecipient” in a sales process.

The data type GDT PartyRoleCode 35800NZ may use the following codes: 1(i.e., a BuyerParty is a party that buys goods or services), 2 (i.e., aSellerParty is a party that sells goods or services), 3 (i.e., aCreditorParty is a party that is authorized to require a service as aresult of an obligation), 4 (i.e., a DebitorParty is a party that isrequired to provide a service as a result of an obligation), 5 (i.e., aProductRecipientParty is a party to which goods are delivered or forwhom services are provided), 6 (i.e., a VendorParty is a party thatdelivers goods or provides services), 7 (i.e., a ManufacturerParty is aparty that manufactures goods), 8 (i.e., a PayerParty is a party thatpays for goods or services), 9 (i.e., a PayeeParty is a party thatreceives payment for goods or services provided), 10 (i.e., aBillToParty is a party to which the invoice for goods or services issent), 11 (i.e., a BillFromParty is a party that issues an invoice forgoods or services providedt), 12 (i.e., a CarrierParty is a party thatprovides the transport goods), 13 (i.e., a RequestorParty is a partythat requests the procurement of goods or services), 14 (i.e., aPortalProviderParty is a party that runs a portal that brings businesspartners together for a business transaction), 15 (i.e., aCatalogueProviderParty is a party that compiles a catalog), 16 (i.e., aBidderParty is a party that bids for goods or services), 17 (i.e., anOwnerParty is a party that owns tangible or intangible goods), 18 (i.e.,a TaxPayerParty is a party that is subject to taxation), 19 (i.e., aTaxOperatorParty is a party that takes care of tax issues for aTaxPayerParty), 20 (i.e., a ContractReleaseAuthorisedParty is a partthat is authorized to release goods or services from a contract.), 21(i.e., a BorrowerParty is a party that takes out a loan), 22 (i.e., aLenderParty is a party that grants a loan), 23 (i.e., a BrokerParty is aparty that is a facilitator in a business transaction), 24 (i.e., aBailsmanParty is a party that provides a debt guarantee for a loan), 25(i.e., a CopyMessageToParty is a party that receives a copy of amessage), 26 (i.e., a BlindCopyMessageToParty is a party that receives acopy of a message, without other recipients being informed of this), 27(i.e., a QualitylnspectionProcessorParty is a party that carries out aquality check), 28 (i.e., a ServiceSupportTeamParty is a party that isresponsible for the processing of service requests and customercomplaints as well as the planning and preparation of service orders),29 (i.e., a SalesPartnerParty is a party that initiates and implementsbusiness transactions for another company), 30 (i.e., a CompetitorPartyis a party that is a competitor in terms of business), and 31 (i.e., aProspectParty is a party that has a business interest or that issuspected of having a business interest).

(aaaaaaaaaaaaaaaaaaaaaaaaa) PersonnelEventTypeCode

A GDT PersonnelEventTypeCode 35800OA is a coded representation of thetype of a personnel event. For example, a personnel event is an event inan employee's professional or private life that needs to be documentedfor the company. The PersonnelEventType is the classification ofpersonnel events according to the type of change to the workrelationship, the work agreement, or the employee-related data. Anexample of the GDT PersonnelEventTypeCode 35800OA is:  <PersonnelEventTypeCode listAgencyID=‘310’ listVersionID =‘1.0’>1</PersonnelEventTypeCode>

The structure of the GDT PersonnelEventTypeCode 35800OA is depicted inFIG. 358OA. For the GDT PersonnelEventTypeCode 35800OA, the Object Classis Personnel Administration 35801OA, the Representation/Association isCode 35804OA, the Type is CCT 35805OA, the Type Name is Code 35806OA,and the Length is from one to four 35807OA. The remark 35809OA showsthat the GDT PersonnelEventTypeCode 35800OA may be restricted.

For the ListAgencyID 35810OA, the Category is Attribute (A) 35811OA, theObject Class is CodeListAgency 35812OA, the Property is Identification35813OA, the Representation/Association is Identifier 35814OA, the Typeis XSD 35815OA, the Type Name is Token 35816OA, and the Cardinality iszero or one 35818OA.

For the ListVersionID 35820OA, the Category is Attribute (A) 35821OA,the Object Class is CodeList 35822OA, the Property is Version 35823OA,the Representation/Association is Identifier 35824OA, the Type is XSD35825OA, the Type Name is Token 35826OA, and the Cardinality is zero orone 35828OA.

For the ListAgency-SchemeID 35830OA, the Category is Attribute (A)35831OA, the Object Class is CodeListAgency 35832OA, the Property isScheme 35833OA, the Representation/Association is Identifier 35834OA,the Type is XSD 35835OA, the Type Name is Token 35846OA, and theCardinality is zero or one 35838OA.

For the ListAgency-SchemeAgencyID 35840OA, the Category is Attribute (A)35841OA, the Object Class is CodeListAgency 35842OA, the Property isSchemeAgency 35843OA, the Representation/Association is Identifier35844OA, the Type is XSD 35845OA, the Type Name is Token 35846OA, andthe Cardinality is zero or one 35848OA.

Several country-specific code lists that are different at runtime areassigned to the GDT PersonnelEventTypeCode 35800OA. The customers maychange these code lists. If a customer makes changes to the code lists,the values of the attributes are changed as follows: listAgencyID—ID ofthe customer, listVersionID—Assigned and managed by the customer,listAgencySchemeID—ID of the scheme, and listAgencySchemeAgencyID—ID ofthe organizationthat manages the scheme of the listAgencySchemeID.

The data type GDT PersonnelEventTypeCode 35800OA may use the followingcodes: 1 (i.e., hiring of an employee), 2 (i.e., transfer of anemployee), 3 (i.e., dismissal by employer), 4 (i.e., resignation byemployee), 5 (i.e., long-term leave), 6 (i.e., military service), 7(i.e., employee's maternity protection), and 8 (i.e., employee'sparental leave).

(bbbbbbbbbbbbbbbbbbbbbbbbb) QualityManagementSystemStandardCode

A GDT QualityManagementSystemStandardCode 35800OB is a codedrepresentation of a standard for the quality management system. Forexample, a quality management system is the summary of the technical andorganizational means needed for the implementation of the qualitymanagement. Different standards exist for the quality management system.An example of the GDT QualityManagementSystemStandardCode 35800OB is:  <QualityManagementSystemStandardCode>1</QualityManagementSystemStandardCode>

The structure of the GDT QualityManagementSystemStandardCode 35800OB isdepicted in FIG. 358OB. For the GDT QualityManagementSystemStandardCode35800OB, the Property Qualifier is Quality Management System 35802OB,the Property is Standard 35803OB, the Representation/Association is Code35804OB, the Type is CCT 35805OB, the Type Name is Code 35806OB, and theLength is from one to four 35807OB. The remark 35809OB shows that theGDT QualityManagementSystemStandardCode 35800OB may be restricted.

For the ListID 35810OB, the Category is Attribute (A) 35811OB, theObject Class is CodeList 35812OB, the Property is Identification35813OB, the Representation/Association is Identifier 35814OB, the Typeis XSD 35815OB, the Type Name is Token 35816OB, and the Cardinality iszero or one 35818OB.

For the ListAgencyID 35820OB, the Category is Attribute (A) 35821OB, theObject Class is CodeListAgency 35822OB, the Property is Identification35823OB, the Representation/Association is Identifier 35824OB, the Typeis XSD 35825OB, the Type Name is Token 35826OB, and the Cardinality iszero or one 35828OB.

For the ListVersionID 35830OB, the Category is Attribute (A) 35831OB,the Object Class is CodeList 35832OB, the Property is Version 35833OB,the Representation/Association is Identifier 35834OB, the Type is XSD35835OB, the Type Name is Token 35836OB, and the Cardinality is zero orone 35838OB.

For the ListAgency-SchemeID 35840OB, the Category is Attribute (A)35841OB, the Object Class is CodeListAgency 35842OB, the Property isScheme 35843OB, the Representation/Association is Identifier 35844OB,the Type is XSD 35845OB, the Type Name is Token 35846OB, and theCardinality is zero or one 35848OB.

For the ListAgency-SchemeAgencyID 35850OB, the Category is Attribute (A)35851OB, the Object Class is CodeListAgency 35852OB, the Property isSchemeAgency 35853OB, the Representation/Association is Identifier35854OB, the Type is XSD 35855OB, the Type Name is Token 35856OB, andthe Cardinality is zero or one 35858OB.

A customer-specific code list is assigned to the GDTQualityManagementSystemStandardCode 35800OB. A customer defines thecodes in the code list. The attributes of the GDTQualityManagementSystemStandardCode 35800OB are assigned values asfollows: listID=“10157”, listAgencyID—ID of the customer,listVersionID—Assigned and managed by the customer,listAgencySchemeID—ID of the scheme, and listAgencySchemeAgencyID—ID ofthe organization that manages the scheme of the listAgencySchemeID

Some companies, especially public authorities and large-scale companiesmay require verification from the vendor that there is an appropriatequality management system described, implemented and operative. Manycompanied have earned relevant certificates from accredited Institutes.Type and area of the required display of quality management systems varydepending on each company. Examples of customer-specific code semantics:ISO certification: Certificate in accordance with IS09001:2000, andTechnical Inspection Authority: Certificate ‘Tested Data Integrity’. Insome instances within the RFQ process certain goods are only acceptedfrom specific vendors, who are assigned to the specific GDTQualityManagementSystemStandardCode 35800OB, this means that the vendoris certified for this standard, or manufacture in accordance with thisstandard.

(ccccccccccccccccccccccccc) ResponsibilityTypeCode

A GDT ResponsibilityTypeCode 35800OC is a coded representation of aResponsibility type. For example, a responsibility type defines thecharacteristic features of a particular responsibility, e.g. surnames ofemployees, product categories, organizational centres etc. Aresponsibility describes specific rights and duties of an acting agentresponsible such as a person or an organizational centre etc. An exampleof the GDT ResponsibilityTypeCode 35800OC is:

<ResponsibilityTypeCode>ActingRLUForPayment</ResponsibilityTypeCode>

The structure of the GDT ResponsibilityTypeCode 35800OC is depicted inFIG. 358OC. For the GDT ResponsibilityTypeCode 35800OC, the Object Classis Responsibility 35801OC, the Property is Type 35803OC, theRepresentation/Association is Code 35804OC, the Type is CCT 35805OC, theType Name is Code 35806OC, and the Length is from one to five 35807OC.The remark 35809OC shows that the GDT ResponsibilityTypeCode 35800OC maybe restricted.

For the ListAgencyID 35810OC, the Category is Attribute (A) 35811OC, theObject Class is CodeListAgency 35812OC, the Property is Identification35813OC, the Representation/Association is Identifier 35814OC, the Typeis XSD 35815OC, the Type Name is Token 35816OC, and the Cardinality iszero or one 35818OC.

For the ListVersionID 35820OC, the Category is Attribute (A) 35821OC,the Object Class is CodeList 35822OC, the Property is Version 35823OC,the Representation/Association is Identifier 35824OC, the Type is XSD35825OC, the Type Name is Token 35826OC, and the Cardinality is zero orone 35828OC.

For the ListAgency-SchemeID 35830OC, the Category is Attribute (A)35831OC, the Object Class is CodeListAgency 35832OC, the Property isScheme 35833OC, the Representation/Association is Identifier 35834OC,the Type is XSD 35835OC, the Type Name is Token 35836OC, and theCardinality is zero or one 35838OC.

For the ListAgency-SchemeAgencyID 35840OC, the Category is Attribute (A)35841OC, the Object Class is CodeListAgency 35842OC, the Property isSchemeAgency 35843OC, the Representation/Association is Identifier35844OC, the Type is XSD 35845OC, the Type Name is Token 35846OC, andthe Cardinality is zero or one 35848OC.

An extendible code list may be assigned to the code. A customer canreplace the list by his/her own list. An unchanged Code list has thefollowing attributes: listID=“10244”, listAgencyID=“310”, andlistVersionID=[Version of the codes list in question.] If the customercreates his/her own code list, the attributes change as follows:listAgencyID—ID of the customer, listVersionID—Assigned and managed bythe customer, listAgencySchemeID—ID of the scheme, andlistAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID.

The GDT ResponsibilityTypeCode 35800OC may be used to determine actingagents responsible (in responsibility queries) in order to narrow downthe responsibility that is to be found. For example, the agentresponsible for the responsilbility type “authorization of leaverequest” needs to be determined.

The data type GDT ResponsibilityTypeCode 35800OC may use the followingcodes: 1 (i.e., responsibility type for authorizing leave requests), 2(i.e., responsibility type for authorizing purchase orders), and 3(i.e., responsilbility type for unit of payment in Due Payment).

(ddddddddddddddddddddddddd) ResponsibleAgent

A GDT ResponsibleAgent 35800OD is an acting agent with specific rightsand duties. For example, a ResponsibleAgent can be e.g. an employee oran Organisational Centre. An example of the GDT ResponsibleAgent 35800ODis: <ResponsibleAgent>  <UUID>f81d4fae-7dec-1d0-a765-00a0c91e6bf6</UUID>  <BusinessObjectTypeCode>1001</BusinessObjectTypeCode></ResponsibleAgent>

The structure of the GDT ResponsibleAgent 35800OD is depicted in FIG.358OD. For the GDT ResponsibleAgent 35800OD, the Object Class isResponsible Agent 35801OD, the Representation/Association is Details35804OD, For the UUID 35810OD, the Category is Element (E) 35811OD, theObject Class is Responsible Agent 35812OD, the Property is UniveralUnique_Identification 35813OD, the Representation/Association isIdentifier 35814OD, the Type is GDT 35815OD, the Type Name is UUID35816OD, and the Cardinality is one 35818OD.

For the BusinessObjectTypeCode 35820OD, the Category is Element (E)35821OD, the Object Class is Responsible Agent 35822OD, the Property isBusiness Object Type 35823OD, the Representation/Association is Code35824OD, the Type is GDT 35825OD, the Type Name isBusinessObjectTypeCode 35826OD, and the Cardinality is one 35828OD.

The data type GDT ResponsibleAgent 35800OD may use the following codes:1001 (i.e., master data object BusinessPartner), 1002 (i.e., master dataobject Customer), 1003 (i.e., master data object Supplier), 1004 (i.e.,master data object Employee), 1005 (i.e., master data object Company),1006 (i.e., master data object CostCentre), 1007 (i.e., master dataobject SalesUnit), 1008 (i.e., master data object ServiceUnit), 1009(i.e., master data object PurchasingUnit), 1010 (i.e., master dataobject ReportingLineUnit), 1011 (i.e., master data object Location), and1012 (i.e., master data object DistributionCentre).

One or more ResponsibleAgents are always the result of responsibilityquery. The GDT ResponsibleAgent 35800OD is also used when maintainingresponsibilities for e.g. a position, in order to show that theresponsibilities being maintained currently refer to one person, but maybe transferred to a different person, if in future the position isfilled by someone else.

(eeeeeeeeeeeeeeeeeeeeeeeee) ServicelssueCategoryCatalogueID

A GDT ServicelssueCategoryCatalogueID 35800OE is an identifier for acatalog of issue categories in customer service. For example, a catalogof issue categories is a structured directory of categories thatdescribe an issue in a business process in customer service. Thehierarchical struc-ture is used to depict dependencies between thecategories. Depending on how detailed the description of the issues mustbe, additional, more specific categories are defined underneath the maincategories. The number of hierarchy levels in the structure isunlimited. An example of the GDT ServicelssueCategoryCatalogueID 35800OEis:   <ServiceIssueCategoryCatalogueID> SOFTWARE_COMPONENTS/ServiceIssueCategoryCatalogueID>

The structure of the GDT ServicelssueCategoryCatalogueID 35800OE isdepicted in FIG. 358OE. For the GDT ServicelssueCategoryCatalogueID35800OE, the Object Class is Service Issue Category Catalogue 35804OE,the Property is Identification 35806OE, the Representation/Associationis Identifier 35808OE, the Type is GDT 35810OE, the Type Name isIdentifier 35812OE, and the Length is from one to twenty five 35814OE.The remark 35818OE shows that the GDT ServicelssueCategoryCatalogueID35800OE may be restricted.

The ServicelssueCategoryCatalogueID does not have any identifyingattributes, since (multiple) identification schemes are not supported. Acatalogue of issue categories is used in customer service in order toprovide a predefined collection of categories for controlling businessprocesses and for classifying relevant business documents. Thesebusiness documents are usually service transactions (service requests,service orders, service confirmations).

(ffffffffffffffffffffffff) ServiceIssueCategoryID

A GDT ServicelssueCategoryID 35800OF is an identifier for an issuecategory in customer service. For example, an issue category is aclassification of issues in a business process in customer service,according to objective or subjective criteria. See alsoServicelssueCategoryHierarchyID. An example of the GDTServicelssueCategoryID 35800OF is:

<ServiceIssueCategoryID>CRM-CIC </ServiceIssueCategoryID>

The structure of the GDT ServicelssueCategoryID 35800OF is depicted inFIG. 358OF. For the GDT ServicelssueCategoryID 35800OF, the Object Classis Service Issue Category 35804OF, the Rep./Ass. Qual. is Identifiction35806OF, the Representation/Association is Identifier 35808OF, the Typeis GDT 35810OF, the Type Name is Identifier 35812OF, and the Length isfrom one to twenty five 35814OF. The remark 35818OF shows that the GDTServicelssueCategoryID 35800OF may be restricted.

The GDT ServicelssueCategoryID 35008OF does not have any identifyingattributes, since (multiple) identification schemes are not supported.The GDT ServicelssueCategoryID 35008OF can currently not be used in A2A-or B2B Messages. Issue categories can be used, for example, forprocessing service requests, in order to allocate the type of request,problem, or cause. Depending on the individual categorization of theservice request, solutions that are linked to the category can beproposed automatically. In addition, once again depending on thecategorization, follow-up actions can be automated, for example: forwarda service request to a single expert or a group of experts, check theentitlements of a customer (for example the existence of a validwarranty), and propose a special e-mail template to answer the customerinquiry.

A ProcessServiceCategoryID is an identifier for a category in customerservice that is used to characterize and control a business process. AnIncidentServiceCategoryID is an identifier for a category in customerservice that is used to descibe an individual issue and to contributetowards its resolution. An issue is typically a problem and its cause orcauses.

(ggggggggggggggggggggggggg) ServiceIssueCategoryTypeCode

A GDT ServiceIssueCategoryTypeCode 35800OG is a coded representation ofthe type of an issue category in customer service. For example, an issuecategory in customer service is a characteristic of a specific issuethat categorizes a business transaction document according to anobjective or a subjective point of view. An example of the GDTServicelssueCategoryTypeCode 35800OG is:

<ServiceIssueCategoryTypeCode>1</ServiceIssueCategoryTypeCode>

The structure of the GDT ServiceIssueCategoryTypeCode 35800OG isdepicted in FIG. 358OG. For the GDT ServiceIssueCategoryTypeCode35800OG, the Object Class is Service Issue Category 35801OG, theProperty is Type 35803OG, the Representation/Association is Code35804OG, the Type is CCT 35805OG, the Type Name is Code 35806OG, and theLength is from one to two 35807OG. The remark 35809OG shows that the GDTServiceIssueCategoryTypeCode 35800OG may be restricted.

For the ListAgencyID 35810OG, the Category is Attribute (A) 35811OG, theObject Class is CodeListAgency 35812OG, the Property is Identification35813OG, the Representation/Association is Identifier 35814OG, the Typeis XSD 35815OG, the Type Name is Token 35816OG, and the Cardinality iszero or one 35818OG.

For the ListVersionID 35820OG, the Category is Attribute (A) 35821OG,the Object Class is CodeList 35822OG, the Property is Version 35823OG,the Representation/Association is Identifier 35824OG, the Type is XSD35825OG, the Type Name is Token 35826OG, and the Cardinality is zero orone 35828OG.

For the ListAgency-SchemeID 35830OG, the Category is Attribute (A)35831OG, the Object Class is CodeListAgency 35832OG, the Property isScheme 35833OG, the Representation/Association is Identifier 35834OG,the Type is XSD 35835OG, the Type Name is Token 35836OG, and theCardinality is zero or one 35838OG.

For the ListAgency-SchemeAgencyID 35840OG, the Category is Attribute (A)35841OG, the Object Class is CodeListAgency 35842OG, the Property isSchemeAgency 35843OG, the Representation/Association is Identifier35844OG, the Type is XSD 35845OG, the Type Name is Token 35846OG, andthe Cardinality is zero or one 35848OG.

An extendable code list is assigned to the GDTServicelssueCategoryTypeCode 35800OF. The customers can change this codelist. In its unchanged state, the code list has the followingattributes: listID=“10226”, listAgencyID=“310”, listVersionID=[Versionof the relevant code list]. If a customer makes changes to the codelist, the values assigned to the attributes change as follows:listAgencyID—ID of the customer, listVersionID—Assigned and managed bythe customer, listAgencySchemeID—ID of the scheme, andlistAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID.

(hhhhhhhhhhhhhhhhhhhhhhhhh) ServiceValuationCode

A GDT ServiceValuationCode 35800OH is a coded representation of aservice valuation. For example, a service can be evaluated in differentways, for example, as follows: according to qualifications (for example,master craftsman, specialist, apprentice, etc.), or according tovaluation records (for example, billing records for consultants: L1-L6).An example of the GDT ServiceValuationCode 35800OH is:

<ServiceValuationCode>1</ServiceValuationCode>

The structure of the GDT ServiceValuationCode 35800OH is depicted inFIG. 358OH. For the GDT ServiceValuationCode 35800OH, the Object Classis Service 35801OH, the Property is Valuation 35803OH, theRepresentation/Association is Code 35804OH, the Type is CCT 35805OH, theType Name is Code 35806OH, and the Length is from one to six 35807OH.The remark 35809OH shows that the GDT ServiceValuationCode 35800OH maybe restricted.

For the ListID 35810OH, the Category is Attribute (A) 358110OH, theObject Class is CodeList 35812OH, the Property is Identification35813OH, the Representation/Association is Identifier 35814OH, the Typeis XSD 35815OH, the Type Name is Token 35816OH, and the Cardinality iszero or one 35818OH.

For the ListAgencyID 35820OH, the Category is Attribute (A) 35821OH, theObject Class is CodeListAgency 35822OH, the Property is Identification35823OH, the Representation/Association is Identifier 35824OH, the Typeis XSD 35825OH, the Type Name is Token 35826OH, and the Cardinality iszero or one 35828OH.

For the ListVersionID 35830OH, the Category is Attribute (A) 35831OH,the Object Class is CodeList 35832OH, the Property is Version 35833OH,the Representation/Association is Identifier 35834OH, the Type is XSD35835OH, the Type Name is Token 35836OH, and the Cardinality is zero orone 35838OH.

For the ListAgency-SchemeID 35840OH, the Category is Attribute (A)358410OH, the Object Class is CodeListAgency 35842OH, the Property isScheme 35843OH, the Representation/Association is Identifier 35844OH,the Type is XSD 35845OH, the Type Name is Token 35846OH, and theCardinality is zero or one 35848OH.

For the ListAgency-SchemeAgencyID 35850OH, the Category is Attribute (A)35851OH, the Object Class is CodeListAgency 35852OH, the Property isSchemeAgency 35853OH, the Representation/Association is Identifier35854OH, the Type is XSD 35855OH, the Type Name is Token 35856OH, andthe Cardinality is zero or one 35858OH.

There are only alternative code lists that differ at configurationand/or runtime. The ServiceValuationCode is a customer-specific codelist. Examples of the possible semantics of the codes can be found underthe heading “Use”. The attributes are used as follows: listID—ID of therelevant code list. It is assigned and administered by a customer wherethe customer is responsible for the values of the ID in question,listAgencyID—ID of the customer where an ID assigned by an organizationmay be used (such as the business IDs assigned by DUNS, EAN, and SWIFT),listVersionID—Version of the relevant code list that may be assigned andadministered by the customer listed in the listAgencyID,listAgencySchemeID—ID of the scheme by which the customer listed in thelistAgencyID is identified that may be a particular identificationscheme for partners, businesses, and members (such as DUNS+4), and soon, of an administering organization (such as EAN, DUNS, and SWIFT) thatis listed in the listAgencySchemeAgencyID, andlistAgencySchemeAgencyID—ID of the administering organization (such asDUNS, EAN, or SWIFT) that is responsible for identifying theorganization listed in the ListAgencyID.

The GDT ServiceValuatonCode 35800OH may be used for pricing, in order tocalculate surcharges or discounts for the customer. The surcharges anddiscounts can be an absolute or a percentage value. For example, if aservice with a base price of 100 Euro has to be carried out by aspecialist, a surcharge of 50% can be defined for this service. In thiscase, a total price of 150 Euro can be charged to the customer.

(iiiiiiiiiiiiiiiiiiiiiiiii)StatutoryMealsReimbursementExpenseReporterGroupCode

A GDT StatutoryMealsReimbursementExpenseReporterGroupCode 35800OI is acoded representation of a group of expense reporters to whom the samestatutory or contractual expense regulations apply regarding thereimbursement of meal expenses. An example of the GDTStatutoryMealsReimbursementExpenseReporterGroupCode 35800OI is:  <StatutoryMealsReimbursementExpenseReporterGroupCode>1</StatutoryMealsReimbursementExpenseReporterGroupCode >

The structure of the GDTStatutoryMealsReimbursementExpenseReporterGroupCode 35800OI is depictedin FIG. 358OI. For the GDTStatutoryMealsReimbursementExpenseReporterGroupCode 35800OI, the ObjectClass is Statutory_MealsReimbursement-ExpenseReporterGroup 35804OI, theRepresentation/Association is Code 35808OI, the Type is CCT 35810OI, theType Name is Code 35812OI, and the Length is from one to two 35814OI.The remark 35818OI shows that the GDTStatutoryMealsReimbursementExpenseReporterGroupCode 35800OI may berestricted.

The value range of the GDT

StatutoryMealsReimbursementExpenseReporterGroupCode 35800OI may consistof a customer-specific code list. The GDTStatutoryMealsReimbursementExpenseReporterGroupCode 35800OI maycurrently be used only in BOs. Examples of the GDTStatutoryMealsReimbursementExpenseReporterGroupCode 35800OI are the fouremployee groups of the Italian banking collective agreement with a perdiem that varies according to the employee hierarchy level: 1. areaprofessionale—Employee hierarchy level 1, 2. area professionals 1.e 2.livello retributivo—Employee hierarchy level 2, 3. area professionals e2. area professionale 3. livello retributive—Employee hierarchy level 3,and Quadri Direttivi 1.-4. livello—Employee hierarchy level 4.

For the GDT StatutoryMealsReimbursementExpenseReporterGroupCode 35800OIthere is the corresponding GDTEnterpriseMealsReimbursementExpenseReporterGroupCode as the codedrepresentation of a group of expense reporters to whom the samecompany-specific expense regulations apply regarding the reimbursementof meal expenses.

(jjjjjjjjjjjjjjjjjjjjjjjj)StatutoryMileageReimbursementExpenseReporterGroupCode

A GDT StatutoryMileageReimbursementExpenseReporterGroupCode 35800OJ is acoded representation of a group of expense reporters to whom the samestatutory or contractual expense regulations apply regarding thereimbursement of travel costs. An example of the GDTStatutoryMileageReimbursementExpenseReporterGroupCode 35800OJ is:  <StatutoryMileageReimbursementExpenseReporterGroupCode>1</StatutoryMileageReimbursementExpenseReporterGroupCode>

The structure of the GDTStatutoryMileageReimbursementExpenseReporterGroupCode 35800OJ isdepicted in FIG. 358OJ. For the GDTStatutoryMileageReimbursementExpenseReporterGroupCode 35800OJ, theObject Class is Statutory_MileageReimbursement-ExpenseReporterGroup35804OJ, the Representation/Association is Code 35808OJ, the Type is CCT35810OJ, the Type Name is Code 35812OJ, and the Length is from one totwo 35814OJ. The remark 35818OJ shows that the GDTStatutoryMileageReimbursementExpenseReporterGroupCode 35800OJ may berestricted.

The value range of the GDTStatutoryMileageReimbursementExpenseReporterGroupCode 35800OJ mayconsist of a customer-specific code list. The GDTStatutoryMileageReimbursementExpenseReporterGroupCode 35800OJ maycurrently be used only in BOs. Examples of the GDTStatutoryMileageReimbursementExpenseReporterGroupCode 35800OJ are thetwo employee groups of the Italian banking collective agreement: groupof employees who are allowed to use a private automobile, and group ofemployees who are not allowed to use a private automobile (noreimbursement of travel costs).

For the GDT StatutoryMileageReimbursementExpenseReporterGroupCode35800OJ there may be the corresponding GDTEnterpriseMileageReimbursementExpenseReporterGroupCode as the codedrepresentation of a group of expense reporters to whom the samecompany-specific expense regulations apply regarding the reimbursementof travel costs.

(kkkkkkkkkkkkkkkkkkkkkkkk) SubledgerAccountLineItemTypeCode

A GDT SubledgerAccountLineItemTypeCode 35800OK is a coded representationof the type of line item of a subledger account. For example, the lineitems of the subledger accounts are generated during the posting ofbusiness transactions. An example of the GDTSubledgerAccountLineItemTypeCode 35800OK is:

<SubledgerAccountLineItemTypeCode>1</SubledgerAccountLineItemTypeCode>

The structure of the GDT SubledgerAccountLineItemTypeCode 35800OK isdepicted in FIG. 358OK. For the GDT SubledgerAccountLineItemTypeCode35800OK, the Object Class is SubledgerAccountLineItem 35804OK, theProperty is TypeCode 35806OK, the Representation/Association is Code35808OK, the Type is CCT 35810OK, the Type Name is Code 35812OK, and theLength is from four to five 35814OK. The remark 35818OK shows that theGDT SubledgerAccountLineItemTypeCode 35800OK may be restricted.

The GDT SubledgerAccountLineItemTypeCode 35800OK is a fixed code list.The attributes of the CCT identifier have the following values:listID=“10069”, listAgencyID=“310”, and listVersionID—Version of therelevant code list.

The data type GDT SubledgerAccountLineItemTypeCode 35800OK may use thefollowing codes: 5001 (i.e., a customer line item is the representationof a change in value regarding a business partner who is in an accountsreceivable relationship to your company), and 5002 (i.e., a vendor lineitem is the representation of a change in value regarding a businesspartner who is in an accounts payable relationship to your company).

The semantics for grouping code list entries are not fixed. Applicationsmay not use the semantics in their program logic.SubledgerAccountLineItemTypeCode is used, for example, to categorize theline items in the business objectAccountsReceivablePayableSubledgerAccount. EachSubledgerAccountLineItemTypeCode is assigned to exactly oneSubledgerAccount.

(llllllllllllllllllllllll) SubledgerAccountTypeCode

A GDT SubledgerAccountTypeCode 35800OL is a coded representation of thetype of subledger. For example, a subledger is a disjoint subdivision ofFinancial Accounting. An example of the GDT SubledgerAccountTypeCode35800OL is:

<SubledgerAccountTypeCode>1</SubledgerAccountTypeCode>

The structure of the GDT SubledgerAccountTypeCode 35800OL is depicted inFIG. 358OL. For the GDT SubledgerAccountTypeCode 35800OL, the ObjectClass is Subledger Account 35804OL, the Property is Type 35806OL, theRepresentation/Association is Code 35808OL, the Type is CCT 35810OL, theType Name is Code 35812OL, and the Length is from one to two 35814OL.The remark 35818OL shows that the GDT SubledgerAccountTypeCode 35800OLmay be restricted.

The data type GDT SubledgerAccountTypeCode 35800OL may use the followingcodes: 1 (i.e., subledger account for tangible assets and intangibleassets), 2 (i.e., subledger account for materials), 3 (i.e., subledgeraccount for work in process), 4 (i.e., subledger account for purchaseorders), 5 (i.e., subledger account for customers and vendors), 6 (i.e.,subledger account for taxes), 7 (i.e., subledger account for liquidfunds), 8 (i.e., subledger account for sales processes), and 9 (i.e.,subledger account for overhead costs).

The attributes of the CCT code are filled implicitly with the followingvalues: listID=“10070”, listAgencyID=“310”, and listVersionID—Version ofthe relevant code list.

(mmmmmmmmmmmmmmmmmmmmmmmmm) TaxDeductibilityCode

A GDT TaxDeductibilityCode 35800OM is a coded representation of the taxdeductibility. For example, the deductibility specifies the portion ofVAT that can be deducted from purchases. An example of GDTTaxDeductibilityCode 35800OM is:

<TaxDeductibilityCode listID=21701listAgencyID=310>1</TaxDeductibilityCode>The structure of the GDTTaxDeductibilityCode 35800OM is depicted in FIG. 358OM. For the GDTTaxDeductibilityCode 35800OM, the Object Class is Tax Deductibility35801OM, the Representation/Association is Code 35804OM, the Type is CCT35805OM, the Type Name is Code 35806OM, and the Length is from one tofour 35807OM. The remark 35809OM shows that the GDT TaxDeductibilityCode35800OM may be restricted.

For the ListID 35810OM, the Category is Attribute (A) 35811OM, theObject Class is CodeList 35812OM, the Property is Identification35813OM, the Representation/Association is Identifier 35814OM, the Typeis XSD 35815OM, the Type Name is Token 35816OM, and the Cardinality iszero or one 35818OM.

For the ListAgencyID 35820OM, the Category is Attribute (A) 35821OM, theObject Class is CodeListAgency 35822OM, the Property is Identification35823OM, the Representation/Association is Identifier 35824OM, the Typeis XSD 35825OM, the Type Name is Token 35826OM, and the Cardinality iszero or one 35828OM.

For the ListVersionID 35830OM, the Category is Attribute (A) 35831OM,the Object Class is CodeList 35832OM, the Property is Version 35833OM,the Representation/Association is Identifier 35834OM, the Type is XSD35835OM, the Type Name is Token 35836OM, and the Cardinality is zero orone 35838OM.

For the ListAgency-SchemeID 35840OM, the Category is Attribute (A)35841OM, the Object Class is CodeListAgency 35842OM, the Property isScheme 35843OM, the Representation/Association is Identifier 35844OM,the Type is XSD 35845OM, the Type Name is Token 35846OM, and theCardinality is zero or one 35848OM.

For the ListAgency-SchemeAgencyID 35850OM, the Category is Attribute (A)35851OM, the Object Class is CodeListAgency 35852OM, the Property isSchemeAgency 35853OM, the Representation/Association is Identifier35854OM, the Type is XSD 35855OM, the Type Name is Token 35856OM, andthe Cardinality is zero or one 35858OM.

Several extensible, country-specific code lists, which may bedistinguished at runtime, are assigned to the code. The customers mayreplace lists with their own. If SAP customers create their own codelists in order to replace those from SAP, the allocation of attributeschanges as follows: listAgencyID—ID of the customer,listVersionID—Assigned and managed by the customer,listAgencySchemeID—ID of the scheme, and listAgencySchemeAgencyID—ID ofthe organization that manages the scheme of the listAgencySchemeID.Examples of customer-specific code semantics include input tax deductionaccording to individual agreement with tax authorities.

The classification of deductibility may permit the formulation of legaltexts, and tax assignments, regardless of actual current percentagerates that can be changed. In other words, if a percentage rate isincreased or decreased as of a specific date, the correspondingTaxDeductibilityCode does not change. If additional new percentage ratesare introduced for deductibility, these also lead to newTaxDeductibilityCodes. Non-deductibility is regulated individuallybetween company and tax authority.

TaxDeductibilityCode for EN (SAP code list): listID=“21701”,listAgencyID=“310”, and listVersionID=[Version of the relevant codelist].

The data type GDT TaxDeductibilityCode 35800OM may use the followingcodes: 1 (i.e., the sales tax on purchases is fully deductible), 2(i.e., the sales tax on purchases is not deductible), and 3 (i.e., VATon purchases is partly deductible (according to legal regulationsgoverning deductibility of tax for travel expenses).

(nnnnnnnnnnnnnnnnnnnnnnnnn) TransportationTerms

A GDT TransportationTerms 35800ON are a collection of the conditions andagreements that apply when transporting the ordered goods and providingthe necessary services and activities for this. An example of the GDTTransportationTerms 35800ON is:   <TransportationTerms>    <TransportServiceLevelCode listID=“DE 4219“ listVersionID=“D.02B“listAgencyID=“6“> 1 </TransportServiceLevelCode>     <TransportModeCodelistID=“DE 8067“ listVersionID=“D.02B“ listAgencyID=“6“> 1</TransportModeCode>     <TransportMeans>       <ID>HD AA-123</ID>      <MeansDescriptionCode listID=“DE 8179“ listVersionID=“D.02B“listAgencyID=“6“> 4 </MeansDescriptionCode>     </TransportMeans>    <Description langCode=“de”>       This is a German description text.    </Description>   <TransportationTerms>depicted in FIG. 358ON. For the GDT TransportationTerms 35800ON, theObject Class is TransportationTerms 35801ON, theRepresentation/Association is Details 35804ON, the For theTransportServiceLevel Code 35810ON, the Category is Element (E) 35811ON,the Object Class is TransportationTerms Transport 35812ON, the Propertyis ServiceLevel 35813ON, the Representation/Association is Code 35814ON,the Type is GDT 35815ON, the Type Name is TransportServiceLevelCode35816ON, and the Cardinality is zero or one 35818ON.

For the TransportModeCode 35820ON, the Category is Element (E) 35821ON,the Object Class is TransportationTerms_TransportMode 35822ON, theRepresentation/Association is Code 35824ON, the Type is GDT 35825ON, theType Name is TransportModeCode 35826ON, and the Cardinality is zero orone 35828ON.

For the TransportMeans 35830ON, the Category is Element (E) 35831ON, theObject Class is TransportationTerms_TransportMeans 35832ON, theRepresentation/Association is Details 35834ON, the Type is GDT 35835ON,the Type Name is TransportMeans 35836ON, and the Cardinality is zero orone 35838ON.

For the Description 35840ON, the Category is Element (E) 35841ON, theObject Class is TransportationTerms 35842ON, theRepresentation/Association is Text 35844ON, the Type is GDT 35845ON, theType Name is Long_Description 35846ON, and the Cardinality is zero orone 35848ON.

The GDT TransportationTerms 35800ON contain detailed specifications onthe agreed means of transportation (such as shipping/transport type andmeans of transport to be used). Moreover, additional information canalso be specified in the form of free text. The specification of eachstructural element is optional (the specification of an empty structureTransportaionTerms is not possible). The specifications forTransportModeCode and TransportMeansDescriptionCode may not contradicteach other (business integrity; for example, ModeCode=“MaritimeTransport” und MeansDescriptionCode=“Train with 20 or more wagons”).

With the information in the GDT TransportationTerms 35800ON, theinvolved business partners (purchaser and seller) agree on theconditions regarding the transportation of the ordered products/goods inthe form of orders or purchase orders. They determine and influence theflow of the subsequent logistical processes (for example, they influencethe selection of the transportation service providers and the conditionsto be negotiated with them, selection of a logistical organizationalunit for the delivery, and so on).

The data type GDT TransportationTerms 35800ON may use the followingcodes: 1 (i.e., something), 2 (i.e., something), 3 (i.e., something), 4(i.e., something), 5 (i.e., something).

(ooooooooooooooooooooooooo) ValueAdjustmentBusinessPartnerGroupCode

A GDT ValueAdjustmentBusinessPartnerGroupCode 35800OO is a codedrepresentation of a group of business partners for whom the same valueadjustment requirements apply. For example, a value adjustment isapplied in a balance sheet to receivables for which there is a definiteprobability that they will not be paid. The amount of the valueadjustment depends on the level of probability of non-payment and iscalculated using a set of rules elaborated for the business partnergroup. The actual probability is dictated by the business partner towhom the receivable is due. An example of the GDTValueAdjustmentBusinessPartnerGroupCode 35800OO is:

<ValueAdjustmentBusinessPartnerGroupCode>LOW/ValueAdjustmentBusinessPartnerGroupCode>

The structure of the GDT ValueAdjustmentBusinessPartnerGroupCode 35800OOis depicted in FIG. 358OO. For the GDTValueAdjustmentBusinessPartnerGroupCode 35800OO, the Object Class isValue Adjustment 35804OO, the Property is Business Partner Group35806OO, the Representation/Association is Code 35808OO, the Type is CCT35810OO, the Type Name is Code 35812OO, and the Length is from one tofive 35814OO. The remark 35818OO shows that the GDTValueAdjustmentBusinessPartnerGroupCode 35800OO may be restricted.

The GDT ValueAdjustmentBusinessPartnerGroupCode 35800OO is acustomer-specific code list. The attributes are used as follows:listID=“10380”, listAgencyID—ID of the administrative organization ofthe code list, listVersionID—Version of the relevant code list,listAgencySchemeID—The identification of the scheme once theorganization listed in the listAgencyID is identified, andlistAgencySchemeAgencyID—The ID of the managing organization (forexample, DUNS, EAN, SWIFT) that is responsible for identification of theorganization listed in the listAgencyID.

Examples of the possible semantics of the codes are: Domestic endcustomers, foreign end customers, and foreign business customers. Thepreceding examples assume that the general payment behavior differsbetween end customers and business customers as well as between domesticand foreign business partners.

(ppppppppppppppppppppppppp) WarrantyDependencyTypeCode

A GDT WarrantyDependencyTypeCode 35800OP is a coded representation ofthe type of warranty dependency. For example, the warranty dependencydefines which criterium specifies the validity of the warranty. Anexample of GDT WarrantyDependencyTypeCode 35800OP is:

<WarrantyDependencyTypeCode>1</WarrantyDependencyTypeCode>

The structure of GDT WarrantyDependencyTypeCode 35800OP is depicted inFIG. 358OP. For the GDT WarrantyDependencyTypeCode 35800OP, the ObjectClass is Warranty 35804OP, the Property is Dependency Type 35806OP, theRepresentation/Association is Code 35808OP, the Type is CCT 35810OP, theType Name is Code 35812OP, and the Length is from one 35814OP. Theremark 35818OP shows that the GDT WarrantyDependencyTypeCode 35800OP maybe restricted.

A fixed code list has been assigned to the GDTWarrantyDependencyTypeCode 35800OP. The attributes are as follows:listID=“10105”, listAgencyID=“310”, and listVersionID=Version of therelevant code list.

Examples for the use of the GDT WarrantyDependencyTypeCode 35800OP are:for a warranty with reference to time (i.e., 2 years' warranty frompurchase date), for a warranty with reference to counter (i.e., free ofcharge spare parts for the engine for the first 1000 kilometers), and ora warranty with reference to time and counter (i.e., 3 years' warrantyand 100,000 kilometers).

The data type GDT WarrantyDependencyTypeCode 35800OP may use thefollowing codes: 1 (i.e., the warranty is time-based), 2 (i.e., thewarranty is counter-based), and 3 (i.e., the warranty is time-based andcounter-based).

(qqqqqqqqqqqqqqqqqqqqqqqqq) WarrantyGoodwillCode

A GDT WarrantyGoodwillCode 35800OQ is a coded representation stating towhat extent something is seen as a case for warranty or goodwill. Forexample, the word “something” usually stands for provision of a serviceor a material. An example of the GDT WarrantyGoodwillCode 35800OQ is:

<WarrantyGoodwillCode>1</WarrantyGoodwillCode>

The structure of the GDT WarrantyGoodwillCode 35800OQ is depicted inFIG. 358OQ. For the GDT WarrantyGoodwillCode 35800OQ, the Property isWarranty Goodwill 35803OQ, the Representation/Association is Code35804OQ, the Type is CCT 35805OQ, the Type Name is Code 35806OQ, and theLength is from one to two 35807OQ. The remark 35809OQ shows that the GDTWarrantyGoodwillCode 35800OQ may be restricted.

For the ListID 35810OQ, the Category is Attribute (A) 35811OQ, theObject Class is CodeList 35812OQ, the Property is Identification35813OQ, the Representation/Association is Identifier 35814OQ, the Typeis XSD 35815OQ, the Type Name is Token 35816OQ, and the Cardinality iszero or one 35818OQ.

For the ListAgencyID 35820OQ, the Category is Attribute (A) 35821OQ, theObject Class is CodeListAgency 35822OQ, the Property is Identification35823OQ, the Representation/Association is Identifier 35824OQ, the Typeis XSD 35825OQ, the Type Name is Token 35826OQ, and the Cardinality iszero or one 35828OQ.

For the ListVersionID 35830OQ, the Category is Attribute (A) 35831OQ,the Object Class is CodeList 35832OQ, the Property is Version 35833OQ,the Representation/Association is Identifier 35834OQ, the Type is XSD35835OQ, the Type Name is Token 35836OQ, and the Cardinality is zero orone 35838OQ.

For the ListAgency-SchemeID 35840OQ, the Category is Attribute (A)35841OQ, the Object Class is CodeListAgency 35842OQ, the Property isScheme 35843OQ, the Representation/Association is Identifier 35844OQ,the Type is XSD 35845OQ, the Type Name is Token 35846OQ, and theCardinality is zero or one 35848OQ.

For the ListAgency-SchemeAgencyID 35850OQ, the Category is Attribute (A)35851OQ, the Object Class is CodeListAgency 35852OQ, the Property isSchemeAgency 35853OQ, the Representation/Association is Identifier35854OQ, the Type is XSD 35855OQ, the Type Name is Token 35856OQ, andthe Cardinality is zero or one 35858OQ.

There are only alternative code lists that may differ at configurationand/or runtime. The GDT WarrantyGoodwillCode 35800OQ may be acustomer-specific code list.

The attributes are used as follows: listID—ID of the relevant code list,listAgencyID—The ID of the customer, listVersionID—Version of therelevant code list, listAgencySchemeID—The ID of the scheme by which thecustomer listed in the listAgencyID is identified, andlistAgencySchemeAgencyID—The ID of the managing organization (forexample, DUNS, EAN, SWIFT) that is responsible for identification of theorganization listed in the listAgencyID.

The GDT WarrantyGoodwillCode 35800OQ can be used in the following ways:for service orders or confirmation items, to specify whether they arecovered by a warranty, or to what extent they are covered by goodwill,and in financial accounting, to separate the declaration of costsincurred and revenue obtained according to warranty or goodwill.

Examples of codes with certain business semantics are: Warranty (i.e.,the services or spare parts are completely covered by the warranty),100% goodwill (i.e., the services or spare parts are not covered by thewarranty. However, the customer is extended goodwill in the form of aprice discount of 100%), and 50% goodwill (i.e., the services or spareparts are not covered by the warranty. However, the customer is extendedgoodwill in the form of a price discount of 50%).

(rrrrrrrrrrrrrrrrrrrrrrrr) WithholdingTaxationC haracteristicsCode

A GDT WithholdingTaxationCharacteristicsCode 35800OR is a codedrepresentation of the main characteristics that form the basis of awithholding taxation. For example, main characteristics are the type ofproduct tax (WithholdingTaxEventTypeCode), and the type of tax rate(TaxRateTypeCode) for each type of tax (Tax-TypeCode) related thereto.An example of the GDT WithholdingTaxationCharacteristicsCode 35800OR is:

<WithholdingTaxationCharacteristicsCode listID=21901

listAgencyID=310>1</WithholdingTaxtationCharacteristicsCode>

The structure of the GDT WithholdingTaxationCharacteristicsCode 35800ORis depicted in FIG. 358OR. For the GDTWithholdingTaxationCharacteristicsCode 35800OR, the Object Class isWithholdingTaxationCharacteristics 35801OR, theRepresentation/Association is Code 35804OR, the Type is CCT 35805OR, theType Name is Code 35806OR, and the Length is from one to four 35807OR.The remark 35809OR shows that the GDTWithholdingTaxationCharacteristicsCode 35800OR may be restricted.

For the ListID 35810OR, the Category is Attribute (A) 35811OR, theObject Class is CodeList 35812OR, the Property is Identification35813OR, the Representation/Association is Identifier 35814OR, the Typeis XSD 35815OR, the Type Name is Token 35816OR, and the Cardinality iszero or one 35818OR.

For the ListAgencyID 35820OR, the Category is Attribute (A) 35821OR, theObject Class is CodeListAgency 35822OR, the Property is Identification35823OR, the Representation/Association is Identifier 35824OR, the Typeis XSD 35825OR, the Type Name is Token 35826OR, and the Cardinality iszero or one 35828OR.

For the ListVersionID 35830OR, the Category is Attribute (A) 35831OR,the Object Class is CodeList 35832OR, the Property is Version 35833OR,the Representation/Association is Identifier 35834OR, the Type is XSD35835OR, the Type Name is Token 35836OR, and the Cardinality is zero orone 35838OR.

For the ListAgency-SchemeID 35840OR, the Category is Attribute (A)35841OR, the Object Class is CodeListAgency 35842OR, the Property isScheme 35843OR, the Representation/Association is Identifier 35844OR,the Type is XSD 35845OR, the Type Name is Token 35846OR, and theCardinality is zero or one 35848OR.

For the ListAgency-SchemeAgencyID 35850OR, the Category is Attribute (A)35851OR, the Object Class is CodeListAgency 35852OR, the Property isSchemeAgency 35853OR, the Representation/Association is Identifier35854OR, the Type is XSD 35855OR, the Type Name is Token 35856OR, andthe Cardinality is zero or one 35858OR.

Several extensible, country-specific code lists, which are distinguishedat runtime, may be assigned to the code. If customers create their owncode lists the allocation of attributes changes as follows:listAgencyID—ID of the customer, listVersionID—Assigned and managed bythe customer, listAgencySchemeID—ID of the scheme, andlistAgencySchemeAgencyID—ID of the organization that manages the schemeof the listAgencySchemeID. Although code lists provided may include allcombinations of WithholdingTaxEventTypeCode and TaxRateTypeCode, it maystill be possible to enhance code lists, in order to provide users thepossibility to use in-house codes.

The GDT WithholdingTaxationCharacteristicsCode 35800OR for EN (SAP codelist): listID=“21901”, listAgencyID=“310”, and listVersionID=[Version ofthe relevant code list.].

The data type GDT WithholdingTaxationCharacteristicsCode 35800OR may usethe following codes: 1 (i.e., construction work subject to withholdingtax, at the full tax rate), and 2 (i.e., construction work exempt fromwithholding tax).

(sssssssssssssssssssssssss) AddressPostalAddressID

A GDT AddressPostalAddressID 35800OS is a unique, proprietary identifierof the postal address part of an address. An example of GDTAddressPostalAddressID 35800OS is:

<AddressPostalAddressID>0000010512</AddressPostalAddressID>

The structure of GDT AddressPostalAddressID 35800OS is depicted in FIG.358OS. For the GDT AddressPostalAddressID 35800OS, the object class isAddress Postal Address 35802OS, the property is Identification 35804OS,the Representation/Association is Identifier 35806OS, the Type is CCT35808OS, the Type Name is Identifier 35810OS, and the length is from oneto ten 35812OS. The remark 35814OS shows that the GDTAddressPostalAddressID 35800OS can be restricted.

The data type AddressPostalAddressID 35800OS is required to uniquelyidentify personal addresses and workplace addresses because these arenot identified uniquely by the AddressPersonID alone. The followingdictionary objects are assigned to this GDT in mySAP systems: Dataelement: ADDR_ADDRNUM Domain: AD_ADDRNUM.

(tttttttttttttttttttttttt) AddressRepresentationCode

A GDT AddressRepresentationCode 35800OT is the code for therepresentation of an address. Other representations can be maintainedfor an address, for example, in other languages. An example of GDTAddressRepresentationCode 35800OT is:

<AddressRepresentationCodelistAgencyID=3110>K</AddressRepresentationCode>

The structure of GDT AddressRepresentationCode 35800OT is depicted inFIG. 358OT. For GDT AddressRepresentationCode 35800OT, the object classis address 35801OT, the Property is Representation 35802OT, theRepresentation/Association is Code 35803OT, the Type is CCT 35804OT, theType Name is Code 35805OT, the Length is one 35806OT. For listAgencyID35820OT, the category is A 35811OT, the object class is CodeListAgency35822OT, the property is Identification 35823OT, theRepresentation/Association is Identifier 35824OT, the type is xsd35825OT, the type name is token 35826OT, and the cardinality is fromzero to one 35828OT. For listVersionID 35830OT, the category is A35831OT, the object class is CodeList 35832OT, the property is Version35833OT, the Representation/Association is Identifier 35834OT, the typeis xsd 35835OT, the type name is token 35836OT, and the cardinality isfrom zero to one 35838OT. For listAgencySchemeID 35840OT, the categoryis A 35841OT, the object class is CodeListAgency 35842OT, the propertyis Scheme 35843OT, the Representation/Association is Identifier 35844OT,the type is xsd 35845OT, the type name is token 35846OT, and thecardinality is from zero to one 35848OT. For listAgencySchemeAgencyID35850OT, the category is A 35851OT, the object class is CodeListAgency35852OT, the property is SchemeAgency 35853OT, theRepresentation/Association is Identifier 35854OT, the type is xsd35855OT, the type name is token 35856OT, and the cardinality is fromzero to one 35858OT.

An extendable SAP code list is assigned to theAddressRepresentafionCode. SAP customers can change this code list. Inits unchanged state, the SAP code list has the following attributes:listID=“10181,” listAgencyID=“310,” and listVersionID. If an SAPcustomer makes changes to the SAP code list, the values assigned to theattributes change as follows:

-   -   listAgencyID—ID of the SAP customer (ID from DE 3055 if listed        there)    -   listVersionID—Assigned and managed by the SAP customer    -   listAgencySchemeID—ID of the scheme    -   listAgencySchemeAgencyID—ID of the organization

The data type AddressRepresentationCode 35800OT may be used in theadministration of address data to indicate different addressrepresentations. A value for the AddressAlternativeRepresentationCode isflagged as “Active” in the table TSADVC. The following codes arepossible: (A Arabic)—Arabic address representation; (B Hebrew)—Hebrewaddress representation; (C Chinese)—Chinese address representation; (GGreek)—Greek address representation; (H Hangul)—Address representationin Hangul (Korean); (I International)—International addressrepresentation (Latin characters); (K Kanji)—Address representation inKanji (Japanese); (M Traditional Chinese)—Address representation intraditional Chinese characters; (N Katakana)—Address representation inKatakana (Japanese); (R Cyrillic)—Address representation in Cyrillic(Russian); (T Thai)—Thai address representation.

(uuuuuuuuuuuuuuuuuuuuuuuuu) BusinessSystemID

A GDT BusinessSystemID 35800OU is a unique identifier for a businesssystem. A business system is one that participates in message exchangeeither as a sending or receiving system. An example of GDTBusinessSystemID 35800OU is:

<BusinessSystemID>AE1_(—)805</BusinessSystemID>

The structure of GDT BusinessSystemID 35800OU is depicted in FIG. 358OU.For GDT BusinessSystemId 35800OU, the Property is Business System35806OU, the Representation/Association is Identification 35808OU, theType is Identifier 35810OU, the Type Name is CCT 35812OU, the Length isfrom one to sixty 35814OU.

The BusinessSystemID is designated for use within a system landscape andis used to identify the source and target system of data. For example,in the SAP System Landscape Directory (SLD), the BusinessSystemID is theunique identification of a system in a system landscape. In SAP systemsthe BusinessSystemID is represented by the data element SLD_BSKEY.

(vvvvvvvvvwvvvvvvvvvvvvvvv) BusinessTransactionDocumentParty

A GDT BusinessTransactionDocumentParty 35820OVi contains the informationthat is exchanged—in accordance with common business understanding—inbusiness documents about a party involved in business transactions. Thisinformation is used to identify the party and the party's address, aswell as the party's contact person and the contact person's address.This identification can take place using an internal ID, a standardizedID, or IDs assigned by the parties involved.

For example, a party may be a natural person, organization, or businesspartner group in which a company has a business or intra-enterpriseinterest. This could be a person, organization, or group within oroutside of the company. An ID assigned by a party identifies in the namethe role the assigning party plays in the business transaction. Atpresent, the roles are Buyer, Seller, ProductRecipient, Vendor, BillTo,BillFrom and Bidder.

The examples show the xml instance of the GDTBusinessTransactionDocumentParty within a purchase order for differentidentification types (standard ID, party IDs, internal ID). Here, theparty assumes the role of Buyer. According to the rule Rx, the GDT nameBusinessTransactionDocumentParty is converted in the XML instance asshown in the following examples. Example 1 contains a Standard ID andPartyIDs. <PurchaseOrder> ... <BuyerParty> <StandardIDschemeAgencyID=”016”>4711</StandardID> <BuyerID>9873</BuyerID><SellerID>487847</SellerID> <Address>...</Address> <ContactPerson><BuyerID>9874</BuyerID> <SellerID>487848</SellerID><Address>...</Address> </ContactPerson> </BuyerParty> </PurchaseOrder>

The schemeAgencyID of “016” corresponds to Dun&Bradstreet according tocode list D3055 that means that the DUNS number is assigned byDun&Bradstreet.

Example 2 contains an Internal ID. <PurchaseOrder> ... <BuyerParty><InternalID schemeID=”PartyID” schemeAgencyID=”BPL_300”>747</InternalID> <Address>...</Address> <ContactPerson> <InternalIDschemeID=”PartyID” schemeAgencyID=”BPL_300”>737 </InternalID><Address>...</Address> </ContactPerson> </BuyerParty> <PurchaseOrder>

The schemeID of “PartyID” indicates that the scheme “PartyID” was usedto identify the party. The schemeAgencyID=of “BPL_(—)300” indicates thatthe scheme was assigned by the CMDM system “BPL_(—)300”.

The structure of GDT BusinessTransactionDocumentParty 35820OVI isdepicted in FIGS. 358OVi-iii. For the GDTBusinessTransactionDocumentParty 35820OVi, the Object Class isBusinessTransactionDocumentParty 35821OVi and theRepresentation/Association is Details 35822OVi.

For the InternalID 35823OVi, the Category is Element (E) 35827OVi, theObject Class is BusinessTransactionDocumentParty 35824OVi, thePropertyQualifier is Internal 35825OVi, the Property is Identification35826OVi, the Representation/Association is Identifier 35828OVi, theType is CDT 35830OVi, the Type Name is PartyInternalID 35831OVi, and theCardinality is zero or one 35832OVi.

For the StandardID 35833OVi, the Category is Element (E) 35837OVi, theObject Class is BusinessTransactionDocumentParty 35834OVi, thePropertyQualifier is Standard 35835OVi, the Property is Identification35836OVi, the Representation/Association is Identifier 35838OVi, theType is CDT 35840OVi, the Type Name is PartyStandardID 35841OVi, and theCardinality is zero or any number 35842OVi.

For the BuyerID 35843OVi, the Category is Element (E) 35844OVi, theObject Class is BusinessTransactionDocumentParty 35845OVi, thePropertyQualifier is Buyer 35846OVi, the Property is Version 35848OVi,the Representation/Association is Identifier 35850OVi, the Type is CDT35851OVi, the Type Name is PartyPartyID 35852OVi, and the Cardinality iszero or one 35853OVi.

For the SellerID 35854OVi, the Category is Element (E) 35855OVi, theObject Class is BusinessTransactionDocumentParty 35856OVi, thePropertyQualifier is Seller 35857OVi, the Property is Identification35858OVi, the Representation/Association is Identifier 35859OVi, theType is CDT 35860OVi, the Type Name is PartyPartyID 35861OVi, and theCardinality is zero or one 35862OVi.

For the ProductRecipientID 35863OVi, the Category is Element (E)35864OVi, the Object Class is BusinessTransactionDocumentParty 35865OVi,the PropertyQualifier is ProductRecipient 35866OVi, the Property isIdentification 35867OVi, the Representation/Association is Identifier35868OVi, the Type is CDT 35869OVi, the Type Name is PartyPartyID35870OVi, and the Cardinality is zero or one 35871OVi.

For the VendorID 35823OVii, the Category is Element (E) 35827OVii, theObject Class is BusinessTransactionDocumentParty 35824OVii, thePropertyQualifier is Vendor 35825OVii, the Property is Identification35826OVii, the Representation/Association is Identifier 35828OVii, theType is CDT 35830OVii, the Type Name is PartyPartyID 35831OVii, and theCardinality is zero or one 35832OVii.

For the BillToID 35833OVii, the Category is Element (E) 35837OVii, theObject Class is BusinessTransactionDocumentParty 35834OVii, thePropertyQualifier is BillTo 35835OVii, the Property is Identification35836OVii, the Representation/Association is Identifier 35838OVii, theType is CDT 35840OVii, the Type Name is PartyPartyID 35841OVii, and theCardinality is zero or one 35842OVii.

For the BillFromID 35843OVii, the Category is Element (E) 35844OVii, theObject Class is BusinessTransactionDocumentParty 35845OVii, thePropertyQualifier is BillFrom 35846OVii, the Property is Identification35848OVii, the Representation/Association is Identifier 35850OVii, theType is CDT 35851OVii, the Type Name is PartyPartyID 35852OVii, and theCardinality is zero or one 35853OVii.

For the BidderID 35823OViii, the Category is Element (E) 35824OViii, theObject Class is BusinessTransactionDocumentParty 35825OViii, thePropertyQualifier is Bidder 35826OViii, the Property is Identification35828OViii, the Representation/Association is Identifier 35830OViii, theType is CDT 35831OViii, the Type Name is PartyPartyID 35832OViii, andthe Cardinality is zero or one 35833OViii.

For the TaxID 35834OViii, the Object Class isBusinessTransactionDocumentParty 35835OViii, the Property isTaxIdentification 35836OViii, the Representation/Association isIdentifier 35838OViii, the Type is GDT 35840OViii, the Type Name isPartyTaxID 35841OViii, and the Cardinality is zero or one 35842OViii.

For the Address 35843OViii, the Category is Element (E) 35844OViii, theObject Class is BusinessTransactionDocumentParty 35845OViii, theProperty is Address 35848OViii, the Representation/Association isAddress 35850OViii, the Type is GDT 35851OViii, the Type Name is Address35852OViii, and the Cardinality is zero or one 35853OViii.

For the ContactPerson 35854OViii, the Category is Element (E)35855OViii, the Object Class is BusinessTransactionDocumentParty35856OViii, the Property is ContactPerson 35858OViii, theRepresentation/Association is ContactPerson 35859OViii, the Type is GDT35860OViii, the Type Name is ContactPerson 35861OViii, and theCardinality is zero or one 35862OViii.

The InternalID is the proprietary identifier that is used when bothsender and recipient can access shared master data (extendedenterprise). The StandardID is the standardized identifier for thisparty, whose identification scheme is managed by an agency from the DE3055 code list. The BuyerID is the identifier that is used by theBuyerParty for this party. The SellerID is the identifier that is usedby the SellerParty for this party. The ProductRecipientIDis theidentifier that is used by the ProductRecipientParty for this party. TheVendorID is the identifier that is used by the VendorParty for thisparty. The BillToID is the identifier that is used by the BillToPartyfor this party. The BillFromID is the identifier that is used by theBillFromParty for this party. The BidderID is the identifier that isused by the BidderParty for this party. The TaxID is the identifierissued by an tax authority for a party. The Address is the address ofthe party. The ContactPerson is the contact person of the party.

In some implementations, the different IDs of aBusinessTransactionDocumentParty always identify the same party. A partyis identified in the following (complementary) ways: InternalID (whensender and recipient can access shared master data), StandardID (whensender and recipient can manage standardized identifiers),PartytPartyIDs (when sender and recipient are interested in the PartyIDsassigned by the parties involved). Of the IDs available to the sender,generally only IDs that the recipient is expected to understand are usedin a message. The CDT BusinessTransactionDocumentParty can only be usedin business documents (BusinessTransactionDocuments). The CDTBusinessTransactionDocumentParty is used in messages for internal andexternal communication to transmit required information about theparties involved.

(wwwwwwwwwwwwwwwwwwwwwwwww) CommunicationAddressUsage

A GDT CommunicationAddressUsage 35800OW is a time-dependent usage of acommunication address. A communication address can, for example, be atelephone number, a fax number or an e-mail address. An example of GDTCommunicationAddressUsage 35800OW is: <CommunicationAddressUsage><Code>AD_DEFAULT</Code> <ValidityPeriod><StartDate>2004-01-01</StartDate> <EndDate>2005-09-30</EndDate></ValidityPeriod> </CommunicationAddressUsage>

The structure of GDT CommunicationAddressUsage 35800OW is depicted inFIG. 358OW. For the GDT CommunicationAddressUsage 35800OW, the ObjectClass is CommunicationAddressUsage 35801OW and theRepresentation/Association is Details 35804OW.

For the Code 35810OW, the Category is Element (E) 35811OW, the ObjectClass is CommunicationAddressUsage 35812OW, the Property is Usage35813OW, the Representation/Association is Date 35814OW, the Type is GDT35815OW, the Type Name is CommunicationAddressUsageCode 35816OW, and theCardinality is one 35818OW.

For the ValidityPeriod 35820OW, the Category is Element (E) 35821OW, theObject Class is CommunicationAddressUsage 35822OW, the Property isValidity 35823OW, the Representation/Association is DatePeriod 35824OW,the Type is GDT 35825OW, the Type Name is DatePeriod 35826OW, and theCardinality is zero or one 35828OW.

CommunicationAddressUsage consists of the following sub-elements: Code(The code for indicating the usage) and ValidityPeriod (Period ofvalidity for using the communication address). The GDTCommunicationAddressUsage is used to assign a particular usage to thecommunication details for a period of time.

(xxxxxxxxxxxxxxxxxxxxxxxxx) CommunicationAddressUsageCode

A GDT CommunicationAddressUsageCode 35800OX is the coded representationfor the usage of a communication address. A communication address can,for example, be a telephone number, a fax number or an e-mail address.An example of GDT CommunicationAddressUsageCode 35800OX is:  <CommunicationAddressUsageCodelistAgencyID=310>AD_DEFAULT</CommunicationAddressUsageCode>

For listAgencyID 35820OX, the category is A 35811OX, the object class isCodeListAgency 35822OX, the property is Identification 35823OX, theRepresentation/Association is Identifier 35824OX, the type is xsd35825OX, the type name is token 35826OX, and the cardinality is fromzero to one 35828OX. For listVersionID 35830OX, the category isA35831OX, the object class is CodeList35832OX, the property is Version35833OX, the Representation/Association is Identifier 35834OX, the typeis xsd 35835OX, the type name is token 35836OX, and the cardinality isfrom zero to one 35838OX. For listAgencySchemeID 35840OX, the categoryis A 35841OX, the object class is CodeListAgency 35842OX, the propertyis Scheme 35843OX, the Representation/Association is Identifier 35844OX,the type is xsd 35845OX, the type name is token 35846OX, and thecardinality is from zero to one 35848OX. For listAgencySchemeAgencyID35850OX, the category is A 35851OX, the object class is CodeListAgency35852OX, the property is SchemeAgency 35853OX, theRepresentation/Association is Identifier 35854OX, the type is xsd35855OX, the type name is token 35856OX, and the cardinality is fromzero to one 35858OX.

An extendable SAP code list is assigned to theCommunicationAddressUsageCode. SAP customers can extend this code listby additional entries; how-ever, the already-existing entries may not beremoved from this SAP code list The attributes are as follows:listID=“10261,” listAgencyID=“310,” If an SAP customer makes changes tothe SAP code list, the values assigned to the attributes change asfollows: listAgencyID—ID of the SAP customer (ID from DE 3055 if listedthere), listVersionID—Assigned and managed by the SAP customer,listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055, listAgencySchemeAgencyID

(yyyyyyyyyyyyyyyyyyyyyyyyy) CriticalityCode

The GDT CriticalityCode 35800OY is a coded representation of howcritical a status is. An example of GDT CriticalityCode 35800OY is:

<CriticalityCode>1</CrificalityCode>

The structure of GDT CriticalityCode 35800OY is depicted in FIG. 358OY.For GDT CriticalityCode 35800OY, the Property is Criticality 35802OY,the Representation/Association is Code 35804OY, the Type is CCT 35806OY,the Type Name is Code 35808OY, and the Length is one 35810OY. The remark35812OY shows that the GDT CriticalityCode 35800OY can be restricted.

One fixed SAP code list is assigned to the CriticalityCode. Theattributes are as follows: listID=“10264,” listAgencyID=“310,” andlistVersionID. The CriticalityCode is used to specify whether a statusis critical, partially critical or not critical. The following codes maybe used: 1 (Critical) The status is viewed as critical, 2 (Partiallycritical) The status is viewed as partially critical, and 3 (Notcritical) The status is viewed as non-critical.

(zzzzzzzzzzzzzzzzzzzzzzzzz) OpportunityGroupCode

A GDT OpportunityGroupCode 35800PC is the coded representation of agroup of opportunities for sales displayed according to subjectivecriteria. A sales opportunity is used in CRM in order to documentrecognized sales opportunities, and to support the professional salesperson in converting this opportunity. An example of the GDTOpportunityGroupCode 35800PC is:

<OpportunityGroupCode >1</OpportunityGroupCode >

The structure of GDT OpportunityGroupCode 35800PC is depicted in FIG.358PC. The GDT OpportunityGroupCode 35800PC includes attributes listID35816PC, listAgencyID 35832PC, listVersionID 35848PC, listAgencySchemeID35864PC, and listAgencySchemeAgencyID 35880PC. For the GDTOpportunityGroupCode 35800PC, the Object Class term is Opportunity35802PC, the Property term is Group 35804PC, theRepresentation/Association term is Code 35806PC, the Type term is CCT35808PC, the Type Name term is Code 35810PC, and the Length is from oneto four 35812PC.

For the listID 35816PC, the Category is Attribute 35818PC, the ObjectClass term is CodeList 35820PC, the Property term is Identification35822PC, the Representation/Association term is Identifier 35822PC, theType term is xsd 35826PC, and the Type Name term is token 35828PC. Thecardinality between the listID 35816PC and the GDT OpportunityGroupCode35800PC is either zero or one 35830PC.

For the listAgencyID 35832PC, the Category is Attribute 35834PC, theObject Class term is CodeListAgency 35836PC, the Property term isIdentification 35838PC, the Representation/Association term isIdentifier 35840PC, the Type term is xsd 35842PC, and the Type Name termis token 35844PC. The Cardinality between the listAgencyID 35832PC andthe GDT OpportunityGroupCode 35800PC is either zero or one 35846PC.

For the listVersionID 35848PC, the Category is Attribute 35850PC, theObject Class term is CodeList 35852PC, the Property term is Version35854PC, the Representation/Association term is Identifier 35856PC, theType term is xsd 35858PC, and the Type Name term is token 35860PC. Thecardinality between the listVersionID 35848PC and the GDTOpportunityGroupCode 35800PC is either zero or one 35862PC.

For the listAgencySchemeID 35864PC, the Category is Attribute 35866PC,the Object Class term is CodeListAgency 35868PC, the Property term isScheme 35870PC, the Representation/Association term is Identifier35872PC, the Type term is xsd 35874PC, and the Type Name term is token35876PC. The cardinality between the listAgencySchemeID 35864PC and theGDT OpportunityGroupCode 35800PC is either zero or one 35878PC.

For the listAgencySchemeAgencyID 35880PC, the Category is Attribute35882PC, the Object Class term is CodeListAgency 35884PC, the Propertyterm is SchemeAgency 35886PC, the Representation/Association term isIdentifier 35888PC, the Type term is xsd 35890PC, and the Type Name termis token 35892PC. The cardinality between the listAgencySchemeAgencyID35880PC and the GDT OpportunityGroupCode 35800PC is either zero or one35894PC.

In some variations, multiple code lists are allowed forOpportunityGroupCode 35800PC. The customer can add other code lists. Insome variations, the attributes may be as follows:

listID=“10055”

listAgencyID=“310”

listVersionID—version of the relevant code list.

In some implementations, the attributes can be used as follows:

ListID—ID of the relevant code list. This is assigned and administeredby the organization responsible for the code list, which is not listedin DE 3055. GDT owner must obtain the exact ID from the organizationresponsible. If no unique ID is available, the name of the relevant codelist or code type used in the corresponding standard, specification, orscheme of the responsible organization must be entered.

listAgencyID—ID of the administrative organization of the code list.This ID is provided by the organization and is taken from DE 3055. (Forexample, the DUNS number or EAN number of a company). GDT owner mustobtain the relevant ID from the organization responsible.

ListVersionID—version of the relevant code list. This is assigned andadministered by the organization listed in the listAgencyID. GDT ownermust obtain the relevant versions ID from the organization responsible.If no version has been issued for the code list, the version of thestandard, the specification, or the scheme must be used.

listAgencySchemeID—The identification of the scheme once theorganization listed in the listAgencyID is identified. It is aparticular identification scheme for partners, businesses, and members(such as DUNS+4), and so on, of an administering organization (such asEAN, DUNS, and SWIFT) that is listed in the listAgencySchemeAgencyID.

ListAgencySchemeAgencyID—the ID of the administering organization (suchas DUNS, EAN or SWIFT) that is responsible for identifying theorganization listed in the ListAgencyID. It has to be listed in DE 3055.

The GDT OpportunityGroupCode 35800PC can be used primarily in reporting.As an example, a possible customer-specific code semantics can beStrategic Project, which the OpportunityGroupCode groups salesopportunities according to strategic projects.

An exemplary code list may be: Code Name Description 1 MiscellaneousOther 2 Customer Care The sales opportunity serves to maintain existingcustomers 3 New Business The sales opportunity serves to win newcustomers

(aaaaaaaaaaaaaaaaaaaaaaaaaa) OpportunityOriginTypeCode

A GDT OpportunityoriginTypeCode 35800PD is the coded representationregarding the origin type for an opportunity. The origin type does notrefer to the technical origin, but a place, a communication channel, andso on that represents the type of origin of a sales opportunity. Anexample of the GDT OpportunityoriginTypeCode 35800PD is:

<OpportunityoriginTypeCode>1</OpportunityoriginTypeCode>

The structure of GDT OpportunityoriginTypeCode 35800PD is depicted inFIG. 358PD. The GDT OpportunityoriginTypeCode 35800PD includesattributes listID 35816PD, listAgencyID 35832PD, listVersionID 35848PD,listAgencySchemeID 35864PD, and listAgencySchemeAgencyID 35880PD. Forthe GDT OpportunityoriginTypeCode 35800PD, the Object Class term isOpportunity 35802PD, the Property term is OriginType 35804PD, theRepresentation/Association term is Code 35806PD, the Type term is CCT35808PD, the Type Name term is Code 35810PD, and the Length is from oneto three 35812PD.

For the listID 35816PD, the Category is Attribute 35818PD, the ObjectClass term is CodeList 35820PD, the Property term is Identification35822PD, the Representation/Association term is Identifier 35822PD, theType term is xsd 35826PD, and the Type Name term is token 35828PD. Thecardinality between the listID 35816PD and the GDTOpportunityoriginTypeCode 35800PD is either zero or one 35830PD.

For the listAgencyID 35832PD, the Category is Attribute 35834PD, theObject Class term is CodeListAgency 35836PD, the Property term isIdentification 35838PD, the Representation/Association term isIdentifier 35840PD, the Type term is xsd 35842PD, and the Type Name termis token 35844PD. The Cardinality between the listAgencyID 35832PD andthe GDT OpportunityoriginTypeCode 35800PD is either zero or one 35846PD.

For the listVersionID 35848PD, the Category is Attribute 35850PD, theObject Class term is CodeList 35852PD, the Property term is Version35854PD, the Representation/Association term is Identifier 35856PD, theType term is xsd 35858PD, and the Type Name term is token 35860PD. Thecardinality between the listVersionID 35848PD and the GDTOpportunityOriginTypeCode 35800PD is either zero or one 35862PD.

For the listAgencySchemeID 35864PD, the Category is Attribute 35866PD,the Object Class term is CodeListAgency 35868PD, the Property term isScheme 35870PD, the Representation/Association term is Identifier35872PD, the Type term is xsd 35874PD, and the Type Name term is token35876PD. The cardinality between the listAgencySchemeID 35864PD and theGDT OpportunityOriginTypeCode 35800PD is either zero or one 35878PD.

For the listAgencySchemeAgencyID 35880PD, the Category is Attribute35882PD, the Object Class term is CodeListAgency 35884PD, the Propertyterm is SchemeAgency 35886PD, the Representation/Association term isIdentifier 35888PD, the Type term is xsd 35890PD, and the Type Name termis token 35892PD. The cardinality between the listAgencySchemeAgencyID35880PD and the GDT OpportunityOriginTypeCode 35800PD is either zero orone 35894PD.

In some variations, multiple code lists can be allowed for the GDTOpportunityOriginTypeCode 35800PD. The customer can add other codelists. In some variations, the attributes are as follows:

listID=“10076”

listAgencyID=“310”

ListVersionID—version of the relevant code list.

The attributes are used as follows:

ListID—ID of the relevant code list. This is assigned and administeredby the organization responsible for the code list, which is not listedin DE 3055. GDT owner must obtain the exact ID from the organizationresponsible. If no unique ID is available, the name of the relevant codelist or code type used in the corresponding standard, specification, orscheme of the responsible organization must be entered.

listAgencyID—ID of the administrative organization of the code list.This ID is provided by the organization and is taken from DE 3055. (Forexample, the DUNS number or EAN number of a company). GDT owner mustobtain the relevant ID from the organization responsible.

ListVersionID—version of the relevant code list. This is assigned andadministered by the organization listed in the listAgencyID. GDT ownermust obtain the relevant versions ID from the organization responsible.If no version has been issued for the code list, the version of thestandard, the specification, or the scheme must be used.

listAgencySchemeID—The identification of the scheme once theorganization listed in the listAgencyID is identified. It is aparticular identification scheme for partners, businesses, and members(such as DUNS+4), and so on, of an administering organization (such asEAN, DUNS, and SWIFT) that is listed in the listAgencySchemeAgencyID.

ListAgencySchemeAgencyID—the ID of the administering organization (suchas DUNS, EAN or SWIFT) that is responsible for identifying theorganization listed in the ListAgencyID. It has to be listed in DE 3055.

The OpportunityoriginTypeCode 35800PD is used primarily in reporting. Anexample of possible customer-specific code semantic may be a Publicinvitation to tender, which is a business transaction originates from apublic invitation to tender.

An exemplary code list may be: Code Name Description 1 Trade Fair Theopportunity originates from a trade fair. 2 External The opportunityoriginates from contact with an Partner external partner. 3 Campaign Theopportunity originates from a campaign. 4 Telephone The opportunityoriginates from a telephone inquiry. Inquiry 5 Roadshow The opportunityoriginates from a roadshow.

(bbbbbbbbbbbbbbbbbbbbbbbbbb) PersonNameFormatCode

A GDT PersonNameFormatCode 35800PE is the coded representation of therule used for formatting the complete name of a person using its namecomponents. An example of the GDT PersonNameFormatCode 35800PE is

<PersonNameFormatCode listAgencyID=310>01</PersonNameFormatCode>

The structure of GDT PersonNameFormatCode 35800PE is depicted in FIG.358PE. The GDT PersonNameFormatCode 35800PE includes attributes listID35816PE, listAgencyID 35832PE, listVersionID 35848PE, listAgencySchemeID35864PE, and listAgencySchemeAgencyID 35880PE. For the GDTPersonNameFormatCode 35800PE, the Property term is Person Name Format35802PE, the Representation/Association term is Code 35804PE, the Typeterm is CCT 35806PE, the Type Name term is Code 35808PE, and the Lengthis either one or two 35810PE.

For the listID 35816PE, the Category is Attribute 35818PE, the ObjectClass term is CodeList 35820PE, the Property term is Identification35822PE, the Representation/Association term is Identifier 35822PE, theType term is xsd 35826PE, and the Type Name term is token 35828PE. Thecardinality between the listID 35816PE and the GDT PersonNameFormatCode35800PE is either zero or one 35830PE.

For the listAgencyID 35832PE, the Category is Attribute 35834PE, theObject Class term is CodeListAgency 35836PE, the Property term isIdentification 35838PE, the Representation/Association term isIdentifier 35840PE, the Type term is xsd 35842PE, and the Type Name termis token 35844PE. The Cardinality between the listAgencyID 35832PE andthe GDT PersonNameFormatCode 35800PE is either zero or one 35846PE.

For the listVersionID 35848PE, the Category is Attribute 35850PE, theObject Class term is CodeList 35852PE, the Property term is Version35854PE, the Representation/Association term is Identifier 35856PE, theType term is xsd 35858PE, and the Type Name term is token 35860PE. Thecardinality between the listVersionID 35848PE and the GDTPersonNameFormatCode 35800PE is either zero or one 35862PE.

For the listAgencySchemeID 35864PE, the Category is Attribute 35866PE,the Object Class term is CodeListAgency 35868PE, the Property term isScheme 35870PE, the Representation/Association term is Identifier35872PE, the Type term is xsd 35874PE, and the Type Name term is token35876PE. The cardinality between the listAgencySchemeID 35864PE and theGDT PersonNameFormatCode 35800PE is either zero or one 35878PE.

For the listAgencySchemeAgencyID 35880PE, the Category is Attribute35882PE, the Object Class term is CodeListAgency 35884PE, the Propertyterm is SchemeAgency 35886PE, the Representation/Association term isIdentifier 35888PE, the Type term is xsd 35890PE, and the Type Name termis token 35892PE. The cardinality between the listAgencySchemeAgencyID35880PE and the GDT PersonNameFormatCode 35800PE is either zero or one35894PE.

In some variations, several extensible, country-specific code lists,which are distinguished at runtime, are assigned to thePersonNameFormatCode. Customers can change these code lists. If acustomer makes changes to one of the code lists, the values assigned tothe attributes change as follows:

listAgencyID—ID of the customer (ID from DE 3055 if listed there)

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of the organization (taken from DE 3055)that manages the scheme of the listAgencySchemeID

In some variations, the data type PersonNameFormatCode 35800PE is usedin the names of persons. In one example, a “PersonNameFormatCode for DE”code list can be:

listID=“20901”

listAgencyID=“310”

listVersionID=Version of the relevant code list. Code Name Description01 Form of address, first name, additional name, last name 02 Academictitle, first name, name prefix, last name

In another example, a “PersonNameFormatCode for JP” code list can be:

listID=“20902”

listAgencyID=“310”

listVersionID=Version of the relevant code list. Code Name Description01 First name, last name

In another example, a “PersonNameFormatCode for US” code list can be:

listID=“20903”

listAgencyID=“310”

listVersionID=Version of the relevant code list. Code Name Description01 Form of address, first name, initials, last name, academic title

(cccccccccccccccccccccccccc) PriceComponentFixationCode

A GDT PriceComponentFixationCode 35800PF is the coded representation ofthe fixation of a price component. The fixation specifies how elementsof a price component are fixed when a price component is recalculated.An example of the GDT PriceComponentFixationCode 35800PF is:

<PriceComponentFixationCode>1</PriceComponentFixationCode>

The structure of GDT PriceComponentFixationCode 35800PF is depicted inFIG. 358PF. For the GDT PriceComponentFixationCode 35800PF, the ObjectClass term is PriceComponent 35802PF, the Property term is Fixation35804PF, the Representation/Association term is Code 35806PF, the Typeterm is CCT 35808PF, the Type Name term is Code 35810PF, and the Lengthis from one to two 35812PF. The GDT PriceComponentFixationCode 35800PFmay be restricted 35814PF.

The GDT PriceSpecificationBaseCode 35800PF can be a fixed code list. Forexample, the attributes of PriceComponentFixationCode may have thefollowing values:

listID=10126

listAgencyID=310

listVersionID=Version of the relevant code list. Assigned and managed bySAP AG.

In some variations, the PriceComponentFixationCode can be a proprietarycode list with fixed predefined values. Changes to the permitted valuesinvolve changes to the interface. An exemplary code list is: Code NameDescription 1 Basis Fixation of the basis of the price component 2 ValueFixation of the calculated value of the price component 3 Basis-ValueFixation of the basis and the calculated value of the price component 4Rate-Basis Fixation of the rate, the basis, and the calculated Valuevalue of the price component 5 All Fixation of the entire pricecomponent

(dddddddddddddddddddddddddd)PriceComponentItemHierarchyEvaluationMethodCode

A GDT PriceComponentItemHierarchyEvaluationMethodCode 35800PG is thecoded representation of the method used to evaluate the hierarchy ofitems in the underlying business transaction document for this pricecomponent. Exactly one item of the underlying business transactiondocument is assigned to a price component on item level. If this itemhas a hierarchical structure, then the method describes the influencethat the relevant price component of the higher-level item or subitemhas on the price component of the actual item, for the purpose ofevaluating the item hierarchy. An example (Instance) of the GDTPriceComponentItemHierarchyEvaluationMethodCode 35800PG is:

<PriceComponentItemHierarchyEvaluationMethodCode>1</PriceComponentItemHierarchyEvaluationMethodCode>

The structure of GDT PriceComponentItemHierarchyEvaluationMethodCode35800PG is depicted in FIG. 358PG. For the GDTPriceComponentItemHierarchyEvaluationMethodCode 35800PG, the ObjectClass term is Price Component 35802PG, the Property term is ItemHierarchy Evaluation Method 35804PG, the Representation/Association termis Code 35806PG, the Type term is CCT 35808PG, the Type Name term isCode 35810PG, and the Length is from one to two 35812PG. The GDTPriceComponentItemHierarchyEvaluationMethodCode 35800PG may berestricted 35814PG.

In some variations, the GDTPriceComponentItemHierarchyEvaluationMethodCode 35800PG can be a fixedCodelist. For example, the attributes of the GDTPriceComponentItemHierarchyEvaluationMethodCode 35800PG can have thefollowing values:

listID=10124

listAgencyID=310

listVersionID=Version of the relevant code list.

In some variations, subitems are used in bills of material, for example.In this case, the bill of material header forms the main item. Adiscount (for example, 10%) that is entered manually on the bill ofmaterial header should be copied to all subitems. Conversely, the netprice is usually cumulated from the subitems to the bill of materialheader.

The GDT PriceComponentItemHierarchyEvaluationMethodCode 35800PG is aproprietary code list with fixed predefined values. Changes to thepermitted values involve changes to the interface. For example, a codelist can be: Code Name Description 1 Duplication The fixing of theprice, discount, or surcharge based on the price claculation isduplicated by the higher-level item. 2 Cumulation The price component iscalculated by aggregating all subitems.

(eeeeeeeeeeeeeeeeeeeeeeeeee) PriceComponentOriginCode

A GDT PriceComponentOriginCode 35800PH is the coded representation ofthe origin of the price component. A price component can be createdmanually or automatically; it can be created automatically from severaldata sources. An example of the GDT PriceComponentOriginCode 35800PH is:

<PriceComponentOriginCode>1</PriceComponentOriginCode>

The structure of GDT PriceComponentOriginCode 35800PH is depicted inFIG. 358PH. For the GDT PriceComponentOriginCode 35800PH, the ObjectClass term is Price Component 35802PH, the Property term is Origin35804PH, the Representation/Association term is Code 35806PH, the Typeterm is CCT 35808PH, the Type Name term is Code 35810PH, and the Lengthis from one to two 35812PH. The GDT PriceComponentOriginCode 35800PH maybe restricted 35814PH.

In some variations, there is exactly one code list and the GDTPriceComponentOriginCode 35800PH is a fixed code list. As an example,the attributes of PriceComponentOriginCode 35800PH have the followingvalues:

listID=10123

listAgencyID=310

listVersionID=Version of the relevant code list.

In some implementations, the PriceComponentOriginCode 35800PH may aproprietary code list with fixed predefined values. Changes to thepermitted values involve changes to the interface. Code Name Description1 From external source The entire price component was created externallywith reference to the item of the business transaction that is assignedto the price component. 2 Manually The input data that is used tocalculate the price component was created manually. 3 From the item Theinput data that is used to calculate the price component was createdwith reference to the item that is assigned to the price component, orwith reference to all items of the business transaction. 4 From thebusiness The input data that is used to calculate the price transactioncomponent was created with reference to the business transactiondocument. 5 From another The input data that is used to calculate theprice business transaction component was created with reference toanother business transaction document.

(ffffffffffffffffffffffffff) ProductCategoryHierarchyID

A GDT ProductCategoryHierarchyID 35800PK is a unique identifier for aproduct category hierarchy. A product category hierarchy is aclassification system for products. It describes a hierarchical order ofproduct categories that exist on both higher and lower levels inrelation to one another, and whose structure can be represented as atree (also see ProductCategoryID ). An example of the GDTProductCategoryHierarchyID 35800PK is:

<ProductCategoryHierarchyID>BASE_FIN</ProductCategoryHierarchyID>

The structure of GDT ProductCategoryHierarchyID 35800PK is depicted inFIG. 358PK. For the GDT ProductCategoryHierarchyID 35800PK, the ObjectClass term is Product Category Hierarchy 35802PK, the Property term isIdentification 35804PK, the Representation/Association term isIdentifier 35806PK, the Type term is GDT 35808PK, the Type Name term isIdentifier 35810PK, and the Length is from one to ten 35812PK. The GDTProductCategoryHierarchyID 35800PK may be restricted 35814PK.

In some variations, the ProductCategoryHierarchyID 35800PK may be usedin business objects.

(gggggggggggggggggggggggggg) ProductRelationshipTypeCode

A GDT ProductRelationshipTypeCode 35800PL is the code for the nature ofthe product relationship with regard to the type and function of theobjects involved. An example of the GDT ProductRelationshipTypeCode35800PL is:

<ProductRelationshipTypeCode>ACCESS</ProductRelationshipTypeCode>

The structure of GDT ProductRelationshipTypeCode 35800PL is depicted inFIG. 358PL. The GDT ProductRelationshipTypeCode 35800PL includesattributes listAgencyID 35814PL, listVersionID 35830PL,listAgencySchemeID 35846PL, and listAgencySchemeAgencyID 35862PL. Forthe GDT ProductRelationshipTypeCode 35800PL, the Object Class term isProduct 35801PL, the Property term is Type 35802PL, theRepresentation/Association term is Code 35804PL, the Type term is CCT35806PL, the Type Name term is Code 35808PL, and the Length is from oneto six 35810PL. The ProductRelationshipTypeCode 35800PL may berestricted 35812PL.

For the listAgencyID 35814PL, the Category is Attribute 35816PL, theObject Class term is CodeListAgency 35818PL, the Property term isIdentification 35820PL, the Representation/Association term isIdentifier 35822PL, the Type term is xsd 35824PL, and the Type Name termis token 35826PL. The cardinality between the listAgencyID 35814PL andthe GDT ProductRelationshipTypeCode 35800PL is either zero or one35828PL.

For the listVersionID 35830PL, the Category is Attribute 35832PL, theObject Class term is CodeList 35834PL, the Property term is Version35836PL, the Representation/Association term is Identifier 35838PL, theType term is xsd 35840PL, and the Type Name term is token 35842PL. Thecardinality between the listVersionID 35830PL and the GDTProductRelationshipTypeCode 35800PL is either zero or one 35844PL.

For the listAgencySchemeID 35846PL, the Category is Attribute 35848PL,the Object Class term is CodeListAgency 35850PL, the Property term isScheme 35852PL, the Representation/Association term is Identifier35854PL, the Type term is xsd 35856PL, and the Type Name term is token35858PL. The cardinality between the listAgencySchemeID 35862PL and theGDT ProductRelationshipTypeCode 35800PL is either zero or one 35860PL.

For the listAgencySchemeAgencyID 35862PL, the Category is Attribute35864PL, the Object Class term is CodeListAgency 35866PL, the Propertyterm is Scheme 35868PL, the Representation/Association term isIdentifier 35870PL, the Type term is xsd 35872PL, and the Type Name termis token 35874PL. The cardinality between the listAgencySchemeAgencyID35862PL and the GDT ProductRelationshipTypeCode 35800PL is either zeroor one 35876PL.

In some variations, an extensible code list can be assigned to theProductRelationshipTypeCode 35800PL. Customers can change this codelist. In its unchanged state, the SAP code list may have, for example,the following attributes:

listID=“10033”

listAgencyID=“310”

listVersionID=Version of the relevant code list.

If a customer makes changes to the assigned code list, the valuesassigned to the attributes change as follows:

listAgencyID—ID of the customer (ID from DE 3055 if listed there)

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of the organization (taken from DE 3055)that manages the scheme of the listAgencySchemeID

As an example, the ProductRelationshipTypeCode 35800PL can be used inthe product master to represent the type of relationship between aproduct and other business entities. For example, a customer-specificcode semantics may be “Product->Competitor,” meaning a Relationship of aproduct with its competitors. An exemplary code list is shown asfollows: Code Name Description ACCESS Product Accessories Relationshipof a product with an accessory product PRDCPN Product CustomerRelationship of a product with customer-specific Product product dataPRDCTP Product Contenct Relationship of a product with a contentprovider Provider PRDMPN Product Relationship of a product withmanufacturer-specific Manufacturer product data PRDVND Product VendorRelationship of a product with vendor-specific product data PROREFProduct Reference Relationship of a material with a reference productfor Product an individual material SERVI Product Service Relationship ofa product with a service product SPARE Product Spare Part Relationshipof a product with a spare part

(hhhhhhhhhhhhhhhhhhhhhhhhhh) QuantityRatio

A GDT QuantityRatio 35800PM represents the relationship between twoquantities that have different quantity units. An example (Instance) ofthe GDT QuantityRatio 35800PM is: <QuantityRatio> <QuantityunitCode=”PCE”>4</Quantity> <CorrespondingQuantityunitCode=”KGM”>20</CorrespondingQuantity> <QuantityRatio>

The structure of GDT QuantityRatio 35800PM is depicted in FIG. 358PM.The QuantityRatio 35800PM includes a Quantity 35806PM element and aCorrespondingQuantity 35838PM element. For the GDT QuantityRatio35800PM, the Object Class term is 35802PM and theRepresentation/Association term is Details 35804PM.

The Quantity 35806PM includes an attribute UnitCode 35822PM. For theQuantity 35806PM, the Category is Element 35808PM, the Object Class termis QuantityRatio 35810PM, the Property term is Quantity 35812PM, theRepresentation/Association term is Quantity 35814PM, the Type term isGDT 35816PM, the Type Name term is Quantity 35818PM. The Cardinalitybetween the Quantity 35806PM and the QuantityRatio 35800PM is one35820PM. The Quantity 35806PM may be restricted 35821PM.

For the UnitCode 35822PM, the Category is Attribute 35824PM, the ObjectClass term is QuantityRatio 35826PM, the Property term is Unit 35828PM,the Representation/Association term is Code 35830PM, the Type term isGDT 35832PM, the Type Name term is MeasureUnitCode 35834PM. TheCardinality between the UnitCode 35822PM and the Quantity 35806PM is one35836PM.

The CorrespondingQuantity 35838PM includes an attribute UnitCode35854PM. For the CorrespondingQuantity 35838PM, the Category is Element35840PM, the Object Class term is QuantityRatio 35842PM, the Propertyterm is CorrespondingQuantity 35844PM, the Representation/Associationterm is Quantity 35846PM, the Type term is GDT 35848PM, the Type Nameterm is Quantity 35850PM. The Cardinality between theCorrespondingQuantity 35838PM and the QuantityRatio 35800PM is one35852PM. The Quantity 35806PM may be restricted 35853PM.

For the UnitCode 35854PM, the Category is Attribute 35856PM, the ObjectClass term is QuantityRatio 35858PM, the Property term is Unit 35860PM,the Representation/Association term is Code 35862PM, the Type term isGDT 35864PM, the Type Name term is MeasureUnitCode 35866PM. TheCardinality between the UnitCode 35854PM and the CorrespondingQuantity35838PM is one 35868PM.

In some variations, the Quantity may be an amount with unit of measure(such as the base unit of measure), and the CorrespondingQuantity may bea corresponding amount in an alternative unit of measure.

In some implementations, the GDT QuantityRatio 35800PM can specify howmany units in a unit of measure are equal to a number of units inanother unit of measure. For example, if a product has Piece (ISO: PCE)as its base unit of measure and the sales unit is kilograms (ISO: KGM),the following values may be possible:

-   -   4 pieces=20 kilograms    -   1 piece=5 kilograms

The attribute UnitCode can be declared as mandatory in the GDTQuantityRatio 35800PM and may be checked by the application because itis optional in the GDT Quantity, and restrictions of elementary GDTs incomplex GDTs are currently not supported by the repository.

(iiiiiiiiiiiiiiiiiiiiiiiiii) SalesCyclePhaseStepCode

A GDT SalesCyclePhaseStepCode 35800PN is the description of a step in asales cycle phase. The sales cycle of a product or service begins withthe recognition of an opportunity, that is with the possible salesopportunity, and ends with an order or rejection by the customer. Thesales cycle of an opportunity is made up of different phases, such asfor example, project identification, qualification, quote, and so on,and each phase is made up of different steps. A step is a task thatshould be carried out in a sales cycle phase. An example of the GDTSalesCyclePhaseStepCode 35800PN is:

<SalesCyclePhaseStepCode listAgencyID=310>1</SalesCyclePhaseStepCode>

The structure of GDT SalesCyclePhaseStepCode 35800PN is depicted in FIG.358PN. The GDT SalesCyclePhaseStepCode 35800PN includes attributeslistAgencyID 35814PN, listVersionID 35830PN, listAgencySchemeID 35846PN,and listAgencySchemeAgencyID 35862PN. For the GDTSalesCyclePhaseStepCode 35800PN, the Object Class term is Sales CyclePhase 35801PN, the Property term is Step 35802PN, theRepresentationl/Association term is Code 35806PN, the Type term is CCT35808PN, the Type Name term is Code 35810PN, and the Length is from oneto three 35810PN. The SalesCyclePhaseStepCode 35800PN may be restricted35812PN.

For the listAgencyID 35814PN, the Category is Attribute 35816PN, theObject Class term is CodeListAgency 35818PN, the Property term isIdentification 35820PN, the Representation/Association term isIdentifier 35822PN, the Type term is xsd 35824PN, and the Type Name termis token 35826PN. The cardinality between the listAgencyID 35814PN andthe GDT SalesCyclePhaseStepCode 35800PN is either zero or one 35828PN.

For the listVersionID 35830PN, the Category is Attribute 35832PN, theObject Class term is CodeList 35834PN, the Property term is Version35836PN, the Representation/Association term is Identifier 35838PN, theType term is xsd 35840PN, and the Type Name term is token 35842PN. Thecardinality between the listVersionID 35830PN and the GDTSalesCyclePhaseStepCode 35800PN is either zero or one 35844PN.

For the listAgencySchemeID 35846PN, the Category is Attribute 35848PN,the Object Class term is CodeListAgency 35850PN, the Property term isScheme 35852PN, the Representation/Association term is Identifier35854PN, the Type term is xsd 35856PN, and the Type Name term is token35858PN. The cardinality between the listAgencySchemeID 35862PN and theGDT SalesCyclePhaseStepCode 35800PN is either zero or one 35860PN.

For the listAgencySchemeAgencyID 35862PN, the Category is Attribute35864PN, the Object Class term is CodeListAgency 35866PN, the Propertyterm is Scheme 35868PN, the Representation/Association term isIdentifier 35870PN, the Type term is xsd 35872PN, and the Type Name termis token 35874PN. The cardinality between the listAgencySchemeAgencyID35862PN and the GDT SalesCyclePhaseStepCode 35800PN is either zero orone 35876PN.

In some variations, an extendable code list can be assigned to theSalesCyclePhaseStepCode. Customers may replace lists with their own. Inits unchanged state, the assigned code list has the followingattributes:

listID=10013

listAgencyID=“310”

listVersionID=Version of the relevant code list.

If an customer creates a code list, the attributes can be changed asfollows:

listAgencyID—ID of the customer (ID from DE 3055 if listed there)

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of the organization (taken from DE 3055)that manages the scheme of the listAgencySchemeID

In some examples, the GDT SalesCyclePhaseStepCode 35800PN can be usedprimarily in Presales in order to describe individual steps within asales cycle phase. For example, a customer-specific code semantics maybe Retrieve advertised biddings, which is used to determine publicbiddings of a customer or prospect.

In some implementations, the GDT SalesCyclePhaseStepCode 35800PN is usedprimarily for modeling business objects. It defines its own view on asales process, and should therefore not be used in electronic messageexchange with external parties. An example of an assigned code list maybe: Code Name Description 1 Gather In this step, information regardingthe customer or prospect is Customer gathered. Information 2 IdentifyEntry In this step, the customer or prospect's contact person is Pointidentified. 3 Obtain and In this step, a visit to the customer orprospect is arranged and Prepare Visit carried out. 4 Initial Needs Inthis step, the initial needs are analyzed. Analysis 5 Clarify In thisstep, the feasibility is clarified internally. Feasibility 6 Identify Inthis step, the customer's time schedule is identified. Customer's TimeSchedule 7 Understand In this step, the customer's decision makers areidentified. Decision- Making Process 8 Define Selling In this step, thesales team is defined. Team 9 Make go/no-go In this step, a Go/No-Godecision is made. decision 10 Define Strategy In this step, the strategyand action plan is defined. and Action Plan 11 Align Selling In thisstep, the sales team is assigned to the customer's project Team team. 12Establish In this step, contact is established with all relevantinfluential Relationship members. with all Influential Members 13Identify In this step, individual goals and decision criteria isidentified. Individual Goals and Decision Criteria

(jjjjjjjjjjjjjjjjjjjjjjjjjj) SupplyPlanningAreaID

A GDT SupplyPlanningAreaID 35800PO is a unique identifier of aSupplyPlanningArea. An area in which planning is executed separately toguarantee the availability of products on time. To achieve this, theSupplyPlanningArea groups requirements, stocks, and further requirementcoverage elements of a Location for consumption in the net requirementscalculation in material requirements planning. An example of the GDTSupplyPlanningAreaID 35800PO is:

<SupplyPlanningAreaID>Hamburg</SupplyPlanningAreaID>

<SupplyPlanningAreaID>spare parts</SupplyPlanningAreaID>

The structure of GDT SupplyPlanningAreaID 35800PO is depicted in Figure358PO. For the GDT SupplyPlanningAreaID 35800PO, the Object Class termis Supply Planning Area 35802PO, the Property term is Identification35804PO, the Representation/Association term is Identifier 35806PO, theType term is CCT 35808PO, the Type Name term is Identifier 35810PO, andthe Length is from one to twenty 35812PO. The GDT SupplyPlanningAreaID35800PO may be restricted 35814PO.

(kkkkkkkkkkkkkkkkkkkkkkkkkk) AutomaticNumberingindicator

An AutomaticNumberingIndicator specifies whether or not identifiers areassigned automatically. In some variations, theAutomaticNumberingIndicator may only be used in business objects and/ortheir replication messages. In other variations, theAutomaticNumberingIndicator is used mainly for numerical oralphanumerical identifiers;

The AutomaticNumberingIndicator can be used to control whether or notidentifiers (such as document numbers or product numbers) are assignedautomatically. For example, in some Product master, product categoryidentifiers can be assigned automatically.

(llllllllllllllllllllllllll) ChartOfAccountsItemDescription

A ChartOfAccountsItemDescription is a description of an item in thechart of accounts. A chart of accounts item groups together assets,payables, stockholders' equity, revenues, or expenses and is used toenter and represent for accounting purposes any changes to these valuesresulting from business transactions.

(mmmmmmmmmmmmmmmmmmmmmmmmmm) ClassificationSystemName

A ClassificationSystemName is a word, or a combination of wordsdescribing a classification system.

(nnnnnnnnnnnnnnnnnnnnnnnnnn) DepartmentName

A DepartmentName is a name of a department.

(oooooooooooooooooooooooooo) GroupedIndicator

A GroupedIndicator is the indicator whether the price component shouldbe grouped with the corresponding price component of the other items inthe same business transaction document and therefore processed together,or not. In some variations, the GroupedIndicator may indicate whethersomething is grouped or not.

(pppppppppppppppppppppppppp) Inheritedlndicator

An InheritedIndicator is used to show whether or not an object inheritsthe characteristics or functions of another object. For example, in aProduct master, the product attribute groups can be assigned to productcategories, which in turn are arranged hierarchically in a productcategory hierarchy.

Each product can be assigned in a product category hierarchy to a singleproduct category whose attribute groups it directly inherits. The parentproduct categories that are in the product category hierarchy tree andtheir attribute groups may then be assigned to the product throughinheritance. As an example, the InheritedIndicator may show whetherproduct categories and their product attributes groups are inherited ornot.

In some implementations, the InheritedIndicator is only permitted as anelement and not as an attribute of a GDT. In the context of use, adescription must be given as to which objects or functions theInheritedIndicator refers.

In some implementations, a DefaultIndicator specifies whether or notsomething has been designated as a default. An InheritedIndicatorspecifies whether or not an object has been inherited from anotherobject. By object, we generally mean a business object (such as aproduct category).

(qqqqqqqqqqqqqqqqqqqqqqqqqq) MessageFromName

A MessageFromName is a name of an object that is assigned to the sender.

(rrrrrrrrrrrrrrrrrrrrrrrrrr) MobilePhoneNumberIndicator

A MobilePhoneNumberIndicator specifies whether a telephone number is amobile number or not.

(ssssssssssssssssssssssssss) POBoxIndicator

A POBoxIndicator specifies whether there is a PO Box address or not.This indicator is necessary if a PO Box number is not specified within aPO Box address.

(tttttttttttttttttttttttttt) ProductConfigurableIndicator

A configurable product is used when a lot of variants can exist due tothe diversity of combinations that are possible in the productcharacteristics. All the characteristics of a particular product arecombined in a variant piece list. For example, product characteristicsfor a particular vehicle type can be engine capacity, gearbox type,color, upholstery, type of glass, sunroof, radio model, number of wingmirrors, ashtray(s).

(uuuuuuuuuuuuuuuuuuuuuuuuuu) PropertyParametricSearchableIndicator

A ProductConfigurableIndicator specifies whether or not a product can beconfigured. In some variations, thePropertyParametricSearchableIndicator is used in the context of theproperty definition.

(vvvvvvvvvvvvvvvvvvvvvvvvvv) ServicePointIndicator

A ServicePointIndicator specifies whether something is a service pointor not.

(wwwwwwwwwwwwwwwwwwwwwwwwww) ChequeLot1ID

A GDT ChequeLot1ID 35800PP is an identifier for a check lot. A check lotdescribes a restricted quantity of unissued outgoing checks for a housebank account by a number interval. An example (Instance) of the GDTChequeLot1ID 35800PP is:

<ChequeLot1ID>Lot1</ChequeLot1ID>

The structure of GDT ChequeLot1ID 35800PP is depicted in FIG. 358PP. Forthe GDT ChequeLot1ID 35800PP, the Object Class term is Check Lot35802PP, the Property term is Identification 35804PP, theRepresentation/Association term is Identifier 35806PP, the Type term isCCT 35808PP, the Type Name term is Identifier 35810PP, and the Length isfrom one to eight 35812PP. The GDT ChequeLot1ID 35800PP may berestricted 35814PP.

In some embodiments, the GDT ChequeLot1ID 35800PP is unique per housebank account. For example, the GDT ChequeLot1ID 35800PQ can be stored inthe field STAPL of table PCEC in an SAP R/3 system provided by the SAPAG in Waldorf, Germany.

(xxxxxxxxxxxxxxxxxxxxxxxxxx)EnterpriseAccommodationReimbursementExpenseReporterGroupCode

A GDT EnterpriseAccommodationReimbursementExpenseReporterGroupCode35800PQ is the coded representation of a group of expense reporters towhom the same company-specific expense regulations apply regarding thereimbursement of accommodation expenses. An Example (Instance) of theGDT EnterpriseAccommodationReimbursementExpenseReporterGroupCode 35800PQis:

<EnterpriseAccommodationReimbursementExpenseReporterGroupCode>1</EnterpriseAccommodationReimbursementExpenseReporterGroupCode>

The structure of GDTEnterpriseAccommodationReimbursementExpenseReporterGroupCode 35800PQ isdepicted in FIG. 358PQ. For the GDTEnterpriseAccommodationReimbursementExpenseReporterGroupCode 35800PQ,the Object Class term is Enterprise Accommodation Reimbursement ExpenseReporter Group 35802PQ, the Representation/Association term is Code35804PQ, the Type term is CCT 35806PQ, the Type Name term is Code35808PQ, and the Length is from one to two 35810PQ. The GDTEnterpriseAccommodationReimbursementExpenseReporterGroupCode 35800PQ maybe restricted 35812PQ.

In some embodiments, the value range of the GDTEnterpriseAccommodationReimbursementExpenseReporterGroupCode 35800PQ(e.g., listID=“10267”) may include a customer-specific code list.

In some implementations, the GDTEnterpriseAccommodationReimbursementExpenseReporterGroupCode 35800PQ cancurrently only be used in BOs.

As an example, the GDTEnterpriseAccommodationReimbursementExpenseReporterGroupCodes 35800PQmay be an Extended Management Board Members of the extended managementboard that includes Senior Executives and Salaried Employees.

For the GDT EnterpriseAccommodationReimbursementExpenseReporterGroupCode35800PQ, there can be a correspondingStatutoryAccommodationReimbursementExpenseReporterGroupCode as the codedrepresentation of a group of expense reporters to whom the samestatutory or contractual expense regulations apply regarding thereimbursement of accommodation expenses.

(yyyyyyyyyyyyyyyyyyyyyyyyyy) HouseID

A GDT HouseID 35800PR is a unique identifier of a building or buildingsection within a street by means of a house number. An example of GDTHouseID 35800PR is:

<HouseID>16</HouseID>

The structure of GDT HouseID 35800PR is depicted in FIG. 358PR. For theGDT HouseID 35800PR, the Object Class is House 35802PR, the Property isIdentification 35804PR, the Representation/Association is Identifier35806PR, the Type is CCT 35808PR, the Type Name is Identifier 35810PR,and the Length is from one to ten 35812PR. The remark 35814PR shows thatthe GDT HouseID 35800PR may be restricted.

The value list of the HouseID 35800PR is unique for each street. Thestreet is known from the context. The HouseID 35800PR is used in thepostal address. The following dictionary objects are assigned to thisGDT in mySAP systems: Data element: BU_HSNM1 and Domain: TEXT10.

(zzzzzzzzzzzzzzzzzzzzzzzzzz) GeneralLedgerAccountReference

A GDT GeneralLedgerAccountTypeCode 35800PS is the coded representationof the type of a general ledger account. A general ledger account is astructure for storing changes in value relating to assets, payables,stockholders' equity, revenues, or expenses of a company. A generalledger account relates to exactly one item in a chart of accounts.Examples of general ledger accounts are: trade receivables or cumulateddepreciation on buildings. An example of GDTGeneralLedgerAccountTypeCode 35800PS is:

<GeneralLedgerAccountTypeCode>10</GeneralLedgerAccountTypeCode>

The structure of GDT GeneralLedgerAccountTypeCode 35800PS is depicted inFIG. 358PS. For the GDT GeneralLedgerAccountTypeCode 35800PS, the ObjectClass is General Ledger Account 35802CPS, the Property is Type 35804PS,the Representation/Association is Code 35806PS, the Type is CCT 35808PS,the Type Name is Code 35810PS, and the Length is from one to six 35812PS. The remark 35814PS shows that the GDT GeneralLedgerAccountTypeCode35800PS may be restricted.

The GeneralLedgerAccountTypeCode is a customer-specific code list. Theattribute “listID” is filled implicitly with “10110”. The GDTGeneralLedgerAccountTypeCode 35800PS is currently used in businessobjects. Examples of the possible semantics of the codes are: (FixedAsset)—Account for fixed assets, (Inventory)—Account for materialinventories, (Loans taken)—Account for loans taken, and (OverheadCosts)—Account for overhead costs

The GDT GeneralLedgerAccountTypeCode 35800PS may be used to subdividethe general ledger, such as into fixed asset accounts, accounts formaterial inventories, or accounts for overhead costs. The subdivision ismore refined that the division into balance sheet accounts and accountsfor the profit and loss statement. A GDT GeneralLedgerAccountTypeCode35800PS can be used to derive whether an account is an assets account ora liability account in the balance sheet or whether it is an expenseaccount or a revenue account in the profit and loss statement.

(aaaaaaaaaaaaaaaaaaaaaaaaaaa) InventoryMovementDirectionCode

A GDT InventoryMovementDirectionCode 35800PT is a coded representationof the direction of an inventory movement (receipt, issue). For example,inventory may be the quantity of all the materials in a certain locationincluding the material allocations at this location. An example of GDTInventoryMovementDirectionCode 35800PT is:

<InventoryMovementDirectionCode>1</InventoryMovementDirectionCode>

The structure of GDT InventoryMovementDirectionCode 35800PT is depictedin FIG. 358PT. For the GDT InventoryMovementDirectionCode 35800PT, theObject Class is Inventory Movement 35804PT, the Property is Direction35806PT, the Representation/Association is Code 35808PT, the Type is CCT35810PT, the Type Name is Code 35812PT, and the Length is one 35814PT.The remark 35818PT shows that the GDT InventoryMovementDirectionCode35800PT may be restricted.

The value range of the InventoryMovementDirectionCode corresponds to thevalues of the code 4501 (“Inventory Movement Direction Code”) of theEDIFACT code list D04B. The data type GDT InventoryMovementDirectionCode35800PT may use the following codes: 1 (i.e., an inventory issue is thequantitative change of the total inventory caused by the withdrawal of apartial inventory.), 2 (i.e., an inventory receipt is the quantitativechange of the total inventory caused by the receipt of inventory).

(bbbbbbbbbbbbbbbbbbbbbbbbbbb) ProfitCentreID

A GDT ProfitCentreID 35800PU is a unique identifier for a profit center.The following are examples of GDT ProfitCentreID 35800PU. ID of profitcenter “SALES_(—)01” “in Business-System “FIN_(—)001”:   <ProfitCentreIDschemeID=”ProfitCentreID”   schemeAgencyID=”FIN_001”>   0001SALES_01  </ProfitCentreID>   GUID of organizational center's profit center fromMOM:   <ProfitCentreID schemeID=”OrganisationalCentreID”schemeAgencyID=”MOM_001”>   D2E40E4157AC6511E10000000A155064  </ProfitCentreID >

The structure of GDT ProfitCentreID 35800PU is depicted in FIG. 358PU.For the GDT ProfitCentreID 35800PU, the Object Class is ProfitCentre35801PU, the Property is Identification 35803PU, theRepresentation/Association is Identifier 35804PU, the Type is CCT35805PU, the Type Name is Identifier 35806PU, and the Length is from oneto thirty-two 35807PU. The remark 35809PU shows that the GDTProfitCentreID 35800PU may be restricted.

For the SchemeID 35810PU, the Category is Attribute (A) 35811PU, theObject Class is IdentificationScheme 35812PU, the Property isIdentification 35813PU, the Representation/Association is Identifier35814PU, the Type is XSD 35815PU, the Type Name is Token 35816PU, theLength is sixty 35817PU, and the Cardinality is zero or one 35818PU.

For the SchemeAgencyID 35820PU, the Category is Attribute (A) 35821PU,the Object Class is IdentificationScheme-Agency 35822PU, the Property isIdentification 35823PU, the Representation/Association is Identifier35824PU, the Type is XSD 35825PU, the Type Name is Token 35826PU, theLength is sixty 35827PU, and the Cardinality is zero or one 35828PU.

The ProfitCentreGroupID attributes are filled as follows: schemeID isthe “ProfitCentreID” for an ID of a profit center or the“OrganisationalCentreID” for a GUID of on organizational center withprofit responsibility of a MOM, schemeAgencyID is the business system inwhich the ID was assigned. In some ERP implementations, the ID of aprofit centre includes a cost centre's number range (4 characters) andprofit centre (10 characters).

(ccccccccccccccccccccccccccc)StatutoryAccommodationReimbursementExpenseReporterGroupCode

A GDT StatutoryAccommodationReimbursementExpenseReporterGroupCode35800PV is a coded representation of a group of expense reporters towhom the same statutory or contractual expense regulations applyregarding the reimbursement of accommodation expenses. An example of GDTStatutoryAccommodationReimbursementExpenseReporterGroupCode 35800PV is:

<StatutoryAccommodationReimbursementExpenseReporterGroupCode>1</StatutoryAccommodationReimbursementExpenseReporterGroupCode>

The structure of GDTStatutoryAccommodationReimbursementExpenseReporterGroupCode 35800PV isdepicted in FIG. 358PV. For the GDTStatutoryAccommodationReimbursementExpenseReporterGroupCode 35800PV, theObject Class isStatutory_AccommodationReimbursement_ExpenseReporterGroup 35804PV, theRepresentation/Association is Code 35808PV, the Type is CCT 35810PV, theType Name is Code 35812PV, and the Length is from one to two 35814PV.The remark 35818PV shows that the GDTStatutoryAccommodationReimbursementExpenseReporterGroupCode 35800PV maybe restricted.

The value range ofStatutoryAccommodationReimbursementExpenseReporterGroupCode consists ofa customer-specific code list. In some implementations,StatutoryAccommodationReimbursementExpenseReporterGroupCode can only beused in Business Objects. Examples ofStatutoryAccommodationReimbursementExpenseReporterGroupCodes are thefour employee groups of the Italian banking collective agreement with aper diem that varies according to the employee hierarchy level: 1—areaprofessionale (Employee hierarchy level 1), 2—area professionale 1. e 2.livello retributivo (Employee hierarchy level 2), 3—area professionale e2. area professionale 3. livello retributivo (Employee hierarchy level3), 4—Quadri Direttivi 1.-4. livello (Employee hierarchy level 4). ForStatutoryAccommodationReimbursementExpenseReporterGroupCode there is acorrespondingEnterpriseAccommodationReimbursementExpenseReporterGroupCode as thecoded representation of a group of expense reporters to whom the samecompany-specific expense regulations apply regarding the reimbursementof accommodation expenses.

(ddddddddddddddddddddddddddd) InspectionSampleTypeCode

A GDT InspectionSampleTypeCode 35800PW is a coded representation of thetype of a sample in the context of an inspection. An example of GDTInspectionSampleTypeCode 35800PW is:

<InspectionS ampleTypeCode>1</InspectionSampleTypeCode>

The structure of GDT InspectionSampleTypeCode 35800PW is depicted inFIG. 358PW. For the GDT InspectionSampleTypeCode 35800PW, the ObjectClass is InspectionSampleType 35801PW, the Representation/Association isCode 35804PW, the Type is XSD 35805PW, the Type Name is Token 35806PW,and the Length is from one to three 35807PW. The remark 35809PW showsthat the GDT InspectionSampleTypeCode 35800PW may be restricted.

For the ListAgencyID 35810PW, the Category is Attribute (A) 35811PW, theObject Class is CodeListAgency 35812PW, the Property is Identification35813PW, the Representation/Association is Identifier 35814PW, the Typeis XSD 35815PW, the Type Name is Token 35816PW, and the Cardinality iszero or one 35818PW.

For the ListVersionID 35820PW, the Category is Attribute (A) 35821PW,the Object Class is CodeList 35822PW, the Property is Version 35823PW,the Representation/Association is Identifier 35824PW, the Type is XSD35825PW, the Type Name is Token 35826PW, and the Cardinality is zero orone 35828PW.

For the ListAgency-SchemeID 35830PW, the Category is Attribute (A)35831PW, the Object Class is CodeListAgency 35832PW, the Property isScheme 35833PW, the Representation/Association is Identifier 35834PW,the Type is XSD 35835PW, the Type Name is Token 35836PW, and theCardinality is zero or one 35838PW.

For the ListAgency-SchemeAgencyID 35840PW, the Category is Attribute (A)35841PW, the Object Class is CodeListAgency 35842PW, the Property isSchemeAgency 35843PW, the Representation/Association is Identifier35844PW, the Type is XSD 35845PW, the Type Name is Token 35846PW, andthe Cardinality is zero or one 35848PW.

An extendable code list is assigned to the code. Customers may replacelists with their own. In its unchanged state, the code list has thefollowing attributes: listID of “10405”, listAgencyID of “310”,listVersionID is the version of the relevant code list. If a customercreates a code list, the attributes change as follows: listAgencyID isthe ID of the customer (ID from DE 3055 if listed there), listVersionIDis assigned and managed by the customer, listAgencySchemeID is the ID ofthe scheme if the listAgencyID is not taken from DE 3055,listAgencySchemeAgencyID is the ID of the organization (taken from DE3055) that manages the scheme of the listAgencySchemeID. TheInspectionSampleTypeCode allocates in which process a sample for anobject is to be inspected. For example, a particular sample type couldrepresent samples that are taken from a delivered material in a goodsreceipt. The data type GDT InspectionSampleTypeCode 35800PW may use thefollowing codes: 1 (i.e., Sample that is taken during the goods receiptprocess), 2 (i.e., Sample that is taken during the goods issue process),3 (i.e., Sample of a material from a customer complaint).

(eeeeeeeeeeeeeeeeeeeeeeeeeee) QualityInspectionSample

A QualityInspectionSample is an optional, planned element for thesegmentation of a quality inspection in discrete units.

(fffffffffffffffffffffffffff) QualityInspectionSampleID

A QualityInspectionSampleID is an indentifier for a quality inspectionsample. For example, a quality inspection sample may be an optional,planned element for the segmentation of a quality inspection in discreteunits.

(ggggggggggggggggggggggggggg) QualityInspectionStatusCode

A QualityInspectionStatusCode is a coded representation of a qualityinspection's status. For example, a quality inspection may be a documentthat describes the execution of an inspection for a particular material,and that is used to record this inspection.

(hhhhhhhhhhhhhhhhhhhhhhhhhhh) QualityInspectionSubset

A QualityInspectionSubset is a subset of an entirety, which is processedin a quality inspection. For example, a quality inspection may be adocument that describes the execution of an inspection for a particularmaterial, and that is used to record this inspection.

(iiiiiiiiiiiiiiiiiiiiiiiiiii) InspectionContainerTypeCode

A GDT InspectionContainerTypeCode 35800PX is the coded representation ofthe container in which the inspection sample is transported and storedfor inspection purposes. An example of the GDTInspectionContainerTypeCode 35800PX is:

<InspectionContainerTypeCode>1</InspectionContainerTypeCode>

The structure of GDT InspectionContainerTypeCode 35800PX is depicted inFIG. 358PX. The GDT InspectionContainerTypeCode 35800PX includesattributes listAgencyID 35814PX, listVersionID 35830PX,listAgencySchemeID 35846PX, and listAgencySchemeAgencyID 35862PX. Forthe GDT InspectionContainerTypeCode 35800PX, the Object Class term isInspection 35802PX, the Representation/Association term is Code 35804PX,the Type term is xsd 35806PX, the Type term is token 35808PX, the TypeName term is Code 35810PX, and the Length is from one to fifteen35810PX. The InspectionContainerTypeCode 35800PX may be restricted35812PX.

For the listAgencyID 35814PX, the Category is Attribute 35816PX, theObject Class term is CodeListAgency 35818PX, the Property term isIdentification 35820PX, the Representation/Association term isIdentifier 35822PX, the Type term is xsd 35824PX, and the Type Name termis token 35826PX. The cardinality between the listAgencyID 35814PX andthe GDT InspectionContainerTypeCode 35800PX is either zero or one35828PX.

For the listVersionID 35830PX, the Category is Attribute 35832PX, theObject Class term is CodeList 35834PX, the Property term is Version35836PX, the Representation/Association term is Identifier 35838PX, theType term is xsd 35840PX, and the Type Name term is token 35842PX. Thecardinality between the listVersionID 35830PX and the GDTInspectionContainerTypeCode 35800PX is either zero or one 35844PX.

For the listAgencySchemeID 35846PX, the Category is Attribute 35848PX,the Object Class term is CodeListAgency 35850PX, the Property term isScheme 35852PX, the Representation/Association term is Identifier35854PX, the Type term is xsd 35856PX, and the Type Name term is token35858PX. The cardinality between the listAgencySchemeID 35862PX and theGDT InspectionContainerTypeCode 35800PX is either zero or one 35860PX.

For the listAgencySchemeAgencyID 35862PX, the Category is Attribute35864PX, the Object Class term is CodeListAgency 35866PX, the Propertyterm is Scheme 35868PX, the Representation/Association term isIdentifier 35870PX, the Type term is xsd 35872PX, and the Type Name termis token 35874PX. The cardinality between the listAgencySchemeAgencyID35862PX and the GDT InspectionContainerTypeCode 35800PX is either zeroor one 35876PX.

In some embodiments, a customer-specific code list is assigned to theCode. A customer can define the codes in the code list. As an example,attributes of a Code may be assigned values as follows:

listID=“10402”

listAgencyID—ID of the customer (ID from DE 3055 if listed there)

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of the organization (taken from DE 3055)that manages the scheme of the listAgencySchemeID

The GDT InspectionContainerTypeCode 35800PX can, for example, be used todescribe transport containers for samples in the context of a materialinspection.

(jjjjjjjjjjjjjjjjjjjjjjjjjjj) InspectionDecisionCode

A GDT InspectionDecisionCode 35800PY is the coded representation of thedecision that is made as part of an inspection regarding the acceptanceor rejection of the inspected object. An example of the GDTInspectionDecisionCode 35800PY is:

<InspectionDecisionCode>1</InspectionDecisionCode>

The structure of GDT InspectionDecisionCode 35800PY is depicted in FIG.358PY. The GDT InspectionDecisionCode 35800PY includes attributeslistAgencyID 35814PY, listVersionID 35830PY, listAgencySchemeID 35846PY,and listAgencySchemeAgencyID 35862PY. For the GDT InspectionDecisionCode35800PY, the Object Class term is Inspection Decision 35802PY, theRepresentation/Association term is Code 35804PY, the Type term is xsd35806PY, the Type term is token 35808PY, the Type Name term is Code35810PY, and the Length is from one to fifteen 35810PY. TheInspectionDecisionCode 35800PY may be restricted 35812PY.

For the listAgencyID 35814PY, the Category is Attribute 35816PY, theObject Class term is CodeListAgency 35818PY, the Property term isIdentification 35820PY, the Representation/Association term isIdentifier 35822PY, the Type term is xsd 35824PY, and the Type Name termis token 35826PY. The cardinality between the listAgencyID 35814PY andthe GDT InspectionDecisionCode 35800PY is either zero or one 35828PY.

For the listVersionID 35830PY, the Category is Attribute 35832PY, theObject Class term is CodeList 35834PY, the Property term is Version35836PY, the Representation/Association term is Identifier 35838PY, theType term is xsd 35840PY, and the Type Name term is token 35842PY. Thecardinality between the listVersionID 35830PY and the GDTInspectionDecisionCode 35800PY is either zero or one 35844PY.

For the listAgencySchemeID 35846PY, the Category is Attribute 35848PY,the Object Class term is CodeListAgency 35850PY, the Property term isScheme 35852PY, the Representation/Association term is Identifier35854PY, the Type term is xsd 35856PY, and the Type Name term is token35858PY. The cardinality between the listAgencySchemeID 35862PY and theGDT InspectionDecisionCode 35800PY is either zero or one 35860PY.

For the listAgencySchemeAgencyID 35862PY, the Category is Attribute35864PY, the Object Class term is CodeListAgency 35866PY, the Propertyterm is Scheme 35868PY, the Representation/Association term isIdentifier 35870PY, the Type term is xsd 35872PY, and the Type Name termis token 35874PY. The cardinality between the listAgencySchemeAgencyID35862PY and the GDT InspectionDecisionCode 35800PY is either zero or one35876PY.

In some embodiments, a customer-specific code list is assigned to theCode. A customer can define the codes in the code list. As an example,attributes of a Code are assigned values as follows:

listID=“10403”

listAgencyID—ID of the customer (ID from DE 3055 if listed there)

listVersionID—Assigned and managed by the customer

listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055

listAgencySchemeAgencyID—ID of the organization (taken from DE 3055)that manages the scheme of the listAgencySchemeID

The InspectionDecisionCode 35800PY can, for example, be used in thecontext of a material inspection. This code is used to document thedecision about whether the inspected material is accepted or rejectedfor the further production process. Some examples of customer-specificcode semantics are “OK,” meaning Accepted, “OK with Restrictions,”meaning Accepted with restrictions, and “Not OK,” meaning Rejected,material should not be used.

(kkkkkkkkkkkkkkkkkkkkkkkkkkk) InspectionDecisionCodeListID

A GDT InspectionDecisionCodeListID 35800PZ is an identifier for a listof codes that are used to valuate the inspection object. AnInspectionDecisionCodeList is a list of codes that are valid for adecision in an inspection regarding the acceptance or rejection of thein-spected object. An example of the GDT InspectionDecisionCodeListID35800PZ is:

<InspectionDecisionCodeListID>123456789012345</InspectionDecisionCodeListID>

The structure of GDT InspectionDecisionCodeListID 35800PZ is depicted inFIG. 358PZ. The GDT InspectionDecisionCodeListID 35800PZ includesattributes SchemeID 35816PZ and SchemeAgencyID 35834PZ. For the GDTInspectionDecisionCodeListID 35800PZ, the Object Class term isInspection Decision Code List 35802PZ, the Property term isIdentification 35804PZ, the Representation/Association term isIdentifier 35806PZ, the Type term is CCT 35808PZ, the Type Name term isIdentifier 35810PZ, the TypeName term is Identifier 35012PZ, and theLength is from one to fifteen 35812PZ. The GDTInspectionDecisionCodeListID 35800PZ may be restricted 35814PZ.

For the schemeID 35816PZ, the Category is Attribute 35818PZ, the ObjectClass term is IdentificationScheme 35820PZ, the Property term isIdentification 35822PZ, the Representation/Association term isIdentifier 35824PZ, the Type term is xsd 35826PZ, and the Type Name termis Token 35828PZ, and the Length is from one to sixty 35830PZ. Thecardinality between the schemeID 35816PZ and the GDTInspectionDecisionCodeListID 35800PZ is either zero or one 35832PZ.

For the SchemeAgencyID 35834PZ, the Category is Attribute 35836PZ, theObject Class term is IdentificationScheme Agency 35838PZ, the Propertyterm is Identification 35840PZ, the Representation/Association term isIdentifier 35842PZ, the Type term is xsd 35844PZ, and the Type Name termis Token 35846PZ, and the Length is from one to sixty 35848PZ. Thecardinality between the SchemeAgencyID 35834PZ and the GDTInspectionDecisionCodeListID 35800PZ is either zero or one 35850PZ.

In some embodiments, the attributes of InspectionDecisionCodeListID maybe filled as follows:

schemeID=InspectionDecisionCodeList<Qualifier>ID

schemeAgencyID: Business system in which the identifier was assigned.

The GDT InspectionDecisionCodeListID 35800PZ can identify a list ofdecision codes in a material inspection.

(lllllllllllllllllllllllllll) InspectionSampleCategoryCode

The GDT InspectionSampleCategoryCode 35800QA is the coded representationof the category of a sample in the context of an inspection. An exampleof GDT InspectionSampleCategoryCode 35800QA is:

<InspectionSampleCategoryCode>1</InspectionSampleCategoryCode>

The structure of GDT InspectionSampleCategoryCode 35800QA is depicted inFIG. 358QA. For the GDT InspectionSampleCategoryCode 35800QA, the Objectclass is InsepctionSampleCategory 35802QA, theRepresentation/Association is Code 35804QA, the Type is xsd 35806QA, theType Name is Token 35808QA and the Length is from one to three 35810QA.The remark 35812QA shows that GDT InspectionSampleCategoryCode 35800QAcan be restricted. The GDT InspectionSampleCategoryCode 35800QA includesan attribute listVersionID 35814QA. For listVersionID 35814QA, theCategory is A 35816QA, the Object Class is CodeList 35818QA, theProperty is Version 35820QA, the Representation/Association isIdentifier 35822QA, the Type is xsd 35824QA, the Type Name is Token35826QA and the cardinality is from zero to one 35828QA.

One fixed SAP code list has been assigned to the code. The attributesare as follows:

listID=“10404,” listAgencyID=“310,” and listVersionID=[Version of therelevant code list. The code list includes (1) Primary Sample—Samplethat is taken directly from the material to be examined, (2) PooledSample—Sample that consists of a mixture of at least two primarysamples, and (3) Reserve Sample—Sample that must be stored for aspecific time period for documentation purposes.

In the context of a material inspection, GDTInspectionSampleCategoryCode 35800QA can define whether a sample is aprimary sample, pooled sample, or reserve sample. In the SAP system thatruns the QIE, InspectionSampleCategoryCode is represented by thefollowing dictionary objects: Data element: QIE_TV_ELEM_SUB_CATEGORY andDomain: QIE_TV_ELEM_SUB_CATEGORY.

(mmmmmmmmmmmmmmmmmmmmmmmmmm) InspectionSampleTypeCode

The GDT InspectionSampleTypeCode 35800QB is the coded representation ofthe type of a sample in the context of an inspection. An example of GDTInspectionSampleTypeCode 35800QB is:

<InspectionSampleTypeCode>1</InspectionSampleTypeCode>

The structure of GDT InspectionSampleTypeCode 35800QB is depicted inFIG. 358QB. For the GDT InspectionSampleTypeCode 35800QB, the ObjectClass is InspectionSampleType 35801QB, the Representation/Association isCode 35802QB, the Type is xsd 35803QB, and the Type Name is Token35804QB. The remark 35806QB shows that GDT InspectionSampleTypeCode35800QB can be restricted.

The GDT InspectionSampleTypeCode 35800QB includes the followingattributes: listAgencyID 35807QB, listVersionID 35816QB,listAgencySchemeID 35826QB, and listAgencySchemeAgencyID 35836QB. ForlistAgencyID 35807QB, the Category is A 35808QB, the Object Class isCodeListAgency 35809QB, the Property is Identification 35810QB, theRepresentation/Association is Identifier 35811QB, the Type is xsd35812QB, the Type Name is Token 35813QB, and the cardinality is fromzero to one 35815QB. For listVersionID 35816QB, the Category is A35818QB, the Object Class is CodeList 35820QB, the Property is Version35821QB, the Representation/Association is Identifier 35822QB, the Typeis xsd 35823QB, the Type Name is Token 35824QB, and the cardinality isfrom zero to one 35825QB. For listAgencySchemeID 35826QB, the Categoryis A 35828QB, the Object Class is CodeListAgency 35830QB, the Propertyis Scheme 35831QB, the Representation/Association is Identifier 35832QB,the Type is xsd 35833QB, the Type Name is Token 35834QB, and thecardinality is from zero to one 35835QB. For listAgencySchemeAgencyID35836QB, the Category is A 35836QB, the Object Class is CodeListAgency35840QB, the Property is SchemeAgency 35841QB, theRepresentation/Association is Identifier 35842QB, the Type is xsd35843QB, the Type Name is Token 35844QB, and the cardinality is fromzero to one 35845QB.

An extendable SAP code list is assigned to the code. SAP customers mayreplace SAP lists with their own. In its unchanged state, the SAP codelist has the following attributes: listID=“10405,” listAgencyID=“310,”and listVersionID. If an SAP customer creates a code list, theattributes change as follows: listAgencyID—ID of the SAP customerlistVersionID—Assigned and managed by the SAP customer,listAgencySchemeID—ID of the scheme if the listAgencyID is not takenfrom DE 3055, and listAgencySchemeAgencyID—ID of the organization (takenfrom DE 3055) that manages the scheme of the listAgencySchemeID. The SAPcode list and its values are provided in “Appendix—Code List”. Semanticexamples of customer-specific codes are provided in the “Use” section.

The GDT InspectionSampleTypeCode 35800QB may allocate a process in whicha sample for an object is to be inspected. For example, a particularsample type could represent samples that are taken from a deliveredmaterial in a goods receipt.

The code list may have the following values: (1) Goods ReceiptSample—Sample that is taken during the goods receipt process, (2) GoodsIssue Sample—Sample that is taken during the goods issue process, or (3)Returns Sample—Sample of a material from a customer complaint.

(nnnnnnnnnnnnnnnnnnnnnnnnnnn) InspectionSubsetID

A GDT InspectionSubsetID 35800QC is a unique identification of a subsetin the context of an inspection. An example of GDT InspectionSubsetID35800QC is:

<InspectionSubsetID>Subset0001</InspectionSubsetID>

The structure of GDT InspectionSubsetID 35800QC is depicted in FIG.358QC. For the GDT InspectionSubsetID 35800QC, the Object Class isInspectionSubset 35801QC, the Property is Identification 35803QC, theRepresentation/Association is Identifier 35804QC, the Type is XSD35805QC, the Type Name is Token 35806QC, and the Length is from one tothirty-five 35807QC. The remark 35809QC shows that the GDTInspectionSubsetID 35800QC may be restricted.

For the SchemeID 35810QC, the Category is Attribute (A) 35811QC, theObject Class is IdentificationScheme 35812QC, the Property isIdentification 35813QC, the Representation/Association is Identifier35814QC, the Type is XSD 35815QC, the Type Name is Token 35816QC, theLength is from one to sixty 35817QC, and the Cardinality is zero or one35818QC.

For the SchemeAgencyID 35820QC, the Category is Attribute (A) 35821QC,the Object Class is IdentificationScheme-Agency 35822QC, the Property isIdentification 35823QC, the Representation/Association is Identifier35824QC, the Type is XSD 35825QC, the Type Name is Token 35826QC, theLength is from one to sixty 35827QC, and the Cardinality is zero or one35828QC.

The attributes of InspectionSubsetID are filled as follows: schemeID isthe InspectionSubset<Qualifier>ID, schemeAgencyID is the Business systemin which the identifier was assigned. In the context of a materialinspection, InspectionSubsetID can be used to identify a subset of thematerial that is to be inspected.

(ooooooooooooooooooooooooooo) InspectionSubsetTypeCode

A GDT InspectionSubsetTypeCode 35800QD is a coded representation of thetype of a subset in the context of an inspection. An example of GDTInspectionSubsetTypeCode 35800QD is:

<InspectionSubsetTypeCode>1</InspectionSubsetTypeCode>

The structure of GDT InspectionSubsetTypeCode 35800QD is depicted inFIG. 358QD. For the GDT InspectionSubsetTypeCode 35800QD, the ObjectClass is InspectionSubsetType 35801QD, the Representation/Association isCode 35804QD, the Type is XSD 35805QD, the Type Name is Token 35806QD,and the Length is from one to three 35807QD. The remark 35809QD showsthat the GDT InspectionSubsetTypeCode 35800QD may be restricted.

For the ListAgencyID 35810QD, the Category is Attribute (A) 35811QD, theObject Class is CodeListAgency 35812QD, the Property is Identification35813QD, the Representation/Association is Identifier 35814QD, the Typeis XSD 35815QD, the Type Name is Token 35816QD, and the Cardinality iszero or one 35818QD.

For the ListVersionID 35820QD, the Category is Attribute (A) 35821QD,the Object Class is CodeList 35822QD, the Property is Version 35823QD,the Representation/Association is Identifier 35824QD, the Type is XSD35825QD, the Type Name is Token 35826QD, and the Cardinality is zero orone 35828QD.

For the ListAgency-SchemeID 35830QD, the Category is Attribute (A)35831QD, the Object Class is CodeListAgency 35832QD, the Property isScheme 35833QD, the Representation/Association is Identifier 35834QD,the Type is XSD 35835QD, the Type Name is Token 35836QD, and theCardinality is zero or one 35838QD.

For ListAgency-SchemeAgencyID 35840QD, the Category is Attribute (A)35841QD, the Object Class is CodeListAgency 35842QD, the Property isSchemeAgency 35843QD, the Representation/Association is Identifier35844QD, the Type is XSD 35845QD, the Type Name is Token 35846QD, andthe Cardinality is zero or one 35848QD.

An extendable code list is assigned to the code. Customers may replacelists with their own. In its unchanged state, the code list has thefollowing attributes: llistID of “10406”, listAgencyID of “310”,listVersionID is the version of the relevant code list. If a customercreates a code list, the attributes change as follows: listAgencyID isthe ID of the customer (ID from DE 3055 if listed there), listVersionIDis assigned and managed by the customer, listAgencySchemeID is the ID ofthe scheme if the listAgencyID and is not taken from DE 3055,listAgencySchemeAgencyID is the ID of the organization (taken from DE3055) that manages the scheme of the listAgencySchemeID. TheInspectionSubsetTypeCode describes the process in which the inspectionquantity is to be divided into subsets and where this process takesplace. In the context of a material inspection, for example, subsets maybe formed in the goods receipt or goods issue processes. The data typeGDT InspectionSubsetTypeCode 35800QD may use the following codes: 1(i.e., Subsets are formed in the material inspection in the goodsreceipt process), 2 (i.e., Subsets are formed in the material inspectionin the goods issue process).

(ppppppppppppppppppppppppppp) InspectionTypeCode

A GDT InspectionTypeCode 35800QE is a coded representation of the typeof an inspection. An example of GDT InspectionTypeCode 35800QE is:

<InspectionTypeCode>1</InspectionTypeCode>

The structure of GDT InspectionTypeCode 35800QE is depicted in FIG.358QE. For the GDT InspectionTypeCode 35800QE, the Object Class isInspectionType 35801QE, the Representation/Association is Code 35804QE,the Type is XSD 35805QE, the Type Name is Token 35806QE, and the Lengthis from one to four 35807QE. The remark 35809QE shows that the GDTInspectionTypeCode 35800QE may be restricted.

For the ListAgencyID 35810QE, the Category is Attribute (A) 35811QE, theObject Class is CodeListAgency 35812QE, the Property is Identification35813QE, the Representation/Association is Identifier 35814QE, the Typeis XSD 35815QE, the Type Name is Token 35816QE, and the Cardinality iszero or one 35818QE.

For the ListVersionID 35820QE, the Category is Attribute (A) 35821QE,the Object Class is CodeList 35822QE, the Property is Version 35823QE,the Representation/Association is Identifier 35824QE, the Type is XSD35825QE, the Type Name is Token 35826QE, and the Cardinality is zero orone 35828QE.

For the ListAgency-SchemeID 35830QE, the Category is Attribute (A)35831QE, the Object Class is CodeListAgency 35832QE, the Property isScheme 35833QE, the Representation/Association is Identifier 35834QE,the Type is XSD 35835QE, the Type Name is Token 35836QE, and theCardinality is zero or one 35838QE.

For ListAgency-SchemeAgencyID 35840QE, the Category is Attribute (A)35841QE, the Object Class is CodeListAgency 35842QE, the Property isSchemeAgency 35843QE, the Representation/Association is Identifier35844QE, the Type is XSD 35845QE, the Type Name is Token 35846QE, andthe Cardinality is zero or one 35848QE.

An extendable code list is assigned to the code. Customers may replacelists with their own. In its unchanged state, the code list has thefollowing attributes: IlistID of “10407”, listAgencyID of “310”,listVersionID is the version of the relevant code list. If a customercreates a code list, the attributes change as follows: listAgencyID isthe ID of the customer (ID from DE 3055 if listed there), listVersionIDis assigned and managed by the customer, listAgencySchemeID is the ID ofthe scheme if the listAgencyID and is not taken from DE 3055,listAgencySchemeAgencyID is the ID of the organization (taken from DE3055) that manages the scheme of the listAgencySchemeID. The type of aninspection defines the process and the object for which inspectiondocuments can be created. This type could, for example, describe amaterial inspection in the goods receipt process. It is the centralcontrolling element of the inspection. The data type GDTInspectionTypeCode 35800QE may use the following codes: 1 (i.e.,Material inspection in goods receipt process), 2 (i.e., Inspection ofmaterial that a customer has complained about and that has beenreturned).

(qqqqqqqqqqqqqqqqqqqqqqqqqqq) CostCentreID

A GDT CostCentreID 35800QF is an identifier for a cost center. Forexample, CostCentre may be an organizational center that represents aclearly defined location at which costs arise, and for which costs areentered separately. The definition can be based on functionalrequirements, allocation criteria, physical location, and responsibilityfor costs. Examples of GDT CostCentreID 35800QF are:   <CostCentreIDschemeID=”CostCentreID”   schemeAgencyID=”FIN_001”>   0001BOARD  </CostCentreID>   <CostCentreID schemeID=”OrganisationalCentreID”schemeAgencyID=”MOM_001”>   D55B17417854D208E10000000A155064  </CostCentreID>

The structure of GDT CostCentreID 35800QF is depicted in FIG. 358QF. Forthe GDT CostCentreID 35800QF, the Object Class is CostCentre 35801QF,the Property is Identification 35803QF, the Representation/Associationis Identifier 35804QF, the Type is CCT 35805QF, the Type Name isIdentifier 35806QF, and the Length is from one to thirty-two 35807QF.The remark 35809QF shows that the GDT CostCentreID 35800QF may berestricted.

For the SchemeID 35810QF, the Category is Attribute (A) 35811QF, theObject Class is IdentificationScheme 35812QF, the Property isIdentification 35813QF, the Representation/Association is Identifier35814QF, the Type is XSD 35815QF, the Type Name is Token 35816QF, theLength is sixty 35817QF, and the Cardinality is zero or one 35818QF.

For the SchemeAgencyID 35820QF, the Category is Attribute (A) 35821QF,the Object Class is IdentificationScheme-Agency 35822QF, the Property isIdentification 35823QF, the Representation/Association is Identifier35824QF, the Type is XSD 35825QF, the Type Name is Token 35826QF, theLength is sixty 35827QF, and the Cardinality is zero or one 35828QF.

(rrrrrrrrrrrrrrrrrrrrrrrrrrrr) TaxDeclarationKeyNumberTypeCode

A GDT TaxDeclarationKeyNumberTypeCode 35800QG is a coded representationof a tax declaration key number type. For example, a tax declaration keynumber may be a criterion of the type of entry in a tax report given bytax authorities. An example of GDT TaxDeclarationKeyNumberTypeCode35800QG is: <TaxDeclarationKeyNumberTypeCode listID=”20xyz.1”listVersionID=”200401”> 61 </TaxDeclarationKeyNumberTypeCode>

The structure of GDT TaxDeclarationKeyNumberTypeCode 35800QG is depictedin FIG. 358QG. For the GDT TaxDeclarationKeyNumberTypeCode 35800QG, theCategory is Element (E) 35802QG, the Object Class is Tax Declaration35801QG, the Property is Key Number Type 35803QG, theRepresentation/Association is Code 35804QG, the Type is CCT 35805QG, theType Name is Code 35806QG, and the Length is from one to ten 35807QG.The remark 35809QG shows that the GDT TaxDeclarationKeyNumberTypeCode35800QG may be restricted.

For the ListID 35810QG, the Category is Attribute (A) 35811QG, theObject Class is CodeList 35812QG, the Property is Identification35813QG, the Representation/Association is Identifier 35814QG, the Typeis XSD 35815QG, the Type Name is Token 35816QG, the Length is from threeto four 35817QG, and the Cardinality is zero or one 35818QG.

For the ListAgencyID 35820QG, the Category is Attribute (A) 35821QG, theObject Class is CodeListAgency 35822QG, the Property is Identification35823QG, the Representation/Association is Identifier 35824QG, the Typeis XSD 35825QG, the Type Name is Token 35826QG, the Length is from oneto six 35827QG, and the Cardinality is zero or one 35828QG.

b) Entities

Entities are discrete business elements that are used during a businesstransaction. Entities are not to be confused with business entities orthe components that interact to perform a transaction. Rather,“entities” are one of the layers of the business object model and theinterfaces. For example, a Catalogue entity is used in a CataloguePublication Request and a Purchase Order is used in a Purchase OrderRequest. These entities are created using the data types defined aboveto ensure the consistent representation of data throughout the entities.

A list of entities that are contained in the illustrative businessobject model, along with a description of each of these entities, isprovided below. The entities that do not have a corresponding globaldata type may be derived from the global data type of a related entity.For example AddressCommunication and AddressOffice are defined withinand can be derived from the Address global data type. This is easilydiscernable from the global data type previously described. Global DataEntity Definition Type Accounting ACCOUNTINGCANCELLATION is the completeCancellation cancellation of posting information previously sent toAccounting. Address ADDRESS contains structured information about theAddress types of addresses. This information includes details aboutaddressees, the postal address, and the physical location andcommunication connections. Address ADDRESSCOMMUNICATION contains detailsabout Communication the ways of contacting a person or organization.AddressGeo ADDRESSGEOCOORDTNATES contain the GeoCoordinates Coordinatesgeographical data, in other words longitude and latitude specified asper the WGS84 reference system, which enables you to determine aposition on the globe. AddressOffice ADDRESSOFFICE contains details thatdescribe the working environment of a contact person as well as detailsfor addressing or identifying this person within the organization.AddressPerson ADDRESSPERSONNAME contains the parts of a PersonName Namelegal person's name. Address ADDRESSPHYSICALADDRESS contains the postalPhysical address data of a physical location. Address Attachment AnATTACHMENT is a document of arbitrary type Attachment that is assignedto an interface object as an attachment. BTD BTDAccountingObjectSet is aset of different account AccountingObject Accounting assignment objects.An account assignment object is a Set ObjectSet business object to whichchanges in value from business transactions are assigned in accounting.BTD An ATTACHMENT is a document of arbitrary type Attachment Attachmentthat is assigned to a BUSINESSTRANSACTIONDOCUMENT or a BTDITEM as anappendix. BTD A BTDInternalAttachmentWebAddress is a Web AttachmentWebAttachmentWeb address for a document of any type that is assigned to aAddress Address BUSINESSTRANSACTIONDOCUMENT or a BTDITEM as anattachment. BTDBidder A BTDBidderParty is a party that bids for goods orBusiness Party services. Transaction DocumentParty BTDBidder ABTDBidderPortalProviderParty is a party that runs a BTDPartyPortalProvider portal that brings business partners together for a Partybusiness transaction. BTDBillFrom A BTDBillFromParty is the company orperson Business Party executing the invoicing process for a product orTransaction service. DocumentParty BTDBillTo A BTDBillToParty is thecompany or person to Business Party which/whom the invoice is to be sentfor deliveries Transaction received or services provided. DocumentPartyBTDBuyerParty A BTDBuyerParty is the company or person Businessauthorizing the deliveries or services. Transaction DocumentPartyBTDBuyer A BTDBuyerProductCatalogueReference is a reference CatalogueProduct to a product catalog of a buyer or to an item within ReferenceCatalogue such a catalog. Reference BTDCarrier A BTDCarrierParty is thecompany or person that Business Party transports the goods. TransactionDocumentParty BTDCash BTDCASHDISCOUNTTERMS are payment CashDiscountDiscountTerms conditions for goods and services. Terms BTDCashBTDCashDiscountTermsMaximumDiscount is the CashDiscount DiscountTermsmaximum cash discount in the context of payment Maximum conditions thatis granted during a sales transaction Discount when payment takes placewithin a certain number of days after the baseline date for payment haspassed. BTDCash BTDCashDiscountTermsNormalDiscount is the usualCashDiscount DiscountTerms cash discount in the context of paymentconditions that Normal is granted during a sales transaction. DiscountBTDCatalogue A BTDCATALOGUEPROVIDERPARTY is a party BusinessProviderParty that compiles a catalogue. Transaction DocumentParty BTDBTDConfirmationDescription is a text in natural Description Confirmationlanguage which is visible for parties and is related to a Descriptionconfirmation. BTDConfirmed A BTDCOFIRMEDPRICE is a price which has beenPrice confirmed. BTDContract The BTDContractReleaseAuthorisedParty is aparty BTDParty Release that is authorized to effect releases from apurchasing AuthorisedParty contract. BTDCreation BTDCreationLog is asequence of log messages about Log the creation of aBusinessTransactionDocument. BTDCreation BTDCreationLogItem is a logmessage about the LogItem LogItem creation of aBusinessTransactionDocument. BTDCredit A BTDCreditAgencyReportScoring isthe result of the CreditAgency AgencyReport rating of a party withregard to their creditworthiness ReportScoring Scoring using a scorecardspecified by a credit agency. A scorecard is a schema for rating a partyusing different characteristics. BTDCredit BTDCREDITLIMIT is the creditlimit valid for a Limit business partner for a specific period ofvalidity. BTDCreditor A BTDCreditorParty is a party that, due to anBusiness Party obligation, is authorized to claim goods, services orTransaction payment. DocumentParty BTDCredit BTDCREDITRATING is thescore determined by a Rating credit agency or a credit management for aparty for a specific period of validity. BTDCreditRiskBTDCREDITRISKCLASS is the risk class of a party Class determined by acredit agency or a credit management for a party for a specific periodof validity. BTDDebtor A BTDDebtorParty is a party that, due to anobligation, Business Party is obliged to provide goods, services orpayment. Transaction DocumentParty BTDDelivery The BTDDeliveryControl isthe set of internal Control controlling delivery parameters for one ormore requested deliveries in a delivery process. BTDDelivery ABTDDeliveryReference is a reference to a delivery Business Reference(delivery note ID) or to an item within a delivery. Transaction DocumentReference BTDDelivery The BTDDeliveryTerms are the conditions andDeliveryTerms Terms agreements that are to be valid for executing thedelivery and transporting the ordered goods and for the necessaryservices and activities. BTDDelivery A BTDDeliveryTermsDescription is atext in natural Description Terms language for specification of legibleadditional Description information for delivery terms. BTDDeliveryBTDDeliveryTermsIncoterms are commercial contract IncotermsTermsIncoterms formulae for the delivery conditions that correspond withthe rules compiled by the International Chamber of Commerce (ICC).BTDDelivery BTDDeliveryTermsPartialDelivery is the maximumPartialDelivery TermsPartial number of partial deliveries that may/canbe carried out Delivery to deliver the ordered quantity of an item.BTDDelivery BTDDeliveryTermsQuantityTolerance is the tolerated QuantityTermsQuantity difference between a requested and an actual quantityTolerance Tolerance (for example, a delivery quantity) as a percentage.BTDDelivery BTDDeliveryTermsTransport provides information forTermsTransport the transport of goods. This includes, for example, speedof delivery, the way of doing the transport, the transportation mode,and the transport category. BTD BTDConfirmationDescription is a text innatural Description Description language which is visible for parties.BTD A BTDDespatchedDeliveryNotificationReference is Business Despatchedthe reference to a shipping notification. Transaction Delivery DocumentNotification Reference Reference BTDFollowUp TheBTDFollowUpBillingDueNotification is BillingDue information aboutwhether an invoice is to be created Notification during the subsequentprocess and whether the delivery data is required for invoice creation.BTDFollowUp The BTDFollowUpDespatchedDeliveryNotification is Despatchedinformation about how and if the buyer would like to Delivery beinformed by the seller of a delivery and specifies if Notification anadvanced shipping notification (ASN) is expected or is to be sent.BTDFollowUp BTDFollowUpInvoiceRequest is information aboutInvoiceRequest whether the buyer expects to receive an invoice from theseller. BTDFollowUp The BTDFollowUpInvoicingDueNotification isInvoicingDue information about whether an invoice is expectedNotification during the subsequent process and if the delivery data isrequired for invoice verification. BTDFollowUp ABTDFollowUpPurchaseContract is information Purchase about whether thebuyer expects a purchase contract as Contract the result of the requestfor quotation process. BTDFollowUp A BTDFollowUpPurchaseOrder isinformation about PurchaseOrder whether the buyer expects a purchaseorder as a result of the request for quotation process. BTDFollowUpBTDFollowUpPurchaseOrderConfirmation is PurchaseOrder information aboutwhether and in what form the buyer Confirmation expects to receiveconfirmation of the purchase order from the seller. BTDFollowUp ABTDFollowUpPurchasingContract is information Purchasing about whetherthe buyer expects a purchase contract as Contract the result of therequest for quotation process. BTDFollowUp ABTDFollowUpSalesOrderFulfillmentConfirmation is SalesOrder informationabout whether the seller expects a Fulfillment confirmation of aSalesOrderFulfillment from the Confirmation procurement planningcomponent. BTDFollowUp BTDFollowUpServiceAcknowledgementRequest isService information about whether the buyer wants to be Acknowledgementinformed by the seller of any services provided. Request BTDHandlingBTDHandlingUnit is a physical unit of packaging HandlingUnit Unitmaterials (load carrier, additional packaging materials) and thepackaged products (of type “Material”). BTDIBatch BTDIBatch is a batchwith its properties. A batch is a Batch non-reproducible, homogeneoussubset of a product. The subset's chracteristics lie within the batchcharacteristics defined for the product. BTDI BTDConsignmentInventory isthe consignment store Consignment stock of a product; in other words,the part of the stock Inventory that remains the property of the vendoruntil it is procured (and paid for). BTDIInventory BTDInventory is thewarehouse stock of a product. BTDInbound BTDDeliveryReference is thereference to an incoming Business Delivery delivery or one of its items.Transaction Reference Document Reference BTDInternal ABTDInternalAttachmentWebAddress is a Web AttachmentWeb AttachmentWebaddress for a document of any type that is assigned to a Address AddressBUSINESSTRANSACTIONDOCUMENT or a BTDITEM as an attachment. It is notvisible for parties. BTDInternal A BTDINTERNALDESCRIPTION is a text innatural Description Description language which is not visible forexternal parties. It is intended for internal use only. BTDInvoice ABTDInvoiceReference is the reference to the invoice Business Referenceof the invoicing party. Transaction Document Reference BTDI ABTDIPreferentialStatement is the legally binding Preferential statementof vendors on goods they have delivered, Statement which allows thebuyer to claim customs tariff preferences for these goods. BTDI ANonPreferentialProductConstituent is a specification Preferential onparts or precursor materials of a product for which Statement no customstariff preferences can be claimed. NonPreferential Product ConstituentBTDIPrevious A BTDIPreviousRelease is a statement about the Releaseidentification and validity of the last release instance previouslytransferred in a delivery schedule. BTDIPromotion A BTDIPromotion is amarketing activity between the consumer goods industry and retail over alimited time frame to increase brand capital, name recognition, andmarket share, to boost sales volumes, or to position new products orproduct groups. BTDIRelease A BTDIRelease is a statement about theidentification and validity of a release instance transferred in adelivery schedule item. BTDItem BTDITEM is an Item of aBusinessTransactionDocument. In general it describes a product orsubject of business activities. Quantities and/or dates are specified bymeans of the BTDItemScheduleLine. BTDItem ABusinessTransactionDocumentItemScheduleLine is PurchaseOrder Confirmed aconfirmed subdivision of items of a business Item ScheduleLineScheduleLine transaction document according to dates and the SalesOrderproduct quantity associated with each date. FulfillmentItem ScheduleLineBTDItem BTDHierarchyRelationship is the relationship between Hierarchy asubitem and a higher-level parent item in an item Relationshiphierarchy. BTDItem A BusinessTransactionDocumentItemScheduleLine isPurchaseOrder ScheduleLine a subdivision of items of a businesstransaction ItemScheduleLine document according to dates and the productquantity SalesOrder associated with each date. FulfillmentItemScheduleLine BTDItem The BTDItemScheduleLineDeliveryPeriod is the dateDateTimePeriod ScheduleLine or the period for the delivery of goods orthe provision DeliveryPeriod of services. BTDLegal ALegalDocumentAttachment is an attachment that Attachment Documentcontains the legal text of a business transaction Attachment document.BTDLegal A BTDLEGALEVENT is a legal transaction or a legal Event event.BTDLoan A BTDLoanAmortizementCondition is a repayment Loan Amortizementcondition for a loan. It regulates the conditions to AmortizementCondition which a loan is to be repaid. Condition BTDLoanFee ABTDLoanFeeCondition is the fee condition for a LoanFee Condition loan.Condition BTDLoan A BTDLoanInterestCondition is a condition forLoanInterest Interest calculating the interest on a loan. ConditionCondition BTDLoan A BTDLoanPaymentPlan contains the planned PaymentPlanpayments for a loan. BTDLoan A BTDLoanPaymentPlanItem is a paymentplanned for LoanPaymentPlan PaymentPlan a key date for a loan. Item ItemBTDLocation A BusinessTransactionDocumentLocation contains the Businessinformation that is exchanged in business documents Transaction about alocation relevant for business transactions. Document Thesespecifications contain the identification of the Location location andits address. The identification may be a company-internal ID, astandardized ID, or one or several partner-specific IDs. A location is alogical or a physical place. BTDLocation A BTDLocationAddress assigns anaddress to a Address BTDLocation. BTD A ManufacturerParty is a partythat manufactures Business Manufacturer goods. Transaction PartyDocumentParty BTDNet The BTDNetPurchasePrice refers to the net purchasePrice PurchasePrice price specified by the requester or the buyer(relating to the quantity ordered) for the product or service. Thisprice forms the basis for order optimizing in the planning system. BTDThe BTDOperationalPurchasingContractReference is Business Operationalthe reference to an operational purchasing contract or TransactionPurchasing to an item within an operational purchasing contract.Document Contract Reference Reference BTDOrigin ABTDOriginInvoiceReference is a reference to an Business Invoice origininvoice. Transaction Reference Document Reference BTDOriginBTDOriginPrimaNotaReference is the reference to the Business PrimaNotaorigin document of the sender on which posting Transaction Referenceinformation previously sent to Accounting - and now Document to becancelled - is based. Reference BTDOrigin ABTDOriginPurchaseOrderReference is a reference to Business PurchaseOrderan origin purchase order or to an item within an origin TransactionReference purchase order. Document Reference BTDOrigin ABTDOriginVendorInvoiceReference is the reference Business VendorInvoiceto an origin vendor invoice. Transaction Reference Document ReferenceBTDOwner An BTDOwnerParty is a party that has tangible or Business Partyintangible commodity as property. Transaction DocumentParty BTDParty ABusinessTransactionDocumentParty contains the Business information thatis exchanged - in accordance with Transaction common businessunderstanding - in business DocumentParty documents about a partyinvolved in business transactions. This information is used to identifythe party and the party's address, as well as the party's contact personand the contact person's address. This identification can take placeusing an internal ID, a standardized ID, or IDs assigned by the involvedparties. BTDParty A BTDPartyAddress assigns an address to a BTDParty.Address Address BTDParty A BTDPARTYCONTACTPERSON is a contact BusinessContactPerson person of a party. A ContactPerson is a natural personTransaction who acts as a contact person during the processing ofDocumentParty business processes. The ContactPerson includes details ofthe ContactPerson's identification as well as the ContactPerson'saddress. Identification can take place using an internal ID and usingID's assigned by the involved parties. BTDParty ABTDPartyContactPersonAddress assigns an address ContactPerson to aBTDPartyContactPerson. Address BTDPayeeParty A BTDPayeeParty is a partythat receives a payment Business for goods or services. TransactionDocumentParty BTDPayerParty A BTDPayerParty is a party that pays forgoods or Business services. Transaction DocumentParty BTDPayment ABTDPAYMENTFORM is the way in which, for Form example, goods or servicesare paid for. BTDPayment A BTDPAYMENTFORMPAYMENTCARD is an PaymentCardFormPayment identification card suited for a certain payment form. ItCard authorizes the holder to settle invoices without cash with contractcompanies connected to the payment system. BTDPendingPendingDeliveryReference is the reference to an item Business Deliveryin a delivery that is to be executed or is expected. TransactionReference Document Reference BTDPortal A BTDPortalProviderParty is aparty that runs a portal Business ProviderParty that brings businesspartners together for a business Transaction transaction. DocumentPartyBTDPrice A BTDPrice is a remuneration for a product, which is valid fora base quantity, for a certain period and ship- to location, and whichcan be scaled according to quantity. BTDPrice A BTDPriceComponent is anon-fiscal part of a price PriceComponent Component that was calculatedfor the quantity of a product. BTDPriceScale A BTDPriceScale is a set ofprice scale lines arranged linearly in accordance with a scale (axis)base type. BTDPriceScale A PriceScaleLine is the price of a productdepending Line on the quantity. BTDPrice A BTDPriceSpecificationElementis the definition of a PriceSpecification Specification price, adiscount or a surcharge that is dependent on a Element Elementcombination of properties and that is valid for a certain period oftime. BTDPrimaNota BTDPrimaNotaReference is the reference to theBusiness Reference document of the sender which represents theTransaction cancellation request to Accounting. Document Reference BTD AProcurementCostUpperLimit is a cost upper limit for ProcurementCostProcurement different types of procurement costs. UpperLimitCostUpperLimit BTDProduct A BusinessTransactionDocumentProduct containsthe Business information that is exchanged - in accordance withTransaction common business understanding - in business DocumentProductdocuments about a product. These are the details for identifying aproduct, product type as well as the description of the product. Thisidentification can take place using an internal ID, a standardized ID,or IDs assigned by the involved parties. BTDProduct ABusinessTransactionDocumentProductCategory Business Category containsthe information that is exchanged - in Transaction accordance withcommon business understanding - in DocumentProduct business documentsabout a product category. It Category includes details for identifyingthe product category using an internal ID, a standard ID along with IDsassigned by involved parties. BTDProduct A BTDProductRecipientParty is aparty to which goods Business RecipientParty are delivered or servicesare provided. Transaction DocumentParty BTDProduct A BTDProductTax is atax that is incurred when ProductTax Tax products are purchased, sold,or consumed. BTDProposed A ProposedSellerParty is a preferred party forselling BTDParty SellerParty goods or services. BTDPurchase ABTDPurchaseOrderReference is a reference to a Business Order purchaseorder or item in a purchase order. Transaction Reference DocumentReference BTDPurchasing A BTDPurchasingContractReference is a referenceto a Business Contract purchase contract or item in a purchase contract.Transaction Reference Document Reference BTDQuote A BTDQUOTEREFERENCE isa reference to a Business Reference quotation or item in a quotation.Transaction Document Reference BTDRequest ABTDRequestForQuotationReference is a reference to Business ForQuotationa request for quotation or item in a request for Transaction Referencequotation. Document Reference BTDRequestor A BTDRequestorParty is aparty that requests the Business Party procurement of goods or services.Transaction DocumentParty BTDSales A BTDSALESCONTRACTREFERENCE is aBusiness Contract reference to a sales contract or item in a salescontract. Transaction Reference Document Reference BTDSalesOrder ABTDSalesOrderReference is a reference to a sales Business Referenceorder or item of a sales order. Transaction Document ReferenceBTDScheduling A BTDSCHEDULING groups together time intervals in order todefine a schedule, for example, for ordering, delivering, or picking upproducts. BTDScheduling A BTDSchedulingAgreementReference is a referenceBusiness Agreement to a scheduling agreement or item in a schedulingTransaction Reference agreement. Document Reference BTDSellerParty ABTDSELLERPARTY is a party that sells goods or Business services.Transaction DocumentParty BTDSeller A BTDSellerProductCatalogueReferenceis a reference Catalogue Product to a seller product catalogue or itemin a seller product Reference Catalogue catalogue. Reference BTDServiceA BTDServiceAcknowledgementReference is a Business Acknowledgementreference to a service acknowledgement or item in a TransactionReference service acknowledgement. Document Reference BTDShipFrom ABTDShipFromLocation contains the information that Business Location isexchanged in business documents about a location Transaction relevantfor business transactions, and from where DocumentShip goods or servicesare shipped. These specifications FromLocation contain theidentification of the location, its address and, if necessary, adifferent loading location. The identification may be a company-internalID, a standardized ID, or one or several partner-specific IDs.BTDShipment A BTDShipmentReference is a reference to a shipment BusinessReference or item in a shipment. Transaction Document ReferenceBTDShipTo A BTDShipToLocation contains the information that is BusinessLocation exchanged in business documents about a location Transactionrelevant for business transactions, and to which goods DocumentShipTo orservices are shipped. These specifications contain Location theidentification of the location, its address and, if necessary, adifferent unloading location. The identification may be acompany-internal ID, a standardized ID, or one or severalpartner-specific IDs. BTDTax A TaxAuthorityParty is a party thatcollects and TaxAuthority AuthorityParty manages taxes. Party BTDTax ABTDTaxOperatorParty is a party that processes tax BTDParty OperatorPartyaffairs for a BTDTaxPayerParty. BTDTaxPayer A BTDTaxPayerParty is aparty that is liable to tax. BTDParty Party BTDTransportBTDTransportMeans is the description of a means of TransportMeans Meanstransport and also can include information for a more detailedidentification. BTDTransport BTDTransportTracking containstransport-related Transport Tracking information that can be used fortracking deliveries, for Tracking example, in goods deliveries. BTD ABusinessTransactionDocumentTransshipment BTD Transshipment Locationcontains the information that is exchanged in Transshipment Locationbusiness documents about a relevant location for Location businesstransactions where goods are transshipped (unloaded and reloaded). Thisinformation identifies the location, its address, a loading location,and an unloading location. The identification may be a company-internalID, a standardized ID, or one or more partner-specific IDs.BTDValidation A BTDValidationLog is a series of log messages from Logthe tax authority that is has received and validated a tax return fortax on sales/purchases. BTDValidation A ValidationLogItem is a logmessage on the receipt LogItem LogItem and validation of a tax returnfor tax on sales/purchases. BTDVendor A BTDVendorParty is a party whichdelivers goods or Business Party provides services. TransactionDocumentParty BTDVendor A BTDVendorProductCategory is a company-specificBusiness Product or vendor-specific schedule line for a vendor's entireTransaction Category range of products (vendor subrange). The DocumentVendorProductCategory provides the vendor view. ProductCategoryBusinessPartner A BusinessPartner is a person, an organization, or agroup of persons in which a company has a business interest. Business ABUSINESSTRANSACTIONDOCUMENT is a Transaction document that occurs or iscreated in the context of a Document business transaction. It representsfor a point in time information about Planning Execution/fulfillmentNegotiations or agreements Flows of values or goods regarding theinvolved parties and products, or subjects of a business activity. Thiscan be planned information, targeted information, or actual information.The BUSINESSTRANSACTIONDOCUMENT contains the structures required forbusiness transactions. In general, the basic structure of aBUSINESSTRANSACTIONDOCUMENT is subdivided into items, which in turn aresubdivided into schedule lines according to dates and the productquantity associated with each date. BuyerProduct A BUYERPRODUCTCATALOGUEis a product Catalogue catalogue of a buyer. Catalogue A Catalogue is astructured directory of Catalogue items. Each item represents an object,and provides information about it. The Catalogue consists of global-,model-and content information. The global information providesinformation relevant to the entire Catalogue. The model informationdefines the structure of the Catalogue content and the properties usedto describe this content. Content information contains the items of theCatalogue and their structural assignment within the Cataloguestructure. It also can be the confirmation whether the publication of aCatalogue or the deletion of an already published Catalogue wassuccessful or not. Catalogue A CatalogueContent specifies the list ofbusiness CatalogueContent Content objects included in the catalogue,together with their relationships and descriptions according to thecatalogue's schemas, and the views that are used to restrict thecatalogue's information content for certain purposes. The Cataloguecontent specifies the items contained in the Catalogue and theirclassification (that is, their assignment to Catalogue sections). Theitems can be arranged by defining relationships with a specificsemantics between them. Specific (usage- dependent) Catalogue views canbe defined for a Catalogue. Such a view specifies a subset of theCatalogue structure and/or the Catalogue content. Catalogue ACatalogueContentCatalogueItem specifies CatalogueItem Contentinformation about an object included and to be CatalogueItem classifiedwithin the Catalogue, and in a way according to the Catalogue's schema.A CatalogueContentCatalogueItem can contain one or more Descriptionswhich describe the item. The item can be classified by one or moreClassifications. Furthermore, it can contain one or morePropertyValuations valid for this item. Catalogue ACatalogueContentCatalogueItemClassification CatalogueItem Contentclassifies an item by assigning it to a Section within ClassificationCatalogueItem one of the Catalogue's schemas which the item belongsClassification to. Catalogue A CatalogueContentCatalogueItemDescriptionDescription Content provides a description for an item in a localeCatalogueItem (language). Description Catalogue ACatalogueContentCatalogueItemPropertyValuation Property Contentspecifies the value of a property that can be attributed ValuationCatalogueItem to the object the item represents, according to one ofProperty the Catalogue schemas. Valuation Catalogue ACatalogueContentCatalogueItemRelationship CatalogueItem Contentspecifies a relationship with certain semantics between RelationshipCatalogueItem any two Catalogue items. Relationship Catalogue ACatalogueContentCatalogueView defines a restricted CatalogueView Contentsubset of a Catalogue by specifying schemas, sections, CatalogueViewCatalogue items and item relationship types to be included andproperties to be excluded. A CatalogueContentCatalogueView can containone or more CatalogueViewSchemas, CatalogueViewItems andCatalogueViewItemRelationshipTypes which specify schemas, items and itemrelationship types included in the view. In addition, aCatalogueContentCatalogueView can contain one or moreCatalogueViewExcludedProperty which specify properties not included inthe view. Catalogue A CatalogueContentCatalogueViewExcludedPropertyCatalogueView Content specifies a property that is not included in theExcludedProperty CatalogueView Catalogue view. Excluded PropertyCatalogue A CatalogueContentCatalogueViewItem specifies a CatalogueViewContent Catalogue item to be included in the Catalogue view. ItemCatalogueView Item Catalogue ACatalogueContentCatalogueViewItemRelationship CatalogueView Content Typespecifies a Catalogue item relationship type. All ItemRelationshipCatalogueView Catalogue item relationships of this type are to be TypeItemRelationship included in the Catalogue view. Type Catalogue ACatalogueContentCatalogueViewSchema specifies a CatalogueView Contentschema and a list of sections belonging to the schema SchemaCatalogueView that are to be included in a Catalogue view. A SchemaCatalogueContentCatalogueViewSchema is subdivided into one or moreCatalogueViewSchemaSections which specify Sections included in the view.Catalogue A CatalogueContentCatalogueViewSchemaSection CatalogueViewContent specifies a Section of the referenced Catalogue schemaSchemaSection CatalogueView to be included in the Catalogue view.SchemaSection Catalogue A CatalogueModel describes and structures theCatalogueModel Model catalogue content using systems of categories togroup catalogue items and properties that can be attributed to thecatalogue items or the categories themselves (or both). TheCatalogueModel is the information concerning how the catalogue contentis structured and defined. The CatalogueModel defines properties, their(technical) data types and allowed values, which are used to describeCatalogue sections and/or the items contained in the Catalogue.Additionally the CatalogueModel specifies one or more schemas, whichdefine the structural composition of the Catalogue content by means ofsections and relationships between these sections. The Sections of aschema are a dividing up of Catalogue items and they specify propertieswhich are used to describe the items assigned to the section. Schemasare defined for a specific purpose. Therefore, multiple schemas for oneCatalogue can exist. Catalogue A CatalogueModelCatalogueItemPropertyspecifies a Model property pertaining to each catalogue item togetherCatalogueItem with its position in the full list of propertiesattributed Property to a catalogue item. Catalogue ACatalogueModelCatalogueSchema defines a CatalogueSchema Model structuralcomposition of the Catalogue content Catalogue regarding a certainpurpose. A Schema CatalogueModelCatalogueSchema can contain one or moreItemProperty for the description of catalogue items of this schema. Inaddition, a Schema is subdivided into one or more Sections andSectionRelationships which define its structure. Catalogue ACatalogueModelCatalogueSchemaCatalogueItem Property Model Propertyspecifies a property pertaining to a Catalogue Catalogue item togetherwith its position in the full list of Schema properties attributed to aCatalogue item. CatalogueItem Property Catalogue ACatalogueModelCatalogueSchemaCatalogueSection Model is a dividing up ofCatalogue items according to the Catalogue schema. A section specifiesproperties which can be Schema used to describe such Items. A CatalogueCatalogueModelCatalogueSchemaSection can contain Section one ore morePropertyValuations which describe the section. In addition it cancontain one or more ItemProperty for the description of catalogue itemsof this section. Catalogue A CatalogueModelCatalogueSchemaSectionItemProperty Model Property specifies a property pertaining to the CatalogueCatalogue items (objects) belonging to the Section, Schema together withthe property's position in the full list of Catalogue propertiesattributed to a Catalogue item. Section CatalogueItem Property CatalogueA CatalogueModelCatalogueSchemaCatalogueSection Property ModelPropertyValuation contains the value of a property that ValuationCatalogue can be attributed to or is used to describe the Section Schemaaccording to its Section type. Catalogue SectionProperty ValuationCatalogue A CatalogueModelCatalogueSchemaCatalogueSection ModelRelationship specifies a connection between two Catalogue cataloguesections within a Catalogue schema. Schema Catalogue SectionRelationship Catalogue A CatalogueModelCatalogueSectionType describesthe CatalogueSection Model nature of Catalogue sections by definingproperties for Type Catalogue the description of sections of this type.A SectionType CatalogueModelCatalogueSectionType can contain one or moreSectionProperty for the description of sections of this type. CatalogueA CatalogueSection ModelCatalogueModelCatalogueSectionTypeSectionProperty TypeSection Cataloguespecifies a property pertaining to a Section type Property SectionTypetogether with its position in the list of properties. ThisSectionProperty property has to be attributed to all sections of thisSection type. Catalogue A CatalogueModelProperty specifies a propertyand Property Model Property additional information for it that can beused to describe and differentiate between items contained or sectionsused within the Catalogue. Catalogue A CatalogueModelPropertyDataTypedefines the data PropertyData Model Property type of properties (andinformation about its change) Type DataType used in the Catalogue.Catalogue A CatalogueModelPropertyDefinitionClass defines the PropertyModelProperty scope of properties used in the Catalog. DefinitionClassDefinitionClass Catalogue A CatalogueProviderPropertyValuation valuatesProperty Provider properties provided by the Catalogue provider toValuation Property provide additional information about the CatalogueValuation (e.g., any information about the vendor's, Catalogue creationdate, or Note.). Catalogue A CataloguePublication is a new, changed ordeleted Transmission Publication catalogue for publishing. CatalogueCatalogue A CataloguePublicationConfirmation is the CataloguePublication confirmation whether the publication of a Catalogue orPublication Confirmation the deletion of a (published) Catalogue wassuccessful Confirmation or not. Catalogue ACATALOGUEPUBLICATIONTRANSMISSION is Publication information concerningthe transmission of a catalogue Transmission publication. This can beinformation about the reception of a package of the cataloguepublication transmission and the validity of its content or the requestto cancel the transmission of a catalogue publication or theconfirmation of such a request or the request to lock single items of acatalogue publication transmission or the confirmation of such a lockrequest. Catalogue The CataloguePublicationTransmissionCancellationCatalogue Publication Confirmation is the confirmation whether thePublication Transmission transmission of a Catalogue has been cancelledTransmission Cancellation successfully and an earlier published state ofthis Cancellation Confirmation catalogue (if such exists) has beenrestored or not. The Confirmation entityCataloguePublicationTransmission contains information about a catalogueCatalogue A Catalogue PublicationCataloguePublicationTransmissionCancellationRequest PublicationTransmission is the request to cancel the transmission of a CatalogueTransmission Cancellation and to restore an earlier published state (ifsuch exists) Cancellation Request of the Catalogue. Moreover, no morepackages are Request sent for this transmission. Catalogue ACataloguePublicationTransmissionContentChange Publication Confirmationis the confirmation of Catalog Search Transmission Engine (thepublishing system) to Catalog Authoring ContentChange whether a limitednumber of catalog items contained in Confirmation the catalogpublication transmission could be changed, created or deleted asrequested by a CataloguePublicationTransmissionContentChange Request ornot. Catalogue A CataloguePublicationTransmissionContentChangePublication Request is the request of Catalog Authoring to CatalogTransmission Search Engine to change, create or to delete a limitedContentChange number of catalog items contained in the catalog Requestpublication transmission. Catalogue ACataloguePublicationTransmissionItemLock Catalogue PublicationConfirmation is the confirmation whether single items PublicationTransmission of the catalogue contained in the catalogue publicationTransmissionItem ItemLock transmission could be locked or not. To lockmeans: If Lock Confirmation the catalogue is not yet published the itemsmust not be Confirmation published. If the catalogue is alreadypublished, the publication of these items must be revoked. Catalogue ACataloguePublicationTransmissionItemLockRequest Catalogue Publication isthe request to lock single items of the catalogue PublicationTransmission contained in the catalogue publication transmission.TransmissionItem ItemLock To lock means: If the catalogue is not yetpublished the LockRequest Request items must not be published. If thecatalogue is already published, the publication of these items must berevoked. Catalogue A CataloguePublicationTransmissionPackage specifiesCatalogue Publication a package of a Catalogue publication transmissionand Publication Transmission information about the reception of thispackage and the Transmission Package validity of its content. PackageCatalogue A CatalogueUpdate is a new, changed or deleted TransmissionUpdate catalogue. Catalogue CreditAgency A CREDITAGENCYREPORT is thecredit CreditAgency Report information issued by the credit agency for aparty. Report CREDITAGENCYREPORT contains the credit informationrequired about a party, with details about the creation of thisinformation. CreditAgency A CREDITAGENCYREPORTQUERY is the query toCreditAgency ReportQuery a credit agency for credit information about aparty. ReportQuery CREDITAGENCYREPORTQUERY contains details about theparty for whom credit information is required, together with aspecification of the service required by the agency. CreditAgency ACREDITAGENCYREPORTQUERYSERVICE ReportQuery specifies the type and scopeof the service required Service from the credit agency. CreditCREDITWORTHINESS specifies the creditworthiness CreditWorthinessWorthiness of a business partner, if required with details of the score,risk class, and credit limit. Credit A CREDITWORTHINESSQUERY is thequery CreditWorthiness Worthiness regarding the creditworthiness of abusiness partner. Query Query Cumulative A CumulativeDelivery containsthe cumulated Delivery quantities of all the deliveries for a product inthe specified validity period. CustomsVendor A CustomsVendorDeclarationis the legally binding Declaration declaration of the vendors concerningthe goods they delivered to a buyer which allows the buyer to claimcustoms tariff preferences. A vendor declaration can be made as anindividual declaration for an individual delivery or as a long-termdeclaration that is, in general, valid for one year. CustomsVendor ACustomsVendorDeclarationItem is the summary of DeclarationItem all thespecifications that vendors make in the CustomsVendorDeclaration on aproduct they deliver. Delivery A Delivery is a collection of goods thatis to be staged Delivery for shipment or is to be received - aftershipment - for further use within a company. Delivery specifies when andwhere certain quantities of products are delivered. It also may informabout the status of execution of a delivery. Delivery ADELIVERYEXECUTIONPERIOD is the planned or Execution current period ortime at which a particular step of the Period delivery process is to becompleted or has been completed. Delivery A DeliveryExecutionRequest isa request to supply Delivery Execution chain execution (Logistics, thewarehouse) to stage ExecutionRequest Request goods and to deliver themor prepare goods arrivals and receive incoming goods.DeliveryExecutionRequest contains request items with the requestedproducts, partners, locations, and schedule lines. This specifies whenand where, and by whom, products are to be staged and delivered (fromand to) and received. Delivery A DeliveryExecutionRequestItem is thepart of a Delivery Execution delivery request that contains an actualproduct, its ExecutionRequest RequestItem quantities, and dates as wellas the location to which Item the product is to be delivered. Delivery ADELIVERYEXECUTIONSTATUS specifies the ExecutionStatus type and executionstatus of delivery processing reached for all the items or the deliveryas a whole. Delivery A DeliveryInformation is a message about thecreation Information of a delivery, changes made to a delivery, and theexecution status of a delivery. DeliveryInformation is divided intodelivery items (DeliveryItems), which describe the execution status andexecution period for delivering a particular quantity of a product orbatch. References to relevant business documents can be specified for adelivery item. For the delivery as a whole, the ship-from/to location,shipment details, and references to any relevant business documents canbe specified alongside the delivering party, recipient, and shippingparty. Delivery A DeliveryInformationItem is a quantity of a product inInformation the delivery and contains additional information about Itemits delivery processing status along with any references to previousbusiness documents. DeliveryItem A DELIVERYITEM is an item thatspecifies a quantity DeliveryItem of a product to be delivered andcontains additional information about its delivery processing statusalong with any references to previous business documents. DeliveryItemDeliveryItemVariance describes a variance in the Variance receivedquantity of a product and type of and reason for the variance. DeliveryA DeliverySchedule is a tool that is used by a customer Schedule tonotify a vendor about the quantity of a material from a schedulingagreement item that is to be delivered and at what time. DeliveryDeliveryScheduleItem is a statement regarding the ScheduleItemrequirement for a specific product at a ship-to location with referenceto a scheduling agreement (“Scheduling Agreement”). DespatchedDespatchedDeliveryItem describes what quantity of a DeliveryItem productis to be delivered/picked up. Despatched ADespatchedDeliveryNotification is a notice for a Despatched Deliverygoods recipient about the planned arrival/pickup/issue DeliveryNotification date for a ready-to-send delivery including details aboutthe contents of the delivery. In general, aDespatchedDeliveryNotification contains several items, which refer tothe specifications for the quantity, weight, and volume for eachdelivered product, as well as preceding documents and/or outlineagreements. Inbound An InboundDelivery is an incoming delivery. DeliveryIncoterms Incoterms are commercial contract formulae for the Incotermsdelivery conditions that correspond with the rules compiled by theInternational Chamber of Commerce (ICC). Inventory InventoryChangesummarizes changes in warehouse InventoryChange Change stock. AnInventoryChange consists of individual changes in warehouse stock whichAccounting or Logistics Planning must be informed of. All of the stockchanges summarized in a message are of the same transaction type (goodsreceipt, goods issue, physical stock, transfer posting, and so on).Inventory An INVENTORYCHANGEACCOUNTING Change CANCELLATION is the fullcancellation of posting Accounting information previously sent toAccounting with respect Cancellation to a goods movement. Inventory AnInventoryChangeItem is an individual warehouse InventoryChangeChangeItem stock change. Item Inventory An InventoryChangeItemInboundcharacterizes a InventoryChange ChangeItem receipt of warehouse stock bymeans of the receiving ItemInbound Inbound location, receiving owner,received quantity, and received material. Inventory AnInventoryChangeItemOutbound characterizes an InventoryChange ChangeItemissue of warehouse stock by means of the ship-from ItemOutbound Outboundlocation, issuing owner, issued quantity, and issued material. InvoiceAn Invoice is a binding request from an invoicing party Invoice (such asvendor) to an invoice recipient (such as a sold- to-party) to makepayment for the type and quantity of products or services received as aresult of previous business transactions by a predefined date. Invoicenot only specifies the remuneration and tax to be paid by theparticipating business partners for products and services provided, butalso gives detailed information about the payment conditions anddelivery terms. Invoice An InvoiceAccounting is the preparation of aninvoice Invoice Accounting or credit memo for Accounting. For an invoiceor Accounting credit memo uniquely identified as the underlying businessdocument, InvoiceAccounting contains item information about receivablesand payables, taxes on sales and purchases, and expenses and revenues.In addition, the business partners involved are named. Invoice AnINVOICEACCOUNTINGCANCELLATION is the Accounting full cancellation ofposting information previously sent Cancellation to Accounting for anincoming or outgoing invoice or credit memo. Invoice AnInvoiceAccountingDueItem is the information Invoice AccountingDuerelevant for Accounting about receivables or payments AccountingDue Itemfrom deliveries and services that are listed in an invoice Item orcredit memo item. Invoice An InvoiceAccountingExpenseRevenueItem is theInvoice Accounting information relevant for Accounting about an expenseAccounting Expense or revenue that was listed in an invoice or creditmemo ExpenseRevenue RevenueItem item. Item Invoice AnInvoiceAccountingItem is the information relevant AccountingItem forAccounting about an account receivable or payable from deliveries andservices that are listed in an invoice or credit memo item. Invoice AnInvoiceAccountingTaxItem is the information Invoice AccountingTaxrelevant for Accounting about an account receivable or AccountingTaxItem payable from taxes on sales and purchases that are Item listed inan invoice or credit memo item. InvoiceDue An InvoiceDue summarizes thedetails regarding a InvoiceDue business transaction that are relevantfor settling (creating billing documents and checking and creatingincoming invoices) this business transaction. InvoiceDue consists ofInvoiceDueItems, which represent items of the base business document forthe future settlement. An InvoiceDueItem usually consists of informationabout the quantity of a product that has been ordered or delivered, aswell as the business partners, locations, terms of delivery and paymentinvolved and the other business documents to be taken into account whenthe product is settled. InvoiceDue An InvoiceDueCancellation is arequest to exclude Cancellation business document data that has alreadybeen sent from the settlement. InvoiceDueItem An InvoiceDueItemsummarizes the information from a InvoiceDueItem business document itemthat is to be taken into account in the future settlement. AnInvoiceDueItem usually consists of information about the quantity of aproduct that has been ordered or delivered, as well as the businesspartners, locations, terms of delivery and payment conditions involved,and the other business documents to be taken into account when theproduct is settled. InvoiceIssued An InvoiceIssued summarizes theinvoice information InvoiceIssued relevant for contractmanagement/sales. InvoiceIssued contains information about which orderitems, items in credit and debit memo requests or delivery items havebeen billed and to what extent. InvoiceIssued An InvoiceIssuedItemspecifies the quantity or the InvoiceIssued Item partial value of aproduct billed with respect to a Item business transaction. InvoiceItemAn InvoiceItem is part of an invoice containing the InvoiceItem pricesand taxes for the quantity of a product that has been delivered or for aservice that has been provided. In addition, to the information aboutprices and taxes, InvoiceItem comprises information about theparticipating business partners, the payment conditions, and thedelivery terms, if they differ from the information provided in theinvoice header. Loan A LoanCalculation describes the results of a loanCalculation calculation. Loan A LoanCalculationQuery describes the queryCalculation requesting a loan calculation. It contains information Queryabout the loan to be calculated, loan conditions, and type ofcalculation to be made. LoanContract A LoanContract contains all of theinformation that is required for creating a loan contract. The loan isbased on loan conditions. These define the interest rate, repayment, andfees. Structurally speaking the loan contract is made up as follows:Description of parties to the contract (lender, borrower, and possiblyPayerParty, LoanBrokerParty, and GuarantorParty). Key loan attributessuch as start and end of loan as well as reason for loan, and so on.Payment information Conditions (Interest, Repayment, Fees) Fundamentalagreements and documents such as general terms and conditions, financialstatements, personal information, information about the financingobject, collateral agreement. LoanContract A LoanContractItem definesthe conditions of a loan. Item Conditions can be: Interest conditionsRepayment conditions Fees Location A location is a physical place.OrderID An OrderIDAssignment represents an assignment of Assignmentorder numbers to a vendor/seller by a buyer or, more generally, to anagent by an ordering party. OrderID An OrderIDAssignmentItem describesthe order Assignment numbers that are permissible and should be used toItem identify orders created by the seller for a specific combination ofdelivery location, marketing promotion, and purchasing group at thebuyer. Organisational Building block of the enterprise model, whichCentre represents a node in an organizational structure of the extendedenterprise. It incorporates different business roles that are defined indetail by specializing the org centre into business characters.PaymentDue PaymentDue indicates the type of due payments (for PaymentDuepayment or expected) and their amounts. For each invoice or credit memothat is uniquely identified as the base business document, PaymentDuereceives one or more due date items (PaymentDueItems) with details ofthe type and amount of the payment due, the payment terms and thebusiness partners involved. PaymentDue A PaymentDueItem describes a duedate item PaymentDueItem Item (receivable or payable). PaymentDueItemcan contain additional details on payment terms and participatingbusiness partners as well as the type and amount of payment due. PendingA PENDINGDELIVERY is a planned delivery. Delivery PersonnelTimePersonnelTimeSheet groups together the personnel PersonnelTime Sheettimes or personnel time events recorded for a personnel Sheet resource.The PersonnelTimeSheet includes one or more PersonnelTimeSubsheets,which contain the personnel times and personnel time events for one workagreement. PersonnelTime A PersonnelTimeSubsheet is a set of personneltimes PersonnelTime Subsheet and personnel time events that have beenrecorded Subsheet during a particular period for a personnel resourceregarding a work agreement. PersonnelTime APersonnelTimeSubsheetPersonnelTime is a period of PersonnelTime Subsheeta personnel resource that is characterized by business, PersonnelTimepay scale, or legal criteria. PersonnelTime A personnel time event is achange in the execution of PersonnelTime Subsheet services of apersonnel resource with which one Event PersonnelTime personnel timeends and another personnel time begins. Event Such changes can include,for example, the start of work, interruption of work, or end of work. Apersonnel time event is characterized by a type such as “clock-inentry”, “clock-out entry”, or “start of break”. PreviousPreviousDelivery contains data about the physical Delivery delivery thatwas last received. Product A product is a commodity that is the objectof the business of a company and serves to create value for thiscompany. A product can be tangible or intangible, and can contain otherproducts or belong to another product (such as a set). A product canhave relationships to other products or objects. For example, a servicecan exist for a product that is specially manufactured or financing fora particular category of products. ProductActivity ProductActivitycontains specifications about the stock, ProductActivity demand, andconsumption of products of a buyer (retailers, wholesalers, ormanufacturers) at a ship-to location, and about the involved parties,for other relevant business documents and (optionally) for a ship-fromlocation. ProductActivity A ProductActivityItem contains specificationsabout ProductActivity Item the stock, demand, and/or consumption of aproduct in Item reference to a ship-to location and (optionally) a ship-from location. Product A product category is a division of productsaccording Category to objective business-specific criteria. Product AProduct Category Hierarchy is a hierarchy for Category structuringproduct categories. Depending on the Hierarchy business context,products are assigned to categories and arranged in hierarchies in orderto group similar products. ProductDemand A ProductDemandInfluencingEventdescribes a Influencing demand influencing event and its effects on theEvent demand. A ProductDemandInfluencingEvent specifies event dates andparticipating business partners. It is divided up into items that eachcontain the effects of the event on the expected sales quantities withregard to a ship-to party location and a product. ProductDemand AProductDemandInfluencingEventItem specifies for a Influencing ship-fromlocation (optional), a ship-to location, and a EventItem product thesales quantities expected on the basis of the demand influencing eventin the form of a time series. ProductForecast A ProductForecast is aforecast (or the revision of such ProductForecast a forecast) of thesale/demand of products in the form of time series between businesspartners. A ProductForecast consists of several items which can containinformation about the sales quantities predicted by the forecast foreach ship-to location and product. ProductForecast A ProductForecastItemspecifies (or revises) for a ship- ProductForecast Item from location(optional), a ship-to location, and a Item product the forecasted salesquantities in the form of a time series. ProductForecast AProductForecastNotification is a notice about future ProductForecastNotification product sales or demands (forecasts). ProductForecast AProductForecastNotificationItem specifies for a ship- ProductForecastNotification from location (optional), a ship-to location, and a ItemItem product the forecasted sales quantities in the form of a timeseries. ProductForecast A ProductForecastRevision is a revision of aforecast ProductForecast Revision of the sale/demand of products in theform of time series between business partners. A ProductForecastRevisionconsists of several items, which can contain information about the salesquantities predicted by the forecast for each ship-to location andproduct. ProductForecast A ProductForecastRevisionItem specifies for aship- RevisionItem from location (optional), a ship-to location, and aproduct the revision of the forecasted sales and purchase orderquantities in the form of a time series. Property A PROPERTY is anobject attribute. Property PropertyData PROPERTYDATATYPE is the datatype of a property. PropertyData Type It describes the syntax of thevalues and can contain a Type list of permitted values. Property APROPERTYDEFINITIONCLASS is a class for Property DefinitionClass definingproperties (in a classification system). DefinitionClass PurchaseOrder APurchaseOrder is a buyer's request to a seller to provide or delivercertain quantities of products at one or several dates. This can includea change (including confirmation or cancellation) of a purchase order orinformation about the status of the purchase order. The PurchaseOrder isdivided into PurchaseOrderItems that each specify an ordered product oradditional information relevant for such a product, such as informationabout bills of material (BOMs) or discount or value limits. In addition,to the buying party and the seller, additional parties can be involvedin the PurchaseOrder. Locations can be specified for the purchase orderdelivery. Delivery and payment terms also are agreed. Notes orreferences to attachments can be specified for the PurchaseOrder. Thetypes of follow-up documents that are expected with regard to thePurchaseOrder package also can be specified. PurchaseOrder APurchaseOrderCancellation is a buying party's PurchaseOrder Cancellation(buyer's) request to a provider (seller) to cancel a Cancellationpurchase order. PurchaseOrder A PurchaseOrderChange is a change made tothe PurchaseOrder Change buyer's request to the seller to deliver goodsor provide services. PurchaseOrder A PurchaseOrderConfirmation is aconfirmation, PurchaseOrder Confirmation partial confirmation, or achange sent from the seller to the buyer concerning the requesteddelivery of goods or provision of services. PurchaseOrder APurchaseOrderInformation is the information about PurchaseOrderInformation the status of a purchase order. This includes a purchaseInformation order change, confirmation, or cancellation. PurchaseOrder APurchaseOrderInformationItem specifies a product PurchaseOrderInformation ordered by the purchase order or additional informationInformationItem Item about ordered products. This information includesspecifications on discounts in kind, substitute products, and valuelimits. The PurchaseOrderInformationItem contains detailed informationabout a particular product and its price. The quantity of the productand (delivery) dates are specified in the schedule line. For thePurchaseOrderInformationItem (compared to the information of thePurchaseOrderInformation), deviating parties, locations, and deliveryterms can be defined. The PurchaseOrderInformationItem can containreferences to other business documents that are relevant for the item.Notes or references to attachments also can be specified for thePurchaseOrderInformationItem. A PurchaseOrderInformationItem can besubordinate to another PurchaseOrderInformationItem within a hierarchyto represent a business relationship between the two items. This couldbe information about a discount in kind or substitute product for anordered product, for example. This relationship also can be used togroup together purchase order items; that is, aPurchaseOrderInformationItem can group together otherPurchaseOrderInformationItems. PurchaseOrder A PurchaseOrderItemspecifies a product ordered by PurchaseOrder Item the PurchaseOrder oradditional information about such Item a product. This informationincludes specifications on discounts in kind, substitute products, andvalue limits. The PurchaseOrderItem contains detailed information abouta particular product and its price. The quantity of the product and(delivery) dates are specified in the schedule line. For thePurchaseOrderItem (compared to the information of the PurchaseOrder),deviating parties, locations, and delivery terms can be defined. ThePurchaseOrderItem can contain references to other business documentsthat are relevant for the item. Notes or references to attachments alsocan be specified for the item. A PurchaseOrderItem can be subordinate toanother PurchaseOrderInformationItem within a hierarchy to represent abusiness relationship between the two items. This could be informationabout a discount in kind or substitute product for an ordered product,for example. This relationship also can be used to group togetherPurchaseOrder items; that is, a PurchaseOrderItem can group togetherother PurchaseOrderItems. PurchaseOrder A PurchaseOrderRequest is abuyer's request to the PurchaseOrder Request seller to deliver goods orprovide services. PurchaseOrder A PurchaseOrderUpdate is a buyer'srequest to a seller PurchaseOrder Update to provide or deliver certainquantities of products on one or several dates. This can include achange or a confirmation of such a purchase order. Purchase APurchaseRequirement is a requirement for procuring Purchase Requirementproducts (materials or services). The Requirement PurchaseRequirement issubdivided into PurchaseRequirementItems that each specify an orderedproduct or additional information relevant for such a product, such asinformation about product category or value limits. In addition, to thebuying party and the seller as well as the proposed seller, additionalparties can be involved in the PurchaseRequirement. Locations can bespecified for the PurchaseRequirement delivery. Purchase APurchaseRequirementConfirmation is a confirmation Requirement of thebuyer that informs the requester of the extent to Confirmation which arequisition has been fulfilled. Purchase APurchaseRequirementConfirmationItem provides the Purchase Requirementextent to which an item of a requisition has been RequirementConfirmation fulfilled. ConfirmationItem Item Purchase APurchaseRequirementConfirmationItemExecuting Requirement PurchaseOrderis information on a PurchaseOrderItem, Confirmation which originatesfrom a PurchaseRequirementItem. ItemExecuting PurchaseOrder Purchase APurchaseRequirementItem specifies a product Purchase Requirementrequested by the PurchaseRequirement or provides RequirementItem Itemadditional information about such a product. The PurchaseRequirementItemcontains detailed information about a particular product and its price.The quantity of the product and (delivery) dates/times are specified inthe schedule line. For the PurchaseRequirementItem (compared to theinformation of the PurchaseRequirement), deviating parties or locationscan be defined. The PurchaseRequirementItem can contain references toother business documents that are relevant for the item. Notes orreferences to attachments also can be specified for the item. APurchaseRequirementItem can be subordinate to anotherPurchaseRequirementItem within a hierarchy to represent a businessrelationship between the two items. This could be information about asubstitute product for an ordered product, for example. Thisrelationship also can be used to group together PurchaseRequirementitems; that is, a PurchaseRequirementItem can group together otherPurchaseRequirementItems. Purchasing A PurchasingContract is a frameworkagreement with a Contract seller regarding the supply of products inacertain period of time. Purchasing A PurchasingContractRelease(purchasing contract ContractRelease release) is a notification frompurchasing to con-tract management regarding a performed release withreference to a purchasing contract. Purchasing APurchasingContractReleaseItem specifies a certain ContractRelease itemin a PurchasingContractRelease item or provides Item additionalinformation on such an item. This includes information on releasequantities and release amounts. Quote A Quote is a quotation submittedby a bidder to a buyer Quote in response to a request for quotation(RFQ) issued for a product by the buyer. The Quote is subdivided intoQuoteItems, which contain the concrete quotation submitted by the bidderwith reference to the relevant item in the buyer's REQ. QuoteItem AQuoteItem contains the bidder's quotation for a QuoteItem producttendered in an item of a request for quotation (RFQItem) or additionalinformation about this product. Quantities and delivery dates also canbe specified here. Received A ReceivedDelivery is the detailedconfirmation of the ReceivedDelivery Delivery receipt of a delivery.Received A ReceivedDeliveryItem describes which quantity of aDeliveryItem product was received. Replenishment A ReplenishmentOrder isan order that is planned by a Order vendor with the objective ofreplenishing products for a customer. Replenishment AReplenishmentOrderItem is an item in a OrderItem replenishment orderthat is planned and executed by a vendor for his or her customer. Thedates and quantities for delivering a certain product are described inthe individual items and schedule lines. The business partners involvedand (where applicable) references to other relevant business documentsare also listed. Replenishment A ReplenishmentOrderProposal is aproposal for a OrderProposal source location (for example, a vendor) todeliver certain quantities of products to a target location (goodsrecipient, for example, distribution center) at a spe-cific time, forreplenishment purposes. Replenishment A ReplenishmentOrderProposalItemgroups all OrderProposal information, the type, quantity and dates forthe Item products proposed for the replenishment purchase order.RequestFor A RequestForQuotation (RFQ) is a request from a Quotationbuyer to a bidder to submit a quotation for the products (RFQ) (goods orservices) specified in the RFQ. This can include a change or acancellation of such a RFQ. The RFQ is subdivided into RFQItems, whicheach contain a product specified for the RFQ or additional informationfor this product. In addition, to the buying party and the bidder,additional parties can be involved in the RFQ. The delivery locationalso can be specified. Delivery and payment terms also are agreed upon.The RFQ can contain a reference to a Quote if the bidder has a questionor if the buyer has changed the RFQ. Notes or references to attachmentscan be specified for the RFQ. RequestFor An RFQItem specifies a producttendered by an RFQ RFQItem QuotationItem (request for quotation) withadditional information on such a product. The RFQItem contains detailedinformation about a particular product. The quantity of the product and(delivery) dates/times are specified in the schedule line. For theRFQItem (compared to the information of the RFQ), deviating parties,locations, and delivery terms can be defined. The RFQItem can containreferences to other business documents that are relevant for the item.Notes or references to attachments also can be specified for theRFQItem. An RFQItem can be subordinate to another RFQItem within ahierarchy in order to represent a business relationship between the twoitems. RFQ An RFQCancellation is a cancellation of an RFQRFQCancellation Cancellation (request for quotation) to a bidder by abuyer. RFQChange An RFQChange is a change to the buyer's request to aRFQ bidder to submit a quotation for the products (goods or services)specified in the RFQ (request for quotation). RFQRequest An RFQRequestis a request from a buyer to a bidder RFQ to submit a quotation for theproducts (goods or services) specified in the RFQ (request forquotation). RFQResult An RFQResult is the acceptance or the rejection ofa RFQResult bidder's quotation by the buyer. RFQResultItem AnRFQResultItem specifies the rejection or the extent RFQResultItem of theacceptance of a bidder's quotation for a product of an RFQ item.RFQUpdate An RFQ Update is a request (or a change to a request) RFQ froma buyer to a bidder to submit a quotation for the products (goods orservices) specified in the RFQ (request for quotation). SalesContract ASalesContract is a framework agreement with a customer concerning thesupply of products in a certain period. SalesOrder A SalesOrder is therequest (or change or confirmation of such a request) to deliver certainquantities of products to a customer at one or several points in time.SalesOrder A SalesOrderFulfillmentRequest is a request (or SalesOrderFulfillment change and cancellation of such a request) to fulfill aFulfillment sales order and in doing so to take into account thelogistical requirements (availability check, scheduling, requirementsplanning, procurement, delivery, ...) of a sales order. TheSalesOrderFulfillment is divided up into SalesOrderFulfillmentItems thateach specify the product that is to be fulfilled or additionalinformation for such a product such as BOM information. Alongside thepurchasing party and the seller, other parties can be involved in theSalesOrderFulfillment. For the fulfillment of the SalesOrderFulfillment,locations can be determined and delivery methods can be agreed upon.Notes or references to attachments can be added to theSalesOrderFulfillment. Furthermore, it is possible to specify whichtypes of follow-up documents are expected with regard to theSalesOrderFulfillment. SalesOrder A SaleOrderFulfillmentItem specifies aproduct SalesOrder FulfillmentItem transferred by theSalesOrderFulfillment or additional FulfillmentItem information on sucha product. The SalesOrderFulfillmentItem contains detailed informationon a product and its batch. The quantity of the product and the(delivery) dates are specified in the schedule line. Deviating parties,locations and delivery methods can be specified for theSalesOrderFulfillmentItem (compared to the information of theSalesOrderFulfillment). The SalesOrderFulfillmentItem can containreferences to other business documents that are relevant for the item.Furthermore, notes or references to attachments can be added. ASalesOrderFulfillmentItem can be subordinate to anotherSalesOrderFulfillmentItem within a hierarchy in order to represent abusiness connection between the two items. This might, for example, bethe addition of a free-goods discount or a substitute product to anordered product. Scheduling SchedulingAgreement is an outline agreementbetween Agreement the customer and vendor that sets out the conditionsregarding quantities, time periods and prices for the purchasing anddelivery of goods. SellerProduct A SELLERPRODUCTCATALOGUE is a productCatalogue catalogue of a seller. Service A ServiceAcknowledgement is arequest from the Service Acknowledgement seller asking the buyer toacknowledge a service that Acknowledgement has been entered (or thebuyer's acknowledgement of the entered service). TheServiceAcknowledgement is subdivided into ServiceAcknowledgementItems,each of which specifies a service that has been entered or additionalinformation relevant for this service, such as hierarchy information. Inaddition, to the buyer and seller, other parties can participate in theServiceAcknowledgement. Locations can be defined for entering theServiceAcknowledgement. Notes or references to attachments can beincluded in the ServiceAcknowledgement. Service AServiceAcknowledgementItem specifies a service ServiceAcknowledgementItem (service product) entered by the AcknowledgementItemServiceAcknowledgement or additional information about the service(service product). In addition, to service products, materials that arerequired for fulfilling a service can be specified. TheServiceAcknowledgementItem contains detailed information about aproduct, its price, quantity, and date. For theServiceAcknowledgementItem (compared to the information of theServiceAcknowledgement), deviating parties and locations can be defined.The ServiceAcknowledgementItem can contain references to other businessdocuments relevant for the item. Notes or references to attachments alsocan be specified. A ServiceAcknowledgementItem can be subordinate toanother ServiceAcknowledgementItem within a hierarchy, therebyestablishing a business relationship between the two items. Thisrelationship also can be used to group together ServiceAcknowledgementitems; that is, a ServiceAcknowledgementItem can group together otherServiceAcknowledgementItems. Shipment A Shipment is a collection ofproducts that are transported together from a ship-from location toship- to location. SourceOf A SourceOfSupply is a procurement option fora SourceOfSupply Supply particular product or product category. Inparticular, it includes information about prices and ship-to/ship- fromlocations. TaxDue A TaxDue is information from a business documentTaxDue that is required in order to report or pay tax due to the taxauthorities. TaxDue contains information about the business partnerssubject to tax, the tax events based to which the business partners aresubject to tax/tax exempt, and about the type and amount of tax due.TaxDueItem A TaxDueItem is information from an item of a TaxDueItembusiness document that is required in order to report or pay tax due tothe tax authorities. TaxDueItem contains information about the businesspartners subject to tax, the tax events based on which the businesspartners are subject to tax/tax exempt, and about the type and amount oftax due. Transmission A TRANSMISSIONCATALOGUE is a new, changedTransmission Catalogue or deleted Catalogue for the purpose oftransmission. Catalogue VAT A VATDeclaration is a tax return for tax onDeclaration sales/purchases to a tax authority. VAT A VATDeclarationItemis detailed information on the DeclarationItem type and scope ofreported taxes on sales/purchases. Vendor A VendorGeneratedOrder is apurchase order that is GeneratedOrder planned and initiated by a vendorfor a customer and is intended to trigger a replenishment delivery forthe customer. Vendor A VendorGeneratedOrderItem describes when andGeneratedOrder where certain quantities of a product that is listed in aItem VendorGeneratedOrder will be delivered or can be picked up.VendorInvoice A VendorInvoice is an incoming invoice.

c) Packages

Packages group the entities in the business object model and theresulting interfaces into groups of semantically associated information.Packages also may include “sub”-packages, i.e., the packages may benested.

Packages may group elements together based on different factors, such aselements that occur together as a rule with regard to a business-relatedaspect. For example, as depicted in FIG. 252, in a Purchase Order,different information regarding the purchase order, such as the type ofpayment 25202, and payment card 25204, are grouped together via thePaymentInformation package 25200.

Packages also may combine different components that result in a newobject. For example, as depicted in FIG. 253, the components wheels25304, motor 25306, and doors 25308 are combined to form a composition“Car” 25302. The “Car” package 25300 includes the wheels, motor anddoors as well as the composition “Car.”

Another grouping within a package may be subtypes within a type. Inthese packages, the components are specialized forms of a genericpackage. For example, as depicted in FIG. 254, the components Car 25404,Boat 25406, and Truck 25408 can be generalized by the generic termVehicle 25402 in Vehicle package 25400. Vehicle in this case is thegeneric package 25410, while Car 25412, Boat 25414, and Truck 25416 arethe specializations 25418 of the generalized vehicle 25410.

Packages also may be used to represent hierarchy levels. For example, asdepicted in FIG. 255, the Item Package 25500 includes Item 25502 withsubitem xxx 25504, subitem yyy 25506, and subitem zzz 25508.

Packages can be represented in the XML schema as a comment. Oneadvantage of this grouping is that the document structure is easier toread and is more understandable. The names of these packages areassigned by including the object name in brackets with the suffix“Package.” For example, as depicted in FIG. 256, Party package 25600 isenclosed by <PartyPackage> 25602 and </PartyPackage> 25604. Partypackage 25600 illustratively includes a Buyer Party 25606, identified by<BuyerParty> 25608 and </BuyerParty> 25610, and a Seller Party 25612,identified by <SellerParty> 25614 and </SellerParty>, etc.

d) Relationships

Relationships describe the interdependencies of the entities in thebusiness object model, and are thus an integral part of the businessobject model.

(1) Cardinality of Relationships

FIG. 257 depicts a graphical representation of the cardinalities betweentwo entities. The cardinality between a first entity and a second entityidentifies the number of second entities that could possibly exist foreach first entity. Thus, a 1:c cardinality 25700 between entities A25702 and X 25704 indicates that for each entity A 25702, there iseither one or zero 25706 entity X 25704. A 1:1 cardinality 25708 betweenentities A 25710 and X 25712 indicates that for each entity A 25710,there is exactly one 25714 entity X 25712. A 1:n cardinality 25716between entities A 25718 and X 25720 indicates that for each entity A25718, there are one or more 25722 entity Xs 25720. A 1:cn cardinality25724 between entities A 25726 and X 25728 indicates that for eachentity A 25726, there are any number 25730 of entity Xs 25728 (i.e., 0through n Xs for each A).

(2) Types of Relationships

(a) Composition

A composition or hierarchical relationship type is a strong whole-partrelationship which is used to describe the structure within an object.The parts, or dependent entities, represent a semantical refinement orpartition of the whole, or less dependent entity. For example, asdepicted in FIG. 258, the components 25802 wheels 25804 and doors 25806may be combined to form the composite 25800 “Car” 25808 using thecomposition 25810. FIG. 259 depicts a graphical representation of thecomposition 25910 between composite Car 25908 and components wheel 25904and door 25906.

(b) Aggregation

An aggregation or an aggregating relationship type is a weak whole-partrelationship between two objects. The dependent object is created by thecombination of one or several less dependent objects. For example, asdepicted in FIG. 260, the properties of a competitor product 26000 aredetermined by a product 26002 and a competitor 26004. A hierarchicalrelationship 26006 exists between the product 26002 and the competitorproduct 26000 because the competitor product 26000 is a component of theproduct 26002. Therefore, the values of the attributes of the competitorproduct 26000 are determined by the product 26002. An aggregatingrelationship 26008 exists between the competitor 26004 and thecompetitor product 26000 because the competitor product 26000 isdifferentiated by the competitor 26004. Therefore the values of theattributes of the competitor product 26000 are determined by thecompetitor 26004.

(c) Association

An association or a referential relationship type describes arelationship between two objects in which the dependent object refers tothe less dependent object. For example, as depicted in FIG. 261, aperson 26100 has a nationality, and thus, has a reference to its country26102 of origin. There is an association 26104 between the country 26102and the person 26100. The values of the attributes of the person 26100are not determined by the country 26102.

(3) Specialization

Entity types may be divided into subtypes based on characteristics ofthe entity types. For example, FIG. 262 depicts an entity type “vehicle”26200 specialized 26202 into subtypes “truck” 26204, “car” 26206, and“ship” 26208. These subtypes represent different aspects or thediversity of the entity type.

Subtypes may be defined based on related attributes. For example,although ships and cars are both vehicles, ships have an attribute,“draft,” that is not found in cars. Subtypes also may be defined basedon certain methods that can be applied to entities of this subtype andthat modify such entities. For example, “drop anchor” can be applied toships. If outgoing relationships to a specific object are restricted toa subset, then a subtype can be defined which reflects this subset.

As depicted in FIG. 263, specializations may further be characterized ascomplete specializations 26300 or incomplete specializations 26302.There is a complete specialization 26300 where each entity of thegeneralized type belongs to at least one subtype. With an incompletespecialization 26302, there is at least one entity that does not belongto a subtype. Specializations also may be disjoint 26304 or nondisjoint26306. In a disjoint specialization 26304, each entity of thegeneralized type belongs to a maximum of one subtype. With a nondisjointspecialization 26306, one entity may belong to more than one subtype. Asdepicted in FIG. 263, four specialization categories result from thecombination of the specialization characteristics.

e) Structural Patterns

(1) Item

An item is an entity type which groups together features of anotherentity type. Thus, the features for the entity type chart of accountsare grouped together to form the entity type chart of accounts item. Forexample, a chart of accounts item is a category of values or value flowsthat can be recorded or represented in amounts of money in accounting,while a chart of accounts is a superordinate list of categories ofvalues or value flows that is defined in accounting.

The cardinality between an entity type and its item is either 1:n or1:cn. In the case of the entity type chart of accounts, there is ahierarchical relationship of the cardinality 1:n with the entity typechart of accounts item since a chart of accounts has at least one itemin all cases.

(2) Hierarchy

A hierarchy describes the assignment of subordinate entities tosuperordinate entities and vice versa, where several entities of thesame type are subordinate entities that have, at most, one directlysuperordinate entity. For example, in the hierarchy depicted in FIG.264, entity B 26402 is subordinate to entity A 26400, resulting in therelationship (A,B) 26412. Similarly, entity C 26404 is subordinate toentity A 26400, resulting in the relationship (A,C) 26414. Entity D26406 and entity E 26408 are subordinate to entity B 26402, resulting inthe relationships (B,D) 26416 and (B,E) 26418, respectively. Entity F26410 is subordinate to entity C 26404, resulting in the relationship(C,F) 26420.

Because each entity has at most one superordinate entity, thecardinality between a subordinate entity and its superordinate entity is1:c. Similarly, each entity may have 0, 1 or many subordinate entities.Thus, the cardinality between a superordinate entity and its subordinateentity is 1:cn. FIG. 265 depicts a graphical representation of a ClosingReport Structure Item hierarchy 26500 for a Closing Report StructureItem 26502. The hierarchy illustrates the 1:c cardinality 26504 betweena subordinate entity and its superordinate entity, and the 1:cncardinality 26506 between a superordinate entity and its subordinateentity.

3. Creation of the Business Object Model

FIGS. 266A-B depict the steps performed using methods and systemsconsistent with the subject matter described herein to create a businessobject model. Although some steps are described as being performed by acomputer, these steps may alternatively be performed manually, orcomputer-assisted, or any combination thereof. Likewise, although somesteps are described as being performed by a computer, these steps mayalso be computer-assisted, or performed manually, or any combinationthereof.

As discussed above, the designers create message choreographies thatspecify the sequence of messages between business entities during atransaction. After identifying the messages, the developers identify thefields contained in one of the messages (step 26600, FIG. 266A). Thedesigners then determine whether each field relates to administrativedata or is part of the object (step 26602). Thus, the first elevenfields identified below in the left column are related to administrativedata, while the remaining fields are part of the object. MessageID AdminReferenceID CreationDate SenderID AdditionalSenderID ContactPersonIDSenderAddress RecipientID AdditionalRecipientID ContactPersonIDRecipientAddress ID Main Object AdditionalID PostingDate LastChangeDateAcceptanceStatus Note CompleteTransmission Indicator BuyerBuyerOrganisationName Person Name FunctionalTitle DepartmentNameCountryCode StreetPostalCode POBox Postal Code Company Postal Code CityName DistrictName PO Box ID PO Box Indicator PO Box Country Code PO BoxRegion Code PO Box City Name Street Name House ID Building ID Floor IDRoom ID Care Of Name AddressDescription Telefonnumber MobileNumberFacsimile Email Seller SellerAddress Location LocationTypeDeliveryItemGroupID DeliveryPriority DeliveryCondition TransferLocationNumberofPartialDelivery QuantityTolerance MaximumLeadTimeTransportServiceLevel TranportCondition TransportDescriptionCashDiscountTerms PaymentForm PaymentCardID PaymentCardReferenceIDSequenceID Holder ExpirationDate AttachmentID AttachmentFilenameDescriptionofMessage ConfirmationDescriptionof Message FollowUpActivityItemID ParentItemID HierarchyType ProductID ProductType ProductNoteProductCategoryID Amount BaseQuantity ConfirmedAmountConfirmedBaseQuantity ItemBuyer ItemBuyerOrganisationName Person NameFunctionalTitle DepartmentName CountryCode StreetPostalCode POBox PostalCode Company Postal Code City Name DistrictName PO Box ID PO BoxIndicator PO Box Country Code PO Box Region Code PO Box City Name StreetName House ID Building ID Floor ID Room ID Care Of NameAddressDescription Telefonnumber MobilNumber Facsimile Email ItemSellerItemSellerAddress ItemLocation ItemLocationType ItemDeliveryItemGroupIDItemDeliveryPriority ItemDeliveryCondition ItemTransferLocationItemNumberofPartialDelivery ItemQuantityTolerance ItemMaximumLeadTimeItemTransportServiceLevel ItemTranportCondition ItemTransportDescriptionContractReference QuoteReference CatalogueReference ItemAttachmentIDItemAttachmentFilename ItemDescription ScheduleLineID DeliveryPeriodQuantity ConfirmedScheduleLineID ConfirmedDeliveryPeriodConfirmedQuantity

Next, the designers determine the proper name for the object accordingto the ISO 11179 naming standards (step 26604). In the example above,the proper name for the “Main Object” is “Purchase Order.” After namingthe object, the system that is creating the business object modeldetermines whether the object already exists in the business objectmodel (step 26606). If the object already exists, the system integratesnew attributes from the message into the existing object (step 26608),and the process is complete.

If at step 26606 the system determines that the object does not exist inthe business object model, the designers model the internal objectstructure (step 26610). To model the internal structure, the designersdefine the components. For the above example, the designers may definethe components identified below. ID Purchase AdditionalID OrderPostingDate LastChangeDate AcceptanceStatus Note CompleteTransmissionIndicator Buyer Buyer BuyerOrganisationName Person Name FunctionalTitleDepartmentName CountryCode StreetPostalCode POBox Postal Code CompanyPostal Code City Name DistrictName PO Box ID PO Box Indicator PO BoxCountry Code PO Box Region Code PO Box City Name Street Name House IDBuilding ID Floor ID Room ID Care Of Name AddressDescriptionTelefonnumber MobileNumber Facsimile Email Seller Seller SellerAddressLocation Location LocationType DeliveryItemGroupID DeliveryDeliveryPriority Terms DeliveryCondition TransferLocationNumberofPartialDelivery QuantityTolerance MaximumLeadTimeTransportServiceLevel TranportCondition TransportDescriptionCashDiscountTerms PaymentForm Payment PaymentCardIDPaymentCardReferenceID SequenceID Holder ExpirationDate AttachmentIDAttachmentFilename DescriptionofMessage ConfirmationDescriptionofMessage FollowUpActivity ItemID Purchase ParentItemID OrderHierarchyType Item ProductID Product ProductType ProductNoteProductCategoryID ProductCategory Amount BaseQuantity ConfirmedAmountConfirmedBaseQuantity ItemBuyer Buyer ItemBuyerOrganisation Name PersonName FunctionalTitle DepartmentName CountryCode StreetPostalCode POBoxPostal Code Company Postal Code City Name DistrictName PO Box ID PO BoxIndicator PO Box Country Code PO Box Region Code PO Box City Name StreetName House ID Building ID Floor ID Room ID Care Of NameAddressDescription Telefonnumber MobilNumber Facsimile Email ItemSellerSeller ItemSellerAddress ItemLocation Location ItemLocationTypeItemDeliveryItemGroupID ItemDeliveryPriority ItemDeliveryConditionItemTransferLocation ItemNumberofPartial Delivery ItemQuantityToleranceItemMaximumLeadTime ItemTransportServiceLevel ItemTranportConditionItemTransportDescription ContractReference Contract QuoteReference QuoteCatalogueReference Catalogue ItemAttachmentID ItemAttachmentFilenameItemDescription ScheduleLineID DeliveryPeriod QuantityConfirmedScheduleLineID ConfirmedDeliveryPeriod ConfirmedQuantity

During the step of modeling the internal structure, the designers alsomodel the complete internal structure by identifying the compositions ofthe components and the corresponding cardinalities, as shown below.PurchaseOrder 1 Buyer 0..1 Address 0..1 ContactPerson 0..1 Address 0..1Seller 0..1 Location 0..1 Address 0..1 DeliveryTerms 0..1 Incoterms 0..1PartialDelivery 0..1 QuantityTolerance 0..1 Transport 0..1CashDiscountsTerms 0..1 MaximumCashDiscount 0..1 NormalCashDiscount 0..1PaymentForm 0..1 PaymentCard 0..1 Attachment 0..n Description 0..1Confirmation 0..1 Description Item 0..n HierarchyRelationship 0..1Product 0..1 ProductCategory 0..1 Price 0..1 NetUnitPrice 0..1ConfirmedPrice 0..1 NetUnitPrice 0..1 Buyer 0..1 Seller 0..1 Location0..1 DeliveryTerms 0..1 Attachment 0..n Description 0..1ConformationDescription 0..1 ScheduleLine 0..n DeliveryPeriod 1ConfirmedScheduleLine 0..n

After modeling the internal object structure, the developers identifythe subtypes and generalizations for all objects and components (step26612). For example, the Purchase Order may have subtypes Purchase OrderUpdate, Purchase Order Cancellation and Purchase Order Information.Purchase Order Update may include Purchase Order Request, Purchase OrderChange, and Purchase Order Confirmation. Moreover, Party may beidentified as the generalization of Buyer and Seller. The subtypes andgeneralizations for the above example are shown below. PurchaseOrder 1PurchaseOrder Update PurchaseOrder Request PurchaseOrder ChangePurchaseOrder Confirmation PurchaseOrder Cancellation PurchaseOrderInformation Party BuyerParty 0..1 Address 0..1 ContactPerson 0..1Address 0..1 SellerParty 0..1 Location ShipToLocation 0..1 Address 0..1ShipFromLocation 0..1 Address 0..1 DeliveryTerms 0..1 Incoterms 0..1PartialDelivery 0..1 QuantityTolerance 0..1 Transport 0..1 CashDiscount0..1 Terms MaximumCash 0..1 Discount NormalCashDiscount 0..1 PaymentForm0..1 PaymentCard 0..1 Attachment 0..n Description 0..1 Confirmation 0..1Description Item 0..n HierarchyRelationship 0..1 Product 0..1ProductCategory 0..1 Price 0..1 NetUnitPrice 0..1 ConfirmedPrice 0..1NetUnitPrice 0..1 Party BuyerParty 0..1 SellerParty 0..1 Location ShipTo0..1 Location ShipFrom 0..1 Location DeliveryTerms 0..1 Attachment 0..nDescription 0..1 Confirmation 0..1 Description ScheduleLine 0..nDelivery 1 Period ConfirmedScheduleLine 0..n

After identifying the subtypes and generalizations, the developersassign the attributes to these components (step 26614). The attributesfor a portion of the components are shown below. Purchase 1 Order ID 1SellerID 0..1 BuyerPosting 0..1 DateTime BuyerLast 0..1 ChangeDate TimeSellerPosting 0..1 DateTime SellerLast 0..1 ChangeDate Time Acceptance0..1 StatusCode Note 0..1 ItemList 0..1 Complete Transmission IndicatorBuyerParty 0..1 StandardID 0..n BuyerID 0..1 SellerID 0..1 Address 0..1ContactPerson 0..1 BuyerID 0..1 SellerID 0..1 Address 0..1 SellerParty0..1 Product 0..1 RecipientParty VendorParty 0..1 Manufacturer 0..1Party BillToParty 0..1 PayerParty 0..1 CarrierParty 0..1 ShipTo 0..1Location StandardID 0..n BuyerID 0..1 SellerID 0..1 Address 0..1ShipFrom 0..1 Location

The system then determines whether the component is one of the objectnodes in the business object model (step 26616, FIG. 266B). If thesystem determines that the component is one of the object nodes in thebusiness object model, the system integrates a reference to thecorresponding object node from the business object model into the object(step 26618). In the above example, the system integrates the referenceto the Buyer party represented by an ID and the reference to theShipToLocation represented by an into the object, as shown below. Theattributes that were formerly located in the PurchaseOrder object arenow assigned to the new found object party. Thus, the attributes areremoved from the PurchaseOrder object. PurchaseOrder ID SellerIDBuyerPostingDateTime BuyerLastChangeDateTime SellerpostingDateTimeSellerLastChangeDateTime AcceptanceStatusCode Note ItemListCompleteTransmissionIndicator BuyerParty ID SellerParty ProductRecipientPartyVendorParty ManufacturerParty BillToParty PayerParty CarrierPartyShipToLocation ID ShipFromLocation

During the integration step, the designers classify the relationship(i.e., aggregation or association) between the object node and theobject being integrated into the business object model. The system alsointegrates the new attributes into the object node (step 26620). If atstep 26616, the system determines that the component is not in thebusiness object model, the system adds the component to the businessobject model (step 26622).

Regardless of whether the component was in the business object model atstep 26616, the next step in creating the business object model is toadd the integrity rules (step 26624). There are several levels ofintegrity rules and constraints which should be described. These levelsinclude consistency rules between attributes, consistency rules betweencomponents, and consistency rules to other objects. Next, the designersdetermine the services offered, which can be accessed via interfaces(step 26626). The services offered in the example above includePurchaseOrderCreateRequest, PurchaseOrderCancellationRequest, andPurchaseOrderReleaseRequest. The system then receives an indication ofthe location for the object in the business object model (step 26628).After receiving the indication of the location, the system integratesthe object into the business object model (step 26630).

4. Structure of the Business Object Model

The business object model, which serves as the basis for the process ofgenerating consistent interfaces, includes the elements contained withinthe interfaces. These elements are arranged in a hierarchical structurewithin the business object model.

FIGS. 267A-NN depict an exemplary Business Object Model in accordancewith methods and systems consistent with the subject matter describedherein. The business object model includes a BusinessObjectModel package26700, which includes a BusinessObjectModel—Customizing package 26702, aBusinessObjectModel—Strategic package 26704, and aBusinessObjectModel—Operative package 26706.

The BusinessObjectModel—Customizing package 26702 includes an Incoterrnspackage 26708. The Incoterms package 26708 includes an Incoterms entity26710.

The BusinessObjectModel—Strategic package 26704 includes aPropertyDefinitionClass package 26712, a PropertyDataType package 26714,a Property package 26716, a Catalogue package 26718, an Address package26720, and an Attachment package 26722. The PropertyDefinitionClasspackage 26712 includes a PropertyDefinitionClass entity 26724. ThePropertyDataType package 26714 includes a PropertyDataType entity 26726.There is a 1:n relationship 26728 between the PropertyDefinitionClassentity 26724 and the PropertyDataType entity 26726. There is a 1:crelationship 26730 between the PropertyDataType entity 26728 and thePropertyDefinitionClass entity 26724. Thus, in some cases, there is aninstance of the PropertyDataType entity 26728 with a reference to thePropertyDefinitionClass entity 26724.

The Property package includes a Property entity 26734. There is a 1:cnrelationship 26734 between the PropertyDataType entity 26728 and theProperty entity 26732. There is also a 1:c referential relationship26736 between the PropertyDataType entity 26728 and the Property entity26736.

The Address package 26720 includes an Address entity 26737. The Addressentity 26737 includes an AddressPersonName entity 26738, anAddressOffice entity 26740, an AddressPhysicalAddress entity 26742, anAddressGeoCoordinates entity 26744, and an AddressCommunication entity26746. There is a 1:c relationship 26748 between the Address entity26737 and the AddressPersonName entity 26738. There is a 1:crelationship 26750 between the Address entity 26737 and theAddressOffice entity 26740. There is a 1:c relationship 26752 betweenthe Address entity 26737 and the AddressPhysicalAddress entity 26742.There is a 1:c relationship 26754 between the Address entity 26737 andthe AddressGeoCoordinates entity 26744. There is a 1:c relationship26756 between the Address entity 26737 and the AddressCommunicationentity 26746.

The Attachment package 26722 includes an Attachment entity 26758.

The Catalogue package 26718 includes a CatalogueGlobalInformationpackage 26760, a CatalogueModel package 26762, and a CatalogueContentpackage 26764. The Catalogue package 26718 also includes a Catalogueentity 26766. The Catalogue entity 26766 is specialized into aTransmissionCatalogue entity 26768 and aCataloguePublicationConfirmation entity 26770, which are disjointcomplete specializations 26772 of the Catalogue entity 26766. TheTransmissionCatalogue entity 26768 is specialized into a CatalogueUpdateentity 26774 and a CataloguePublication entity 26776, which are disjointcomplete specializations 26778 of the TransmissionCatalogue entity26768. The Catalogue entity 26766 is also specialized into aBuyerProductCatalogue entity 26780 and a SellerProductCatalogue entity26782, which are disjoint complete specializations 26784 of theCatalogue entity 26766.

The CatalogueGlobalInformation package 26760 includes aCatalogueProviderPropertyValuation entity 26786. There is a 1:cnrelationship 26788 between the Catalogue entity 26766 and theCatalogueProviderPropertyValuation entity 26786.

The CatalogueModel package 26762 includes a CatalogueModel entity 26790.There is a 1:c relationship 26792 between the Catalogue entity 26766 andthe CatalogueModel entity 26790.

The CatalogueContent package 26764 includes a CatalogueContent entity26794. There is a 1:c relationship 26796 between the Catalogue entity26766 and the CatalogueContent entity 26794.

The CatalogueModel package 26762 includes aCatalogueModelPropertyDefinitionClass package 26798, aCatalogueModelPropertyDataType package 26700A, a CatalogueModelPropertypackage 26702A, a CatalogueModelCatalogueItemProperty package 26704A, aCatalogueModelCatalogueSectionType package 26706A, and aCatalogueModelCatalogueSchema package 26708A.

The CatalogueModelPropertyDefinitionClass package 26798 includes aCatalogueModelPropertyDefinitionClass entity 26710A. There is a 1:cnrelationship 26714A between the PropertyDefinitionClass entity 26724 andthe CatalogueModelPropertyDefinitionClass entity 26710A, and a 1:cnrelationship 26712A between the CatalogueModel entity 26790 and theCatalogueModelPropertyDefinitionClass entity 26710A.

The CatalogueModelPropertyDataType package 26700A includes aCatalogueModelPropertyDataType entity 26716A. There is a 1:cnrelationship 26718A between the CatalogueModel entity 26790 and theCatalogueModelPropertyDataType entity 26716A. There is a 1:cnrelationship 26720A between the PropertyDataType entity 26726 and theCatalogueModelPropertyDataType entity 26716A.

The CatalogueModelProperty package 26702A includes aCatalogueModelProperty entity 26722A. There is a 1:cn relationship26726A between the Property entity 26732 and the CatalogueModelPropertyentity 26722A. There is a 1:cn relationship 26724A between theCatalogueModel entity 26790 and the CatalogueModelProperty entity26722A.

The CatalogueModelCatalogueItemProperty package 26704A includes aCatalogueModelPropertyDataType entity 26728A. There is a 1:cnrelationship 26730A between the CatalogueModel entity 26790 and theCatalogueModelPropertyDataType entity 26728A.

The CatalogueModelCatalogueSectionType package 26706A includes aCatalogueModelCatalogueSectionType entity 26732A. There is a 1:cnrelationship 26734A between the CatalogueModel entity 26790 and theCatalogueModelCatalogueSectionType entity 26732A. TheCatalogueModelCatalogueSectionType entity 26732A includes aCatalogueModelCatalogueSectionTypeSectionProperty entity 26736A. Thereis a 1:cn relationship 26738A between theCatalogueModelCatalogueSectionType entity 26732A and theCatalogueModelCatalogueSectionTypeSectionProperty entity 26736A.

The CatalogueModelCatalogueSchema package 26708A includes aCatalogueModelCatalogueSchema entity 26740A. There is a 1:cnrelationship 26742A between the CatalogueModel entity 26790 and theCatalogueModelCatalogueSchema entity 26740A. TheCatalogueModelCatalogueSchema entity 26740A includes aCatalogueModelCatalogueSchemaItemProperty entity 26744A, aCatalogueModelCatalogueSchemaSection entity 26746A, and aCatalogueModelCatalogueSchemaSectionRelationship entity 26748A. There isa 1:cn relationship 26750A between the CatalogueModelCatalogueSchemaentity 26740A and the CatalogueModelCatalogueSchemaItemProperty entity26744A. There is a 1:cn relationship 26752A between theCatalogueModelCatalogueSchema entity 26740A and theCatalogueModelCatalogueSchemaSection entity 26746A. There is a 1:cnrelationship 26754A between the CatalogueModelCatalogueSchema entity26740A and the CatalogueModelCatalogueSchemaSectionRelationship entity26748A.

The CatalogueModelCatalogueSchemaSection entity 26746A includes aCatalogueModelCatalogueSchemaSectionPropertyValuation entity 26756A anda CatalogueModelCatalogueSchemaSectionItemProperty entity 26758A. Thereis a 1:cn relationship 26760A between theCatalogueModelCatalogueSchemaSection entity 26746A and theCatalogueModelCatalogueSchemaSectionPropertyValuation entity 26756A.There is a 1:cn relationship 26762A between theCatalogueModelCatalogueSchemaSection entity 26746A and theCatalogueModelCatalogueSchemaSectionItemProperty entity 26758A.

The CatalogueContent package 26764 includes aCatalogueContentCatalogueItem package 26764A and aCatalogueContentCatalogueView package 26766A.

The CatalogueContentCatalogueItem package 26764A includes aCatalogueContentCatalogueItem entity 26768A and aCatalogueContentCatalogueItemRelationship entity 26774A. There is a 1:cnrelationship 26772A between the CatalogueContent entity 26794 and theCatalogueContentCatalogueItem entity 26768A. There is a 1:cnrelationship 26774A between the CatalogueContent entity 26794 and theCatalogueContentCatalogueItemRelationship entity 26770A. TheCatalogueContentCatalogueItem entity 26768A includes aCatalogueContentCatalogueItemDescription entity 26776A, aCatalogueContentCatalogueItemPropertyValuation entity 26778A, and aCatalogueContentCatalogueItemClassification entity 26780A. There is a1:cn relationship 26782A between the CatalogueContentCatalogueItementity 26768A and the CatalogueContentCatalogueItemDescription entity26776A. There is a 1:cn relationship 26784A between theCatalogueContentCatalogueItem entity 26768A and theCatalogueContentCatalogueItemPropertyValuation entity 26778A. There is a1:cn relationship 26786A between the CatalogueContentCatalogueItementity 26768A and the CatalogueContentCatalogueItemClassification entity26780A.

The CatalogueContentCatalogueView package 26766A includes aCatalogueContentCatalogueView entity 26788A. There is a 1:cnrelationship 26790A between the CatalogueContent entity 26794 and theCatalogueContentCatalogueView entity 26788A.

The CatalogueContentCatalogueView entity 26788A includes aCatalogueContentCatalogueViewSchema entity 26792A, aCatalogueContentCatalogueViewItem entity 26794A, aCatalogueContentCatalogueViewItemRelationshipType entity 26796A, and aCatalogueContentCatalogueViewExcludedProperty entity 26798A. There is a1:cn relationship 26700B between the CatalogueContentCatalogueViewentity 26788A and the CatalogueContentCatalogueViewSchema entity 26792A.There is a 1:cn relationship 26702B between theCatalogueContentCatalogueView entity 26788A and theCatalogueContentCatalogueViewItem entity 26794A. There is a 1:cnrelationship 26704B between the CatalogueContentCatalogueView entity26788A and the CatalogueContentCatalogueViewItemRelationshipType entity26796A. There is a 1:cn relationship 26706B between theCatalogueContentCatalogueView entity 26788A and theCatalogueContentCatalogueViewExcludedProperty entity 26798A.

The CatalogueContentCatalogueViewSchema entity 26792A includes aCatalogueContentCatalogueViewSchemaSection entity 26780A. There is a1:cn relationship 26710B between the CatalogueContentCatalogueViewSchemaentity 26792A and the CatalogueContentCatalogueViewSchemaSection entity26780A.

The Business Object Model Operative package 26706 includes aBusinessTransactionDocument package 26712B, and aCataloguePublicationTransmission package 26714B.

The BusinessTransactionDocument package 26712B includes aBTDCreditWorthinessInformation package 26718B, aBTDCreditAgencyReportQueryService package 26720B, a BTDLegalInformationpackage 26722B, a BTDScheduling package 26724B, aBTDTransportInformation package 26726B, a BTDHandlingUnit package26728B, a BTDLog package 26730B, aBTDFollowUpBusinessTransactionDocument package 26732B, aBTDFollowUpMessage package 26734B, a BTDLoanPaymentPlan pakcage 26735B,a BTDItem package 26736B, a BTDPriceInformation package 26738B, aBTDPaymentInformation package 26740B, a BTDTax package 26742B, aBTDDeliveryInformation package 26744B, a BTDDeliveryExecutionInformationpackage 26746B, a BTDAccountingObjectSet package 26748B, aBTDBusinessDocumentObjectReference package 26750B, a BTDAttachmentpackage 26752B, a BTDDescription package 26754B, a BTDParty package26756B, a BTDLocation package 26758B, a BTDProductInformation package26759B, a BTDLoanConditionInformation package 26760B, and aPersonnelTimeSubsheet package 26761B.

The BusinessTransactionDocument package 26712B also includes aBusinessTransactionDocument entity 26762B. TheBusinessTransactionDocument entity 26762B is specialized into anInventoryChange entity 26764B, a SourceOfSupply entity 26766B, aCreditAgencyReportQuery entity 26768B, a CreditAgencyReport entity26770B, a CreditWorthinessQuery entity 26772B, a CreditWorthiness entity26774B, a ProductActivity entity 26776B, a ProductDemandlnfluencingEvententity 26778B, a ProductForecast entity 26780B, a RequestForQuotation(RFQ) entity 26782B, an RFQResult entity 26784B, a Quote entity 26786B,a SalesContract entity 26788B, a PurchaseContract entity 26790B, aSchedulingAgreement entity 26792B, a PurchaseRequirement entity 26794B,a PurchaseRequirementConfirmation entity 26796B, a PurchaseOrder entity26798B, a SalesOrder entity 26700C, a SalesOrderFulfillment entity26702C, a ServiceAcknowledgement entity 26704C, aDeliveryExecutionRequest entity 26706C, a Delivery entity 26708C, aShipment entity 26710C, a PaymentDue entity 26712C, an InvoiceDue entity26714C, an InvoiceDueCancellation entity 26716C, an Invoice entity26718C, an InvoiceIssued entity 26720C, an InvoiceAccounting entity26722C, an AccountingCancellation entity 26724C, a VendorInvoice entity26726C, and a TaxDue entity 26728C, which are disjoint completespecializations 26730C of the BusinessTransactionDocument entity 26762B.

The ProductForecast entity 26780B is specialized into aProductForecastNotification entity 26732C and a ProductForecastRevisionentity 26734C, which are disjoint complete specializations 26736C of theProductForecast entity 26780B.

The RFQ entity 26782B is specialized into a RFQUpdate entity 26738C anda RFQCancellation entity 26740C, which are nondisjoint completespecializations 26742C of the RFQ entity 26782B. The RFQUpdate entity26738C is specialized into a RFQRequest entity 26744C and a RFQChargeentity 26746C, which are nondisjoint complete specializations 26748C ofthe RFQUpdate entity 26738C.

The PurchaseOrder entity 26798B is specialized into aPurchaseOrderUpdate entity 26750C, a PurchaseOrderCancellation entity26752C, and a PurchaseOrderInformation entity 26754C, which arenondisjoint complete specializations 26756C of the PurchaseOrder entity26798B. The PurchaseOrderUpdate entity 26750C is specialized into aPurchaseOrderRequest entity 26758C, a PurchaseOrderChange entity 26760C,and a PurchaseOrderConfirmation entity 26762C, which are nondisjointcomplete specializations 26764C of the PurchaseOrderUpdate entity26750C.

The Delivery entity 26708C is specialized into a PendingDelivery entity26766C, an InboundDelivery entity 26768C, a ReceivedDelivery entity26770C, a DeliveryInformation entity 26772C, and aDespatchedDeliveryNotification entity 26774C, which are nondisjointcomplete specializations 26776C of the Delivery entity 26708C.

The AccountingCancellation entity 26724C is specialized into anInventoryChargeAccountingCancellation entity 26778C and anInvoiceAccountingCancellation entity 26780C, which are disjoint completespecializations 26782C of the AccountingCancellation entity 26724C.

The BTDCreditWorthinessInformation package 26718B includes aBTDCreditRating entity 26784C, a BTDCreditRiskClass entity 26786C, aBTDCreditAgencyReportScoring entity 26788C, and a BTDCreditLimit entity26790C. There is a 1:1 relationship 26792C between theBusinessTransactionDocument entity 26762B and the BTDCreditRating entity26784C. There is a 1:c relationship 26794C between theBusinessTransactionDocument entity 26762B and the BTDCreditRiskClassentity 26786C. There is a 1:cn relationship 26796C between theBusinessTransactionDocument entity 26762B and theBTDCreditAgencyReportScoring entity 26788C. There is a 1:cn relationship26798C between the BusinessTransactionDocument entity 26762B and theBTDCreditLimit entity 26790C.

The BTDCreditAgencyReportQueryService package 26720B includes aCreditAgencyReportQueryService entity 26700D. There is a 1:1relationship 26702D between the BusinessTransactionDocument entity26762B and the CreditAgencyReportQueryService entity 26700D.

The BTDLegalInformation package 26722B includes a BTDLegalEvent entity26704D. There is a 1:cn relationship 26706D between theBusinessTransactionDocument entity 26762B and the BTDLegalEvent entity26704D.

The BTDScheduling package 26724B includes a BTDScheduling entity 26708D.There is a 1:c relationship 26710D between theBusinessTransactionDocument entity 26762B and the BTDScheduling entity26708D.

The BTDTransportInformation package 26726B includes a BTDTransportMeansentity 26712D and a BTDTransportTracking entity 26714D. There is a 1:crelationship 2671.6D between the BusinessTransactionDocument entity26762B and the BTDTransportMeans entity 26712D. There is a 1:crelationship 26718D between the BusinessTransactionDocument entity26762B and the BTDTransportTracking entity 26714D.

The BTDHandlingUnit package 26728B includes a BTDHandlingUnit entity26720D. There is a 1:cn relationship 26722D between theBusinessTransactionDocument entity 26762B and the BTDHandlingUnit entity26720D.

The BTDLog package 26730B includes a BTDCreationLog entity 26724D. Thereis a 1:c relationship 26726D between the BusinessTransactionDocumententity 26762B and the BTDCreationLog entity 26724D. The BTDCreationLogentity 26724D includes a BTDCreationLogItem entity 26728D. There is a1:n relationship 26730D between the BTDCreationLog entity 26724D and theBTDCreationLogItem entity 26728D.

The BTDFollowUpBusinessTransactionDocument package 26732B includes aBTDFollowUpPurchaseOrder entity 26732D and aBTDFollowUpPurchasingContract entity 26734D. There is a 1:c relationship26736D between the BusinessTransactionDocument entity 26762B and theBTDFollowUpPurchaseOrder entity 26732D. There is a 1:c relationship26738D between the BusinessTransactionDocument entity 26762B and theBTDFollowUpPurchasingContract entity 26734D.

The BTDFollowUpMessage package 26734B includes aBTDFollowUpPurchaseOrderConfirmation entity 26740D, aBTDFollowUpSalesOrderFulfillmentConfirmation entity 26742D, aBTDFollowUpServiceAcknowledgementRequest entity 26744D, aBTDFollowUpDespatchedDeliveryNotification entity 26746D, aBTDFollowUpInvoiceRequest entity 26748D, aBTDFollowUpBillingDueNotification entity 26750D, and aBTDFollowUpInvoiceDueNotification entity 26752D. There is a 1:crelationship 26754D between the BusinessTransactionDocument entity26762B and the BTDFollowUpPurchaseOrderConfirmation entity 26740D. Thereis a 1:c relationship 26756D between the BusinessTransactionDocumententity 26762B and the BTDFollowUpSalesOrderFulfillmentConfirmationentity 26742D. There is a 1:c relationship 26758D between theBusinessTransactionDocument entity 26762B and theBTDFollowUpServiceAcknowledgementRequest entity 26744D. There is a 1:crelationship 26760D between the BusinessTransactionDocument entity26762B and the BTDFollowUpDespatchedDeliveryNotification entity 26746D.There is a 1:c relationship 26761 D between theBusinessTransactionDocument entity 26762B and theBTDFollowUpInvoiceRequest entity 26748D. There is a 1:c relationship26762D between the BusinessTransactionDocument entity 26762B and theBTDFollowUpBillingDueNotification entity 26750D. There is a 1:crelationship 26763D between the BusinessTransactionDocument entity26762B and the BTDFollowUpInvoiceDueNofification entity 26752D.

The BTDLoanPaymentPlan package 26735B includes a BTDLoanPaymentPlanentity 26764D. There is a 1:c relationship 26765D between theBusinessTransactionDocument entity 26762B and the BTDLoanPaymentPlanentity 26764D. The BTDLoanPaymentPlan entity 26764D includes aBTDLoanPaymentPlanItem entity 26766D. There is a 1:n relationshipbetween the BTDLoanPaymentPlan entity 26764D and theBTDLoanPaymentPlanItem entity 26766D.

The BTDItem package 26736B includes a BTDItem entity 26768D. There is a1:cn relationship between the BusinessTransactionDocument entity 26762Band the BTDItem entity 26768D. BTDItems are arranged hierarchicallyusing a Hierarchy Relationship 26772D. The Hierarchy Relationship 26772Dis the relationship between a sub-item and a higher-level parent item inan item hierarchy. There is a 1:cn relationship 26774D between theBTDItem entity 26768D and its subordinate entities, and a 1:crelationship 26776D between the BTDItem entity 26768D and itssuperordinate entities.

The BTDItem entity 26768D is specialized into an InventoryChangeItementity 26778D, a ProductActivityItem entity 26780D, anInvoiceAccountingItem entity 26782D, a ProductDemandlnfluencingEventItementity 26784D, a ProductForecastItem entity 26786D, aRequestForQuotationItem entity 26788D, an RFQResultItem entity 26790D, aQuoteItem entity 26792D, a PurchaseRequirementItem entity 26794D, aPurchaseRequirementConfirmationItem entity 26796D, a PurchaseOrderItementity 26798D, a SalesOrderFulfillmentItem entity 26700E, aServiceAcknowledgementItem entity 26702E, a DeliveryExecutionRequestItementity 26704E, a DeliveryItem entity 26706E, a PaymentDueItem entity26708E, an InvoiceDueItem entity 26710E, an InvoiceItem entity 26712E, aTaxDueItem entity 26714E, an InvoicelssuedItem entity 26716E, which aredisjoint complete specializations 26718E of the BTDItem entity 26768D.

The InvoiceAccountingItem entity 26782D is specialized into anInvoiceAccountingExpenseRevenueItem entity 26720E, anInvoiceAccountingDueItem entity 26722E, and an InvoiceAccountingTaxItementity 26724E, which are disjoint complete specializations 26726E of theInvoiceAccountingItem entity 26782D.

The ProductForecastItem entity 26786D is specialized into aProductForecastNotificationItem entity 26728E and aProductForecastRevisionItem entity 26730E, which are disjoint completespecializations 26732E of the ProductForecastItem entity 26786D.

The PurchaseOrderItem entity 26798D is specialized into aPurchaseOrderInformationItem entity 26734E, which is a disjoint completespecialization 26736E of the ProductForecastItem entity 26798D.

The DeliveryItem entity 26706E is specialized into aDespatchedDeliveryItem entity 26738E, a ReceivedDeliveryItem entity26740E, and a DeliveryInformationItem entity 26742E, which are disjointcomplete specializations 26744E of the DeliveryItem entity 26706E.

The BTDItem package 26736B includes a BTDItemScheduleLine package26746E. The BTDItemScheduleLine package 26746E includes aBTDItemScheduleLine entity 26762E. There is a 1:cn relationship 26764Ebetween the BTDItem entity 26768D and the BTDItemScheduleLine entity26762E.

The BTDItemScheduleLine entity 26762E includes aBTDItemScheduleLineDeliveryPeriod entity 26770E. There is a 1:crelationship 26772E between the BTDItemScheduleLine entity 26762E andthe BTDItemScheduleLineDeliveryPeriod entity 26770E. TheBTDItemScheduleLine entity 26762E is specialized into aBTDConfirmedScheduleLine entity 26766E, which is a disjoint incompletespecialization 26768E of the BTDItemScheduleLine entity 26762E.

The BTDItem package 26736B also includes a BTDIBatch package 26748E, aBTDIRelease package 26750E, a BTDIPromotion package 26752E, aBTDIInventory package 26754E, aPurchaseRequirementConfirmationItemExecutingPurchaseOrder package26756E, an InventoryChangeItemlnbound package 26758E, and anInventoryChangeItemOutbound package 26760E. The BTDIBatch package 26748Eincludes a BTDIBatch entity 26774E. There is a 1:c relationship 26776Ebetween the BTDItem entity 26768D and the BTDIBatch entity 26774E. TheBTDIRelease package 26750E includes a BTDIRelease entity 26778E and aBTDIPreviousRelease entity 26780E. There is a 1:c relationship 26782Ebetween the BTDItem entity 26768D and the BTDIRelease entity 26778E.There is a 1:c relationship 26784E between the BTDItem entity 26768D andthe BTDIPreviousRelease entity 26780E. The BTDIPromotion entity 26752Eincludes a BTDIPromotion entity 26786E. There is a 1:c relationship26788E between the BTDItem entity 26768D and the BTDIPromotion entity26786E. The BTDIInventory package 26754E includes a BTDIInventory entity26790E and a BTDIConsignmentlnventory entity 26792E. There is a 1:crelationship 26794E between the BTDItem entity 26768D and theBTDIInventory entity 26790E. There is a 1:c relationship 26796E betweenthe BTDItem entity 26768D and the BTDIConsignmentlnventory entity26792E. The PurchaseRequirementConfirmationItemExecutingPurchaseOrderpackage 26756E includes aPurchaseRequirementConfirmationItemExecutingPurchaseOrder entity 26798E.There is a 1:cn relationship 26700F between the BTDItem entity 26768Dand the PurchaseRequirementConfirmationItemExecutingPurchaseOrder entity26798E. The InventoryChangeItemlnbound package 26758E includes anInventoryChangeItemlnbound entity 26702F. There is a 1:c relationship26704F between the BTDItem entity 26768D and theInventoryChangeItemlnbound entity 26702F. TheInventoryChangeItemOutbound package 26760E includes anInventoryChangeItemOutbound entity 26706F. There is a 1:c relationship26708F between the BTDItem entity 26768D and theInventoryChangeItemOutbound entity 26706F.

The BTDPriceInformation package 26738B includes aBTDProcurementCostUpperLimit entity 26710F, a BTDPrice entity 26712F anda BTDConfirmedPrice entity 26714F. There is a 1:c relationship 26716Fbetween the BTDItem entity 26768D and the BTDProcurementCostUpperLimitentity 26710F. There is a 1:c relationship 26718F between the BTDItementity 26768D and the BTDPrice entity 26712F. There is a 1:cnrelationship 26720F between the BusinessTransactionDocument entity26762B and the BTDPrice entity 26712F. There is a 1:c relationship26722F between the BTDItem entity 26768D and the BTDConfirmedPriceentity 26714F. The BTDPrice entity 26712F includes a BTDPriceComponententity 26724F and a BTDPriceScale entity 26726F. There is a 1:cnrelationship 26728F between the BTDPrice entity 26712F and theBTDPriceComponent entity 26724F. There is a 1:c relationship 26730Fbetween the BTDPrice entity 26712F and the BTDPriceScale entity 26726F.The BTDPriceScale entity 26726F includes a BTDPriceScaleLine entity26732F. There is a 1:n relationship 26734F between the BTDPriceScaleentity 26726F and the BTDPriceScaleLine entity 26732F.

The BTDPaymentInformation package 26740B includes a BTDCashDiscountTermsentity 26736F and a BTDPaymentForm entity 26738F. There is a 1:crelationship 26740F between the BTDItem entity 26768D and theBTDCashDiscountTerns entity 26736F. There is a 1:c relationship 26742Fbetween the BTDCashDiscountTerms entity 26736F and the BTDItem entity26768D. There is a 1:c relationship 26744F between theBusinessTransactionDocument entity 26762B and the BTDCashDiscountTermsentity 26736F. There is a 1:c relationship 26746F between the BTDItementity 26768D and the BTDPaymentForm entity 26738F. There is a 1:crelationship 26748F between the BTDPaymentForm entity 26738F and theBTDItem entity 26768D. There is a 1:c relationship 26750F between theBusinessTransactionDocument entity 26762B and the BTDPaymentForm entity26738F.

The BTDTax package 26742B includes a BTDProductTax entity 26764F. Thereis a 1:cn relationship 26766F between the BTDItem entity 26768D and theBTDProductTax entity 26764F. There is a 1:cn relationship 26768F betweenthe BusinessTransactionDocument entity 26762B and the BTDProductTaxentity 26764F.

The BTDDeliveryInformation package 26744B includes a BTDDeliveryTermsentity 26770F, a DeliveryItemVariance entity 26772F, and aBTDDeliveryControl entity 26774F. There is a 1:c relationship 26776Fbetween the BTDItem entity 26768D and the BTDDeliveryTerms entity26770F. There is a 1:c relationship 26778F between the BTDDeliveryTermsentity 26770F and the BTDItem entity 26768D. There is a 1:c relationship26780F between the BusinessTransactionDocument entity 26762B and theBTDDeliveryTemms entity 26770F. There is a 1:cn relationship 26782Fbetween the BTDItem entity 26768D and the DeliveryItemVariance entity26772F. There is a 1:c relationship 26784F between the BTDItem entity26768D and the BTDDeliveryControl entity 26774F. There is a 1:crelationship 26786F between the BTDDeliveryControl entity 26774F and theBTDItem entity 26768D. There is a 1:c relationship 26788F between theBusinessTransactionDocument entity 26762B and the BTDDeliveryControlentity 26774F.

The BTDDeliveryTerms entity 26770F includes a BTDDeliveryTermslncoterrnsentity 26790F, a BTDDeliveryTermsPartialDelivery entity 26792F, aBTDDeliveryTermsQuantityTolerance entity 26794F, aBTDDeliveryTermsTransport entity 26796F, and aBTDDeliveryTermsDescription entity 26798F. There is a 1:cn relationship26700G between the Incoterms entity 26710 and theBTDDeliveryTermsIncoterms entity 26790F. There is a 1:c relationship26702G between the BTDDeliveryTerms entity 26770F and theBTDDeliveryTermslncoterms entity 26790F. There is a 1:c relationship26704G between the BTDDeliveryTerms entity 26770F and theBTDDeliveryTernsPartialDelivery entity 26792F. There is a 1:crelationship 26706G between the BTDDeliveryTerms entity 26770F and theBTDDeliveryTermsQuantityTolerance entity 26794F. There is a 1:crelationship 26708G between the BTDDeliveryTerms entity 26770F and theBTDDeliveryTermsTransport entity 26796F. There is a 1:c relationship26710G between the BTDDeliveryTerms entity 26770F and theBTDDeliveryTermsDescription entity 26798F.

The BTDDeliveryExecutionInformation package 26746B includes aDeliveryExecutionPeriod entity 26712G and a DeliveryExecutionStatusentity 26714G. There is a 1:cn relationship 26716G between the BTDItementity 26768D and the DeliveryExecutionPeriod entity 26712G. There is a1:c relationship 26718G between the DeliveryExecutionPeriod entity26712G and the BTDItem entity 26768D. There is a 1:cn relationship26720G between the BusinessTransactionDocument entity 26762B and theDeliveryExecutionPeriod entity 26712G. There is a 1:cn relationship26722G between the BTDItem entity 26768D and the DeliveryExecutionStatusentity 26714G. There is a 1:c relationship 26723G between theDeliveryExecutionStatus entity 26714G and the BTDItem entity 26768D.There is a 1:cn relationship 26724G between theBusinessTransactionDocument entity 26762B and theDeliveryExecutionStatus entity 26714G.

The BTDAccountingObjectSet package 26748B includes aBTDAccountingObjectSet entity 26726G. There is a 1:c relationship 26728Gbetween the BTDItem entity 26768D and the BTDAccountingObjectSet entity26726G.

The BTDBusinessDocumentObjectReference package 26750B includes aBTDRequestForQuotationReference entity 26730G, aBTDSchedulingAgreementReference entity 26732G, aBTDSellerProductCatalogueReference entity 26734G, aBTDBuyerProductCatalogueReference entity 26736G, aBTDPurchasingContractReference entity 26738G, aBTDSalesContractReference entity 26740G, aBTDOriginPurchaseOrderReference entity 26742G, a BTDQuoteReferenceentity 26744G, a BTDPurchaseOrderReference entity 26746G, aBTDSalesOrderReference entity 26748G, aBTDServiceAcknowledgementReference entity 26750G, aBTDPendingDeliveryReference entity 26752G, a BTDDeliveryReference entity26754G, a BTDInboundDeliveryReference entity 26756G, aBTDDespatchedDeliveryNotificationReference entity 26758G, aBTDShipmentReference entity 26760G, a BTDOriginInvoiceReference entity26762G, a BTDOriginVendorInvoiceReference entity 26764G, aBTDPrimaNotaReference entity 26766G, and a BTDOriginPrimaNotaReferenceentity 26768G. There is a 1:c relationship 26770G between theBusinessTransactionDocument entity 26762B and theBTDRequestForQuotationReference entity 26730G. There is a 1:cnassociation 26772G between the RFQ Specialization 26782B and theBTDRequestForQuotationReference entity 26730G. There is a 1:crelationship 26774G between the BTDItem entity 26768D and theBTDSchedulingAgreementReference entity 26732G, and a 1:c relationship26776G between the BTDSchedulingAgreementReference entity 26732G and theBTDItem entity 26768D. There is a 1:c relationship 26778G between theBusinessTransactionDocument entity 26762B and theBTDSchedulingAgreementReference entity 26732G. There is a 1:cnassociation 26780G between the SchedulingAgreement entity 26792B and theBTDSchedulingAgreementReference entity 26732G. There is a 1:crelationship 26782G between the BTDItem entity 26768D and theBTDSellerProductCatalogueReference entity 26734G. There is a 1:cnassociation 26784G between the SellerProductCatalogue entity 26782 andthe BTDSellerProductCatalogueReference entity 26734G. There is a 1:crelationship 26786G between the BTDItem entity 26768D and theBTDBuyerProductCatalogueReference entity 26736G. There is a 1:cnassociation 26788G between the BuyerProductCatalogue entity 26780 andthe BTDBuyerProductCatalogueReference entity 26736G. There is a 1:cnrelationship 26790G between the BTDItem entity 26768D and theBTDPurchasingContractReference entity 26738G, and a 1:c relationship26792G between the BTDPurchasingContractReference entity 26738G and theBTDItem entity 26768D. There is a 1:c relationship 26794G between theBusinessTransactionDocument entity 26762B and theBTDPurchasingContractReference entity 26738G. There is a 1:cnassociation 26796G between the PurchaseContract entity 26790B and theBTDPurchasingContractReference entity 26738G. There is a 1:cnrelationship 26798G between the BTDItem entity 26768D and theBTDSalesContractReference entity 26740G. There is a 1:cn association26700H between the SalesContract entity 26788B and theBTDSalesContractReference entity 26740G. There is a 1:c relationship26702H between the BTDItem entity 26768D and theBTDOriginPurchaseOrderReference entity 26742G. There is a 1:cnassociation 26704H between the PurchaseOrderRequest entity 26758C andthe BTDOriginPurchaseOrderReference entity 26742G.

There is a 1:c relationship 26706H between the BTDItem entity 26768D andthe BTDQuoteReference entity 26744G, and a 1:c relationship 26708Hbetween the BTDQuoteReference entity 26744G and the BTDItem entity26768D. There is a 1:c relationship 26710H between theBusinessTransactionDocument entity 26762B and the BTDQuoteReferenceentity 26744G. There is a 1:cn association 26712H between the Quoteentity 26786B and the BTDQuoteReference entity 26744G. There is a 1:cnrelationship 26714H between the BTDItem entity 26768D and theBTDPurchaseOrderReference entity 26746G. There is a 1:cn association26716H between the PurchaseOrderRequest entity 26758C and theBTDPurchaseOrderReference entity 26746G. There is a 1:cn relationship26718H between the BTDItem entity 26768D and the BTDSalesOrderReferenceentity 26748G. There is a 1:cn association 26720H between the SalesOrderentity 26700C and the BTDSalesOrderReference entity 26748G. There is a1:c relationship 26722H between the BTDItem entity 26768D and theBTDServiceAcknowledgementReference entity 26750G. There is a 1:cnassociation 26724H between the ServiceAcknowledgement entity 26704C andthe BTDServiceAcknowledgementReference entity 26750G. There is a 1:cnrelationship 26726H between the BTDItem entity 26768D and theBTDPendingDeliveryReference entity 26752G. There is a 1:cn association26728H between the PendingDelivery entity 26766C and theBTDPendingDeliveryReference entity 26752G. There is a 1:c relationship26730H between the BTDItem entity 26768D and the BTDDeliveryReferenceentity 26754G. There is a 1:cn association 26732H between the DeliverySpecialization 26708C and the BTDDeliveryReference entity 26754G. Thereis a 1:cn relationship 26734H between the BusinessTransactionDocumententity 26762B and the BTDInboundDeliveryReference entity 26756G. Thereis a 1:cn association 26736H between the InboundDelivery entity 26768Cand the BTDInboundDeliveryReference entity 26756G.

There is a 1:c relationship 26738H between the BTDItem entity 26768D andthe BTDDespatchedDeliveryNotificationReference entity 26758G, and a 1:crelationship 26740H between theBTDDespatchedDeliveryNotificationReference entity 26758G and the BTDItementity 26768D. There is a 1:c relationship 26742H between theBusinessTransactionDocument entity 26762B and theBTDDespatchedDeliveryNotificationReference entity 26758G. There is a1:cn association 26744H between the DespatchedDeliveryNotificationentity 26774C and the BTDDespatchedDeliveryNotificationReference entity26758G. There is a 1:c relationship 26746H between the BTDItem entity26768D and the BTDShipmentReference entity 26760G, and a 1:crelationship 26748H between the BTDShipmentReference entity 26760G andthe BTDItem entity 26768D. There is a 1:c relationship 26750H betweenthe BusinessTransactionDocument entity 26762B and theBTDShipmentReference entity 26760G. There is a 1:cn association 26752Hbetween the Shipment entity 26710C and the BTDShipmentReference entity26760G. There is a 1:c relationship 26754H between the BTDItem entity26768D and the BTDOriginInvoiceReference entity 26762G. There is a 1:cnassociation 26756H between the Invoice entity 26718C and theBTDOriginInvoiceReference entity 26762G. There is a 1:c relationship26758H between the BusinessTransactionDocument entity 26762B and theBTDOriginVendorInvoiceReference entity 26764G. There is a 1:cassociation 26760H between the VendorInvoice entity 26726C and theBTDOriginVendorInvoiceReference entity 26764G. There is a 1:crelationship 26762H between the BusinessTransactionDocument entity26762B and the BTDPrimaNotaReference entity 26766G. There is a 1:crelationship 26764H between the BusinessTransactionDocument entity26762B and the BTDOriginPrimaNotaReference entity 26768G.

The BTDAttachment package 26752B includes a BTDAttachment entity 26766H,a BTDAttachmentWebAddress entity 26768H, and aBTDInternetAttachmentWebAddress entity 26770H. There is a 1:cnrelationship 26772H between the BTDItem entity 26768D and theBTDAttachment entity 26766H, and a 1:c relationship 26774H between theBTDAttachment entity 26766H and the BTDItem entity 26768D. There is a1:cn relationship 26776H between the BusinessTransactionDocument entity26762B and the BTDAttachment entity 26766H. There is a 1:cn association26778H between the Attachment entity 26758 and the BTDAttachment entity26766H. There is a 1:cn relationship 26780H between the BTDItem entity26768D and the BTDAttachmentWebAddress entity 26768H. There is a 1:cnrelationship 26782H between the BusinessTransactionDocument entity26762B and the BTDAttachmentWebAddress entity 26768H. There is a 1:cnrelationship 26784H between the BTDItem entity 26768D and theBTDInternetAttachmentWebAddress entity 26770H. There is a 1:cnrelationship 26786H between the BusinessTransactionDocument entity26762B and the BTDInternetAttachmentWebAddress entity 26770H.

The BTDDescription package 26754B includes a BTDDescription entity26788H, a BTDInternalWebAddress entity 26790H, and aBTDConfirmationDescription entity 26792H. There is a 1:cn relationship26794H between the BTDItem entity 26768D and the BTDDescription entity26788H. There is a 1:c relationship 26796H between the BTDDescriptionentity 26788H and the BTDItem entity 26768D. There is a 1:cnrelationship 26798H between the BusinessTransactionDocument entity26762B and the BTDDescription entity 26788H. There is a 1:c relationship26700I between the BTDItem entity 26768D and the BTDInternalWebAddressentity 26790H. There is a 1:c relationship 26702I between theBTDInternalWebAddress entity 26790H and the BTDItem entity 26768D. Thereis a 1:c relationship 26704I between the BusinessTransactionDocumententity 26762B and the BTDInternalWebAddress entity 26790H. There is a1:c relationship 26706I between the BTDItem entity 26768D and theBTDConfirmationDescription entity 26792H. There is a 1:c relationship26708I between the BTDConfirmationDescription entity 26792H and theBTDItem entity 26768D. There is a 1:c relationship 26710I between theBusinessTransactionDocument entity 26762B and theBTDConfirmationDescription entity 26792H.

The BTDParty package 26756B includes a BTDParty entity 26712I. Thedetails regarding the relationships 26713I to the BTDParty entity 26712Iare depicted in FIG. 267FF. There is a 1:1 relationship 26714I betweenthe InventoryChangeItemlnbound entity 26702F and the BTDParty entity26712I, and a 1:c relationship 26716I between the BTDParty entity 26712Iand the InventoryChangeItemlnbound entity 26702F. There is a 1:1relationship 26718I between the InventoryChangeItemOutbound entity26706F and the BTDParty entity 26712I, and a 1:c relationship 26720Ibetween the BTDParty entity 26712I and the InventoryChangeItemOutboundentity 26706F. There is a 1:cn relationship 26722I between the BTDItementity 26768D and the BTDParty entity 26712I, and a 1:c relationship26724I between the BTDParty entity 26712I and the BTDItem entity 26768D.There is a 1:cn relationship 26726I between theBusinessTransactionDocument entity 26762B and the BTDParty entity26712I.

The BTDParty entity 26712I includes a BTDPartyContactPerson entity26728I and a BTDPartyAddress entity 26730I. There is a 1:c relationship26732I between the BTDParty entity 26712I and the BTDPartyContactPersonentity 26728I. There is a 1:c relationship 26734I between the BTDPartyentity 26712I and the BTDPartyAddress entity 26730I. There is a 1:cnrelationship 26736I between the BusinessTransactionDocument entity26762B and the BTDPartyAddress entity 26730I.

The BTDParty entity 26712I is specialized into a BTDBuyerParty entity26744I, a BTDCreditorParty entity 26746I, a BTDSellerParty entity26748I, a BTDDebtorParty entity 26750I, a BTDProductRecipientPartyentity 26752I, a BTDVendorParty entity 26754I, a BTDManufacturerPartyentity 26756I, a BTDPayerParty entity 26758I, a BTDPayeeParty entity26760I, a BTDBillToParty entity 26762I, a BTDBillFromParty entity26764I, a BTDCarrierParty entity 26766I, a BTDRequestorParty entity26767I, a BRDPortalProviderParty entity 26768I, a BTDCatalogueProviderentity 26769I, a BTDBidderParty entity 26770I, a BTDOwnerParty entity26771I, a BTDTaxPayerParty entity 26772I, a BTDTaxAuthorityParty 26773I,a BTDTaxOperatorParty 26774I, a BTDContractReleaseAuthorisedParty26775I, a BTDProposedSellerParty 26776I, and aBTDBidderPortalProviderParty 26777I, which are nondisjoint completespecializations 26778I of the BTDParty entity 26712I.

The BTDLocation package 26758B includes a BTDLocation entity 26780I. Thedetails regarding the relationships 26781I to the BTDLocation entity26780I are depicted in FIG. 267II. There is a 1:cn relationship 26782Ibetween the InventoryChangeItemlnbound entity 26702F and the BTDLocationentity 26780I, and a 1:c relationship 26784I between the BTDLocationentity 26780I and the InventoryChangeItemlnbound entity 26702F. There isa 1:cn relationship 26786I between the InventoryChangeItemOutboundentity 26706F and the BTDLocation entity 26780I, and a 1:c relationship26788I between the BTDLocation entity 26780I and theInventoryChangeItemOutbound entity 26706F. There is a 1:cn relationship26790I between the BTDItem entity 26768D and the BTDLocation entity26780I, and a 1:c relationship 26792I between the BTDLocation entity26780I and the BTDItem entity 26768D. There is a 1:cn relationship26794I between the BusinessTransactionDocument entity 26762B and theBTDLocation entity 26780I.

The BTDLocation entity 26780I includes a BTDLocationAddress entity26796I. There is a 1:cn relationship 26798I between the Address entity26737 and the BTDLocationAddress entity 26796I. There is a 1:crelationship 26700J between the BTDLocation entity 26780I and theBTDLocationAddress entity 26796I. The BTDLocation entity 26780I isspecialized into a BTDShipToLocation entity 26702J and aBTDShipFromLocation entity 26704J, which are nondisjoint incompletespecializations 26706J of the BTDLocation entity 26780I.

The BTDProductInformation package 26759B includes a BTDProduct entity26708J and a BTDProductCategory entity 26710J. The details regarding therelationships 26711J to the BTDProduct entity 26708J are depicted inFIG. 267JJ. There is a 1:1 relationship 26712J between theInventoryChangeItemlnbound entity 26702F and the BTDProduct entity26708J, and a 1:c relationship 26714J between the BTDProduct entity26708J and the InventoryChangeItemlnbound entity 26702F. There is a 1:1relationship 26716J between the InventoryChangeItemOutbound entity26706F and the BTDProduct entity 26708J, and a 1:c relationship 26718Jbetween the BTDProduct entity 26708J and the InventoryChangeItemOutboundentity 26706F. There is a 1:c relationship 26720J between the BTDItementity 26768D and the BTDProduct entity 26708J. There is a 1:crelationship 26722J between the BusinessTransactionDocument entity26762B and the BTDProduct entity 26708J, and a 1:c relationship 26724Jbetween the BTDProduct entity 26708J and the BusinessTransactionDocumententity 26762B. There is a 1:c relationship 26726J between the BTDItementity 26768D and the BTDProductCategory entity 26710J. There is a 1:crelationship 26728J between the BusinessTransactionDocument entity26762B and the BTDProductCategory entity 26710J, and a 1:c relationship26730J between the BTDProductCategory entity 26710J and theBusinessTransactionDocument entity 26762B.

The BTDLoanConditionInformation package includes a BTDInterestConditionentity 26762J, a BTDAmortizementCondition entity 26764J, and aBTDFeeCondition entity 26766J. There is a 1:c relationship 26768Jbetween the BTDItem entity 26768D and the BTDInterestCondition entity26762J, and a 1:c relationship 26769J between the BTDInterestConditionentity 26762J and the BTDItem entity 26768D. There is a 1:cnrelationship 26770J between the BusinessTransactionDocument entity26762B and the BTDInterestCondition entity 26762J. There is a 1:crelationship 26772J between the BTDItem entity 26768D and theBTDAmortizementCondition entity 26764J, and a 1:c relationship 26773Jbetween the BTDAmortizementCondition entity 26764J and the BTDItementity 26768D. There is a 1:cn relationship 26774J between theBusinessTransactionDocument entity 26762B and theBTDAmortizementCondition entity 26764J. There is a 1:c relationship26776J between the BTDItem entity 26768D and the BTDFeeCondition entity26766J, and a 1:c relationship 26777J between the BTDFeeCondition entity26766J and the BTDItem entity 26768D. There is a 1:cn relationship26778J between the BusinessTransactionDocument entity 26762B and theBTDFeeCondition entity 26766J.

The PersonnelTimeSubheet package 26761B includes a PersonnelTimeSubSheetentity 26750J. There is a 1:n relationship 26752J between theBusinessTransactionDocument entity 26762B and the PersonnelTimeSubSheetentity 26750J. The PersonnelTimeSubSheet entity 26750J includes aPersonnelTime entity 26754J and a PersonnelTimeEvent entity 26756J.There is a 1:cn relationship 26758J between the PersonnelTimeSubSheetentity 26750J and the PersonnelTime entity 26754J. There is a 1:cnrelationship 26760J between the PersonnelTimeSubSheet entity 26750J andthe PersonnelTimeEvent entity 26756J.

The CataloguePublicationTransmission package 26714B includes aCataloguePublicationTransmission entity 26732J. There is a 1:cnrelationship 26734J between the Catalogue entity 26766 and theCataloguePublicationTransmission entity 26732J. TheCataloguePublicationTransmission entity 26732J is specialized into aCataloguePublicationTransmissionPackage entity 26736J, aCataloguePublicationTransmissionCancellationRequest entity 26738J, aCataloguePublicationTransmissionCancellationConfirmation entity 26740J,a CataloguePublicationTransmissionItemLockRequest entity 26742J and aCataloguePublicationTransmissionItemLockConfirmation entity 26744J,which are disjoint complete specializations 26746J of theCataloguePublicationTransmission entity 26732J.

5. Interfaces Derived from Business Object Model

Interfaces are the starting point of the communication between twobusiness entities. The structure of each interface determines how onebusiness entity communicates with another business entity. The businessentities may act as a unified whole when, based on the businessscenario, the business entities know what an interface contains from abusiness perspective and how to fill the individual elements or fieldsof the interface.

Communication between components takes place via messages that containbusiness documents. The business document ensures a holisticbusiness-related understanding for the recipient of the message. Asdepicted in FIG. 313, the object 31300 contained in the businessdocument 31302 (i.e., the “business document object”) refers in itssemantics to a “leading” business object 31304, which represents a viewof the business object and its environment.

The business documents are created and accepted or consumed byinterfaces, specifically by inbound and outbound interfaces. Theinterface structure and, hence, the structure of the business documentare derived by a mapping rule. This mapping rule is known as“hierarchization.” An interface structure thus has a hierarchicalstructure created based on the leading business object. The interfacerepresents a usage-specific, hierarchical view of the underlyingusage-neutral object model.

As illustrated in FIG. 314, several business document objects 31402,31404, and 31406 as overlapping views may be derived for a given leadingobject 31400. Each business document object results from the objectmodel by hierarchization.

To illustrate the hierarchization process, FIG. 315 depicts an exampleof an object model 31500 (i.e., a portion of the business object model)that is used to derive a service operation signature (business documentobject structure). As depicted, leading object X 31502 in the objectmodel 31500 is integrated in a net of object A 31504, object B 31506,and object C 31508, each of which objects 31504, 31506, 31508.Initially, the parts of the leading object 31502 that are required forthe business object document are adopted. In one variation, all partsrequired for a business document object are adopted from leading object31502 (making such an operation a maximal service operation). Based onthese parts, the relationships to the superordinate objects (i.e.,objects A, B, and C from which object X depends) are inverted. In otherwords, these objects are adopted as dependent or subordinate objects inthe new business document object.

For example, object A 31504, object B 31506, and object C 30508 haveinformation that characterize object X. Because object A 31504, object B31506, and object C 30508 are superordinate to leading object X 31502,the dependencies of these relationships change so that object A 31504,object B 31506, and object C 30508 become dependent and subordinate toleading object X 31502. This procedure is known as “derivation of thebusiness document object by hierarchization.”

Business-related objects generally have an internal structure (parts).This structure can be complex and reflect the individual parts of anobject and their mutual dependency. When creating the operationsignature, the internal structure of an object is strictly hierarchized.Thus, dependent parts keep their dependency structure, and relationshipsbetween the parts within the object that do not represent thehierarchical structure are resolved by prioritizing one of therelationships.

Relationships of object X to external objects that are referenced andwhose information characterizes object X are added to the operationsignature. Such a structure can be quite complex (see, for example, FIG.316). The cardinality to these referenced objects is adopted as 1:1 or1:C, respectively. By this, the direction of the dependency changes. Therequired parts of this referenced object are adopted identically, bothin their cardinality and in their dependency arrangement.

The newly created business document object contains all requiredinformation, including the incorporated master data information of thereferenced objects. As depicted in FIG. 316, components Xi in leadingobject X 31600 are adopted directly. The relationship of object X 31600to object A 31602, object B 31604, and object C 31606 are inverted, andthe parts required by these objects are added as objects that dependfrom object X 31600. As depicted, all of object A 31602 is adopted. B3and B4 are adopted from object B 31604, but B1 is not adopted. Fromobject C 31606, C2 and C1 are adopted, but C3 is not adopted.

FIG. 317 depicts the business document object X 31700 created by thishierarchization process. As shown, the arrangement of the elementscorresponds to their dependency levels, which directly leads to acorresponding representation as an XML structure 31702.

The following provides certain rules that can be adopted singly or incombination with regard to the hierarchization process:

-   -   A business document object always refers to a leading business        document object and is derived from this object.    -   The name of the root entity in the business document entity is        the name of the business object or the name of a specialization        of the business object or the name of a service specific view        onto the business object.    -   The nodes and elements of the business object that are relevant        (according to the semantics of the associated message type) are        contained as entities and elements in the business document        object.    -   The name of a business document entity is predefined by the name        of the corresponding business object node. The name of the        superordinate entity is not repeated in the name of the business        document entity. The “full” semantical name results from the        concatenation of the entity names along the hierarchical        structure of the business document object.    -   The structure of the business document object is, except for        deviations due to hiearchization, the same as the structure of        the business object.    -   The cardinalities of the business document object nodes and        elements are adopted identically or more restrictively to the        business document object.    -   An object from which the leading business object is dependent        can be adopted to the business document object. For this        arrangement, the relationship is inversted, and the object (or        its parts, respectively) are hierarchically subordinated in the        business document object.    -   Nodes in the business object representing generalized business        information can be adopted as explicit entities to the business        document object (generally speaking, multiply TypeCodes out).        When this adoption occurs, the entities are named according to        their more specific semantic (name of TypeCode becomes prefix).        -   Party nodes of the business object are modeled as explicit            entities for each party role in the business document            object. These nodes are given the name <Prefix><Party            Role>Party, for example, BuyerParty, ItemBuyerParty.        -   BTDReference nodes are modeled as separate entities for each            reference type in the business document object. These nodes            are given the name <Qualifier><BO><Node>Reference, for            example SalesOrderReference, OriginSalesOrderReference,            SalesOrderItemReference.        -   A product node in the business object comprises all of the            information on the Product, ProductCategory, and Batch. This            information is modeled in the business document object as            explicit entities for Product, ProductCategory, and Batch.    -   Entities which are connected by a 1:1 relationship as a result        of hierarchization can be combined to a single entity, if they        are semantically equivalent. Such a combination can often occurs        if a node in the business document object that results from an        assignment node is removed because it does not have any        elements.    -   The message type structure is typed with data types.        -   Elements are typed by GDTs according to their business            objects.        -   Aggregated levels are typed with message type specific data            types (Intermediate Data Types), with their names being            built according to the corresponding paths in the message            type structure.        -   The whole message type structured is typed by a message data            type with its name being built according to the root entity            with the suffix “Message”.    -   For the message type, the message category (e.g., information,        notification, query, response, request, confirmation, etc.) is        specified according to the suited transaction communication        pattern.

In one variation, the derivation by hierarchization can be initiated byspecifiying a leading business object and a desired view relevant for aselected service operation. This view determines the business documentobject. The leading business object can be the source object, the targetobject, or a third object. Thereafter, the parts of the business objectrequired for the view are determined. The parts are connected to theroot node via a valid path along the hierarchy. Thereafter, one or moreindependent objects (object parts, respectively) referenced by theleading object which are relevant for the service may be determined(provided that a relationship exists between the leading object and theone or more independent objects).

Once the selection is finalized, relevant nodes of the leading objectnode that are structurally identifcal to the message type structure canthen be adopted. If nodes are adopted from independent objects or objectparts, the relationships to such independent objects or object parts areinverted. Linearization can occur such that a business object nodecontaining certain TypeCodes is represented in the message typestructure by explicit entities (an entity for each value of theTypeCode). The structure can be reduced by checking all 1:1cardinalities in the message type structure. Entities can be combined ifthey are semantically equivalent, one of the entities carries noelements, or an entity solely results from an n:m assignment in thebusiness object.

After the hierarchization is completed, information regardingtransmission of the business document object (e.g.,CompleteTransmissionIndicator, ActionCodes, message category, etc.) canbe added. A standardized message header can be added to the message typestructure and the message structure can be typed. Additionally, themessage category for the message type can be designated.

Invoice Request and Invoice Confirmation are examples of interfaces.These invoice interfaces are used to exchange invoices and invoiceconfirmations between an invoicing party and an invoice recipient (suchas between a seller and a buyer) in a B2B process. Companies can createinvoices in electronic as well as in paper form. Traditional methods ofcommunication, such as mail or fax, for invoicing are cost intensive,prone to error, and relatively slow, since the data is recordedmanually. Electronic communication eliminates such problems. Themotivating business scenarios for the Invoice Request and InvoiceConfirmation interfaces are the Procure to Stock (PTS) and Sell fromStock (SFS) scenarios. In the PTS scenario, the parties use invoiceinterfaces to purchase and settle goods. In the SFS scenario, theparties use invoice interfaces to sell and invoice goods. The invoiceinterfaces directly integrate the applications implementing them andalso form the basis for mapping data to widely-used XML standard formatssuch as RosettaNet, PIDX, xCBL, and CIDX.

The invoicing party may use two different messages to map a B2Binvoicing process: (1) the invoicing party sends the message typeInvoiceRequest to the invoice recipient to start a new invoicingprocess; and (2) the invoice recipient sends the message typeInvoiceConfirmation to the invoicing party to confirm or reject anentire invoice or to temporarily assign it the status “pending.”

An InvoiceRequest is a legally binding notification of claims orliabilities for delivered goods and rendered services—usually, a paymentrequest for the particular goods and services. The message typeInvoiceRequest is based on the message data type InvoiceMessage. TheInvoiceRequest message (as defined) transfers invoices in the broadersense. This includes the specific invoice (request to settle aliability), the debit memo, and the credit memo.

InvoiceConfirmafion is a response sent by the recipient to the invoicingparty confirming or rejecting the entire invoice received or statingthat it has been assigned temporarily the status “pending.” The messagetype InvoiceConfirmation is based on the message data typeInvoiceMessage. An InvoiceConfirmation is not mandatory in a B2Binvoicing process, however, it automates collaborative processes anddispute management.

FIG. 268 depicts the message choreography for the Invoice interface. Thechoreography involves two business entities: Billing 26802 and Invoicing26804. Billing 26802 sends an InvoiceRequest message 26806 to Invoicing26804. The message type 26808 of the InvoiceRequest message 26806 is0401. Invoicing 26804 then sends Billing 26802 an InvoiceConfirmationmessage 26810. The message type 26812 of the Confirmation message 26810is 0402.

Usually, the invoice is created after it has been confirmed that thegoods were delivered or the service was provided. The invoicing party(such as the seller) starts the invoicing process by sending anInvoiceRequest message. Upon receiving the InvoiceRequest message, theinvoice recipient (for instance, the buyer) can use theInvoiceConfirmation message to completely accept or reject the invoicereceived or to temporarily assign it the status “pending.” TheInvoiceConfirmation is not a negotiation tool (as is the case in ordermanagement), since the options available are either to accept or rejectthe entire invoice. The invoice data in the InvoiceConfirmation messagemerely confirms that the invoice has been forwarded correctly and doesnot communicate any desired changes to the invoice. Therefore, theInvoiceConfirmation includes the precise invoice data that the invoicerecipient received and checked. If the invoice recipient rejects aninvoice, the invoicing party can send a new invoice after checking thereason for rejection (AcceptanceStatus and ConfirmationDescription atInvoice and InvoiceItem level). If the invoice recipient does notrespond, the invoice is generally regarded as being accepted and theinvoicing party can expect payment.

FIGS. 269A-F depict a flow diagram of the steps performed by methods andsystems consistent with the subject matter described herein to generatean interface from the business object model. Although described as beingperformed by a computer, these steps may alternatively be performedmanually, or using any combination thereof. The process begins when thesystem receives an indication of a package template from the designer,i.e., the designer provides a package template to the system (step26900).

Package templates specify the arrangement of packages within a businesstransaction document. Package templates are used to define the overallstructure of the messages sent between business entities. Methods andsystems consistent with the subject matter described herein use packagetemplates in conjunction with the business object model to derive theinterfaces.

The system also receives an indication of the message type from thedesigner (step 26902). The system selects a package from the packagetemplate (step 26904), and receives an indication from the designerwhether the package is required for the interface (step 26906). If thepackage is not required for the interface, the system removes thepackage from the package template (step 26908). The system thencontinues this analysis for the remaining packages within the packagetemplate (step 26910).

If, at step 26906, the package is required for the interface, the systemcopies the entity template from the package in the business object modelinto the package in the package template (step 26912, FIG. 269B). Thesystem determines whether there is a specialization in the entitytemplate (step 26914). If the system determines that there is aspecialization in the entity template, the system selects a subtype forthe specialization (step 26916). The system may either select thesubtype for the specialization based on the message type, or it mayreceive this information from the designer. The system then determineswhether there are any other specializations in the entity template (step26914). When the system determines that there are no specializations inthe entity template, the system continues this analysis for theremaining packages within the package template (step 26910, FIG. 269A).

At step 26910, after the system completes its analysis for the packageswithin the package template, the system selects one of the packagesremaining in the package template (step 26918, FIG. 269C), and selectsan entity from the package (step 26920). The system receives anindication from the designer whether the entity is required for theinterface (step 26922). If the entity is not required for the interface,the system removes the entity from the package template (step 26924).The system then continues this analysis for the remaining entitieswithin the package (step 26926), and for the remaining packages withinthe package template (step 26928).

If, at step 26922, the entity is required for the interface, the systemretrieves the cardinality between a superordinate entity and the entityfrom the business object model (step 26930, FIG. 269D). The system alsoreceives an indication of the cardinality between the superordinateentity and the entity from the designer (step 26932). The system thendetermines whether the received cardinality is a subset of the businessobject model cardinality (step 26934). If the received cardinality isnot a subset of the business object model cardinality, the system sendsan error message to the designer (step 26936). If the receivedcardinality is a subset of the business object model cardinality, thesystem assigns the received cardinality as the cardinality between thesuperordinate entity and the entity (step 26938). The system thencontinues this analysis for the remaining entities within the package(step 26926, FIG. 269C), and for the remaining packages within thepackage template (step 26928).

The system then selects a leading object from the package template (step26940, FIG. 269E). The system determines whether there is an entitysuperordinate to the leading object (step 26942). If the systemdetermines that there is an entity superordinate to the leading object,the system reverses the direction of the dependency (step 26944) andadjusts the cardinality between the leading object and the entity (step26946). The system performs this analysis for entities that aresuperordinate to the leading object (step 26942). If the systemdetermines that there are no entities superordinate to the leadingobject, the system identifies the leading object as analyzed (step26948).

The system then selects an entity that is subordinate to the leadingobject (step 26950). The system determines whether any non-analyzedentities are superordinate to the selected entity (step 26952). If anon-analyzed entity is superordinate to the selected entity, the systemreverses the direction of the dependency (step 26954) and adjusts thecardinality between the selected entity and the non-analyzed entity(step 26956). The system performs this analysis for non-analyzedentities that are superordinate to the selected entity (step 26952). Ifthe system determines that there are no non-analyzed entitiessuperordinate to the selected entity, the system identifies the selectedentity as analyzed (step 26958), and continues this analysis forentities that are subordinate to the leading object (step 26960). Afterthe packages have been analyzed, the system substitutes theBusinessTransactionDocument (“BTD”) in the package template with thename of the interface (step 26962). This includes the “BTD” in theBTDItem package and the “BTD” in the BTDItemScheduleLine package.

For example, FIG. 270A depicts an illustrative package template for aBusinessTransactionDocument 27000. Methods and systems consistent withthe subject matter described herein use this package template to derivethe interfaces unless otherwise specified. The package template includesa BusinessTransactionDocumentItem package 27002, a Log package 27004, aDeliveryExecutionInformation package 27006, a Party package 27008, aLocation package 27010, a ProductInformation package 27012, aTransportInformation package 27014, a DeliveryInformation package 27016,a Scheduling package 27018, a CreditAgencyReportQueryService package27020, a CreditWorthinessInformation package 27022, a LegalInformationpackage 27024, a LoanConditionInformation package 27026, aLoanPaymentPlan package 27028, a PaymentInformation package 27030, aPriceInformation package 27032, a Tax package 27034, aBusinessDocumentObjectReference package 27036, aFollowUpBusinessTransactionDocument package 27038, anAmountAccountingObjectSetAssignment package 27040, an Attachment package27042, a Description package 27044, a FollowUpMessage package 27046, aHandlingUnit package 27048, and a PersonnelTimeSubsheet package 27050.The BusinessTransactionDocumentItem package 27002 includes aBusinessTransactionDocumentItemScheduleLine package 27052, a Log package27054, a DeliveryExecutionInformation package 27056, aProductInformation package 27058, a PriceInformation package 27060, aBatch package 27062, a Configuration package 27064, an Inventory package27066, an InventoryChangeItemOutbound package 27068, anInventoryChangeItemlnbound package 27070, a PropertyValuation package27072, a LoanConditionInformation package 27074, a Tax package 27076, aParty package 27078, a Location package 27080, a Promotion package27082, a PurchaseRequirementConfirmationItemExecutingPurchaseOrderpackage 27084, a CustomsInformation package 27086, a DeliveryInformationpackage 27088, a PaymentInformation package 27090, aBusinessDocumentObjectReference package 27092, anAmountAccountingObjectSetAssignment package 27094, an Attachment package27096, and a Description package 27098.

FIG. 270B depicts an illustrative package template for aBusinessTransactionDocument 27000B for an SCM. The package templateincludes a BusinessTransactionDocumentItem package 27002B, a Partypackage 27004B, a Location package 27006B, a DeliveryInformation package27008B, a Scheduling package 27010B, a PaymentInformation package27012B, a BusinessDocumentObjectReference package 27014B, and aHandlingUnit package 27016B. The BusinessTransactionDocumentItem package27002B includes a BusinessTransactionDocumentItemScheduleLine package27018B, a BusinessTransactionDocumentItemScheduleLine package 27020B, aRelease package 27022B, a Party package 27024B, a Location package27026B, a ProductInformation package 27028B, a Batch package 27030B, anInventory package 27032B, a Promotion package 27034B, aDeliveryInformation package 27036B, a PriceInformation package 27038B, aPropertyValuation package 27040B, and a Log package 27042B.

FIG. 270C depicts an illustrative package template for Master Data. TheCataloguePublicationTransmission package template 27000C includes aCatalogue package 27002C. The Catalogue package 27002C includes aGlobalInformation package 27004C, a Model package 27006C, and a Contentpackage 27008C. The Model package 27006C includes aPropertyDefinitionClass package 27010C, a PropertyDataType package27012C, a Property package 27014C, a CatalogueItemProperty package27016C, a CatalogueSectionType package 27018C, and a CatalogueSchemapackage 27020C. The Content package 27008C includes a CatalogueItempackage 27022C and a CatalogueView package 27024C.

For example, to generate an Invoice Request using theBusinessTransactionDocument package template 27000 in FIG. 270A, thesystem initially selects the Log package 27004. After receiving anindication from the designer that the Log package 27004 is not requiredfor the Invoice Request, the system removes the package from the packagetemplate. The system then selects the DeliveryExecutionInformationpackage 27006. After receiving an indication from the designer that theDeliveryExecutionInformation package 27006 is not required for theInvoice Request, the system removes this package from the packagetemplate, resulting in the BusinessTransactionDocument package depictedin FIG. 271. The system then selects the Party package 27008. Afterreceiving an indication from the designer that the Party package 27008is required for an Invoice Request, the system copies the entitytemplate from the business object model into the Party package, asdepicted in FIG. 272. The Party package entity template 27200 includes aBTDParty entity 27202, which is specialized into subtypes BTDBuyerPartyentity 27204, BTDCreditorParty entity 27206, BTDSellerParty entity27208, BTDDebtorParty entity 27210, BTDProductRecipientParty entity27212, BTDVendorParty entity 27214, BTDManfacturerParty entity 27216,BTDPayerParty entity 27218, BTDPayeeParty entity 27220, BTDBillToPartyentity 27222, BTDBillFromParty entity 27224, BTDCarrierParty entity27226, BTDRequestorParty entity 27228, BTDPortalProviderParty entity27230, BTDCatalogueProviderParty entity 27232, BTDBidderParty entity27234, and BTDOwnerParty entity 27236.

The system starts by selecting the BTDBuyerParty entity 27204. Afterreceiving an indication from the designer that the BTDBuyerParty entity27204 is required in the Invoice Request, the system proceeds to thenext entity, the BTDCreditorParty entity 27206. After receiving anindication from the designer that the BTDCreditorParty entity 27206 isnot required for the Invoice Request, the system removes this entityfrom the Party package, resulting in the Party package depicted in FIG.273. The system continues with the remaining entities of the Partypackage, and ultimately removes the BTDCreditorParty entity 27206, theBTDDebtorParty entity 27210, the BTDRequestorParty entity 27228, theBTDPortalProviderParty entity 27230, the BTDCatalogueProviderPartyentity 27232, the BTDBidderParty entity 27234, and the BTDOwnerPartyentity 27236. FIG. 274 depicts the Party package after the systemremoves the nonessential entities for the Invoice Request.

The system then retrieves the cardinality between the businesstransaction document and the entity from the business object model. Inthis example, the relevant portions of the business object model aredepicted in FIG. 275. As depicted, the BusinessTransactionDocumentpackage 27500 includes a BTDItem package 27502 and a BTDParty package27504. The cardinality between the BusinessTransactionDocument entity27506 and the BTDItem entity 27508, depicted by line 27510, indicatesthat there is a 1:cn relationship between theBusinessTransactionDocument entity 27506 and the BTDItem entity 27508 inthe business object model. Because the designer may select a subset ofthis cardinality, the designer may select any cardinality between theBusinessTransactionDocument entity 27506 and the BTDItem entity 27508 inthe Invoice Request. For the Invoice Request, the designer selects a 1:nrelationship between the BusinessTransactionDocument entity 27604 andthe BTDItem entity 27606, as depicted by the cardinality 27608, asdepicted in FIG. 276.

The cardinality between the BusinessTransactionDocument entity 27506 andthe BTDParty entity 27512, depicted by line 27514, indicates that thereis a 1:cn relationship between the BusinessTransactionDocument entity27506 and the BTDParty entity 27512. Thus, the designer may select anycardinality between the BusinessTransactionDocument entity 27506 and theBTDParty entity 27512 in the Invoice Request. As depicted in FIG. 276,the designer selects a 1:1 relationship between theBusinessTransactionDocument entity 27604 and the BillToParty entity27610, as depicted by the cardinality 27608. The designer also selects a1:1 relationship between the BusinessTransactionDocument entity 27604and the BillFromParty entity 27614, as depicted by the cardinality27610. The designer selects a 1:c relationship between theBusinessTransactionDocument entity 27604 and the BuyerParty entity27618, the SellerParty entity 27622, the ProductRecipientParty entity27626, the VendorParty entity 27630, the ManufacturerParty entity 27634,the PayerParty entity 27638, the PayeeParty entity 27642, and theCarrierParty entity 27646 as depicted by the cardinalities 27616, 27620,27624, 27628, 27632, 27636, 27640, and 27644, respectively.

The system then selects the next package from the package template 27000depicted in FIG. 271, i.e., the Location package 27010, and continuesremoving packages that are not required in an Invoice Request. Thesystem ultimately removes the Log package 27004, theDeliveryExecutionInformation package 27006, the ProductInformationpackage 27012, the TransportInformation package 27014, the Schedulingpackage 27018, the CreditAgencyReportQueryService package 27020, theCreditWorthinessInformation package 27022, the LegalInformation package27024, the LoanConditionInformation package 27026, the LoanPaymentPlanpackage 27028, the BusinessDocumentObjectReference package 27036, theFollowUpBusinessTransactionDocument package 27038, theAmountAccountingObjectSetAssignment package 27040, the FollowUpMessagepackage 27046, the HandlingUnit package 27048, and thePersonnelTimeSubsheet package 27050 from the BusinessTransactionDocumentpackage 27000, and the Log package 27054, theDeliveryExecutionInformation package 27056, the Batch package 27062, theConfiguration package 27064, the Inventory package 27066, theInventoryChangeItemOutbound package 27068, theInventoryChangeItemlnbound package 27070, the PropertyValuation package27072, the LoanConditionInformation package 27074, the Promotion package27082, the PurchaseRequirementConfirmationItemExecutingPurchaseOrderpackage 27084, the CustomsInformation package 27086, thePaymentInformation package 27090, theAmountAccountingObjectSetAssignment package 27094, and theBusinessTransactionDocumentItemScheduleLine package 27052, from theBusinessTransactionDocumentItem package 27002. FIG. 277 depicts thepackage template after the system removes nonessential packages for theInvoice Request. FIG. 278 depicts the InvoiceRequest package after thesystem substitutes the “BusinessTransactionDocument” in the packagetemplate with “Invoice Request,” i.e., the name of the interface.

Each interface may be represented either as a data model or an elementstructure. The data model depicts the layout of the interface. Thus, thedata model illustrates the arrangement of the various elements withinthe interface. The element structure, on the other hand, provides thedetails regarding each of the elements of the interface.

The complete data model for the Invoice Request and Invoice Confirmationis depicted in FIGS. 279A-N. The data model includes an InvoiceMessagepackage 27900. The InvoiceMessage package 27900 includes a MessageHeaderpackage 27902 and an Invoice package 27904. The InvoiceMessage package27900 also includes an InvoiceMessage entity 27906. The message datatype InvoiceMessage makes the structure available for the message typesInvoiceRequest and InvoiceConfirmation, and the relevant interfaces.

A MessageHeader package groups together the business information that isrelevant for sending a business document in a message. The MessageHeaderpackage 27902 includes a MessageHeader entity 27908. There is a 1:crelationship 27910 between the InvoiceMessage entity 27906 and theMessageHeader entity 27908.

A MessageHeader entity 27908 groups business information from theperspective of the sending application to identify the business documentin a message, to provide information about the sender, and to provideany information about the recipient. The MessageHeader entity 27908 isof type GDT BusinessDocumentMessageHeaderParty. The MessageHeader entity27908 includes an ID, a ReferenceID, and a CreationDateTime. The ID isthe identifier of a business document in a technical message, and is oftype GDT BusinessDocumentMessageID. The ReferenceID is the identifier ofanother instance of a business document in a technical message that thebusiness document references, and is of type GDTBusinessDocumentMessageID. The CreationDateTime is the creation date ofa business document in the technical message, and is of type GDTDateTime. The MessageID is set by the sending application.

The MessageHeader entity 27908 also includes a SenderParty entity 27912and a RecipientParty entity 27914. The SenderParty entity 27912 is theparty responsible for sending a business document at the businessapplication level. The SenderParty entity 27912 is of type GDTBusinessDocumentMessageHeaderParty. A RecipientParty entity 27914 is theparty responsible for receiving a business document at businessapplication level. The RecipientParty entity 27914 is of type GDTBusinessDocumentMessageHeaderParty. The SenderParty entity 27912 and theRecipientParty 27914 entity include additional information required bythe parties 27916, 27918, as discussed in detail below. There is a 1:crelationship 27920 between the MessageHeader entity 27908 and theSenderParty entity 27912A, and a 1:c relationship 27922 between theMessageHeader entity 27908 and the RecipientParty entity 27914.

The Invoice package 27904 is a summary of the invoicing informationrequired for the invoicing process. The Invoice package 27904 includes aParty package 27924, a Location package 27926, a DeliveryInformationpackage 27928, a PaymentInformation package 27930, a PriceInformationpackage 27932, a Tax package 27934, an Attachment package 27936, aDescription package 27938, and an Item package 27940. The Invoicepackage 27904 also includes an Invoice entity 27942. There is a 1:1relationship 27944 between the InvoiceMessage entity 27906 and theInvoice entity 27942.

The Invoice entity 27942 is a binding request from an invoicing party(such as vendor) to an invoice recipient (such as a sold-to-party) tomake payment for the type and quantity of products or services receivedas a result of previous business transactions by a predefined date. TheInvoice entity 27942 does not only specify the remuneration and tax tobe paid by the participating business partners for products and servicesprovided, but also gives detailed information about the paymentconditions and delivery terms.

The Invoice entity 27942 includes an ID, a BillToID, a TypeCode, aDateTime, a CancellationInvoiceIndicator, an AcceptanceStatusCode, and aNote. The ID is the invoice number; a unique identifier that is assignedto the invoice by the invoicing party, and is of type GDTBusinessTransactionDocumentID. The BillToID is a unique identifier thatis assigned to the invoice by the invoice recipient, and is of type GDTBusinessTransactionDocumentPartyID. The TypeCode is a codedrepresentation for the invoice type (a specific invoice/payment request,debit memo, or credit memo), and is of type GDTBusinessTransactionDocumentTypeCode. The DateTime is the invoice date,and is of type GDT DateTime. The CancellationInvoiceIndicator is anindicator that specifies whether the invoice is a cancellation invoiceor not, and is of type GDT InvoiceCancellationInvoiceIndicator. TheAcceptanceStatusCode is a coded representation for the status of theinvoice recipient's acceptance of the invoice, and is of type GDTAcceptanceStatusCode. The Note is a short description/name of theinvoice, and is of type GDT Note. The Invoice is of type GDT Invoice.

The Party package 27924 groups together the business partners that canbe involved in an invoicing process. The Party package 27924 includes aBillToParty entity 27946, a BillFromParty entity 27948, a BuyerPartyentity 27950, a SellerParty entity 27952, a ProductRecipientParty entity27954, a VendorParty entity 27956, a ManufacturerParty entity 27958, aPayerParty entity 27960, a PayeeParty entity 27962, and a CarrierPartyentity 27964. There is a 1:1 relationship 27966 between the Invoiceentity 27942 and the BillToParty entity 27946. There is a 1:1relationship 27968 between the Invoice entity 27942 and theBillFromParty entity 27948. There is a 1:c relationship 27970 betweenthe Invoice entity 27942 and the BuyerParty entity 27950. There is a 1:crelationship 27972 between the Invoice entity 27942 and the SellerPartyentity 27952. There is a 1:c relationship 27974 between the Invoiceentity 27942 and the ProductRecipientParty entity 27954. There is a 1:crelationship 27976 between the Invoice entity 27942 and the VendorPartyentity 27956. There is a 1:c relationship 27978 between the Invoiceentity 27942 and the ManufacturerParty entity 27958. There is a 1:crelationship 27980 between the Invoice entity 27942 and the PayerPartyentity 27960. There is a 1:c relationship 27982 between the Invoiceentity 27942 and the PayeeParty entity 27962. There is a 1:crelationship 27984 between the Invoice entity 27942 and the CarrierPartyentity 27964.

The BillToParty is the company or person to which/whom the invoice is tobe sent for deliveries received or services provided. The BillToPartyentity 27946 is of type GDT BusinessTransactionDocumentParty. TheBillToParty also can fulfill the functions of the BuyerParty,ProductRecipientParty, and PayerParty. The BillToParty entity 27946includes an Address entity 27986 and a Contact entity 27988. There is a1:c relationship 27990 between the BillToParty entity 27946 and theAddress entity 27986. There is a 1:c relationship 27992 between theBillToParty entity 27946 and the Contact entity 27988.

The Address entity 27986 includes a PersonName entity 27994, an Officeentity 27996, a PhysicalAddress entity 27998, a GeoCoordinates entity27900A, and a Communication entity 27902A. There is a 1:c relationship27904A between the Address entity 27986 and the PersonName entity 27994.There is a 1:c relationship 27906A between the Address entity 27986 andthe Office entity 27996. There is a 1:c relationship 27908A between theAddress entity 27986 and the PhysicalAddress entity 27998. There is a1:c relationship 27910A between the Address entity 27986 and theGeoCoordinates entity 27900A. There is a 1:c relationship 27912A betweenthe Address entity 27986 and the Communication entity 27902A.

The Contact entity 27988 includes an Address entity 27914A. There is a1:c relationship 27916A between the Contact entity 27988 and the Addressentity 27914A. Similar to the Address entity in the BillToParty entity27946 discussed above, the Address entity 27914A in the Contact entity27988 includes a PersonName entity 27918A, an Office entity 27920A, aPhysicalAddress entity 27922A, a GeoCoordinates entity 27924A, and aCommunication entity 27926A. There is a 1:c relationship 27928A betweenthe Address entity 27914A and the PersonName entity 27918A. There is a1:c relationship 27930A between the Address entity 27914A and the Officeentity 27920A. There is a 1:c relationship 27932A between the Addressentity 27914A and the PhysicalAddress entity 27922A. There is a 1:crelationship 27934A between the Address entity 27914A and theGeoCoordinates entity 27924A. There is a 1:c relationship 27936A betweenthe Address entity 27914A and the Communication entity 27926A.

Each of the BillFromParty entity 27948, the BuyerParty entity 27950, theSellerParty entity 27952, the ProductRecipientParty entity 27954, theVendorParty entity 27956, the ManufacturerParty entity 27958, thePayerParty entity 27960, the PayeeParty entity 27962, and theCarrierParty entity 27964 includes the same elements as that describedfor the BillToParty entity 27946 as denoted by ellipses 27938A, 27940A,27942A, 27944A, 27946A, 27948A, 27950A, 27952A, and 27954A.

The BillFromParty is the company or person executing the invoicingprocess. The BillFromParty entity 27948 is of type GDTBusinessTransactionDocumentParty. The BillFromParty also can fulfill thefunction of the SellerParty, VendorParty, and PayeeParty.

The BuyerParty is the company or person authorizing the deliveries orservices. The BuyerParty entity 27950 is of type GDTBusinessTransactionDocumentParty. If a BuyerParty is not specifiedexplicitly in an invoice, the BillToParty also acts as the BuyerParty.

The SellerParty is the company or person selling (sales/service area).The SellerParty entity 27952 is of type GDTBusinessTransactionDocumentParty. If a SellerParty is not specifiedexplicitly in an invoice, the BillFromParty also acts as theSellerParty.

The ProductRecipientParty is the company or person to which/whom goodsare delivered or for which/whom services are provided. TheProductRecipientParty entity 27954 is of type GDTBusinessTransactionDocumentParty. If a ShipToLocation is not specifiedexplicitly in an invoice, the address of the ProductRecipientParty isthe delivery address. If a ProductRecipientParty is not specifiedexplicitly in an invoice, the BuyerParty is also theProductRecipientParty.

The VendorParty is the company or person delivering the goods orproviding the service. The VendorParty entity 27956 is of type GDTBusinessTransactionDocumentParty. If a ShipFromLocation is not specifiedexplicitly in an invoice, the address of the VendorParty is theship-from address. If a VendorParty is not explicitly specified in aninvoice, the SellerParty is also the VendorParty. The CarrierParty, notthe VendorParty, is the company or person that is solely responsible fortransporting the goods.

The ManufacturerParty is the company or person which/who produced thegoods being invoiced. The ManufacturerParty entity 27958 is of type GDTBusinessTransactionDocumentParty. The ManufacturerParty can be used forinvoice items relating to materials, and can be used to uniquely definethe context of a ManufacturerProductID.

The PayerParty is the company or person that pays for the goods orservices provided. The PayerParty entity 27960 is of type GDTBusinessTransactionDocumentParty. If a PayerParty is not specifiedexplicitly in an invoice, the BillToParty also acts as the PayerParty.

The PayeeParty is the company or person that receives payment for thegoods or services provided. The PayeeParty entity 27962 is of type GDTBusinessTransactionDocumentParty. If a PayeeParty is not specifiedexplicitly in an invoice, the BillFromParty also acts as the PayeeParty.

The CarrierParty is the company or person that transported the goods.The CarrierParty entity 27964 is of type GDTBusinessTransactionDocumentParty. The CarrierParty is to be used forinvoice items relating to materials; it can be ignored by the recipientin the case of items relating to services. In certain businesstransactions involving delivery across countries, the CarrierParty isrequired for fiscal law purposes.

The Location package 27926 groups together the of the locations that canoccur in an invoicing process. The Location package 27926 includes aShipToLocation entity 27956A and a ShipFromLocation entity 27958A. Thereis a 1:c relationship 27960A between the Invoice entity 27942 and theShipToLocation entity 27956A. There is also a 1:c relationship 27962Abetween the Invoice entity 27942 and the ShipFromLocation entity 27958A.

The invoicing system uses locations that are specified at the Invoicelevel for the items for which corresponding locations are not explicitlytransferred. The invoicing system can use the ShipToLocation entity27956A and the ShipFromLocation entity 27958A to provide a more detaileddescription of the flow of goods between the delivery point and thedispatch point. In certain countries, such as the United States, thisdetailed information is required for calculating taxes.

The ShipToLocation is the location to which goods were delivered orwhere services were provided. The ShipToLocation entity 27956A is oftype GDT BusinessTransactionDocumentLocation. For example, if aBuyerParty headquartered in California orders steel beams for a buildinglocated in Arizona, the tax amount is calculated using the tax ratesthat are valid in Arizona.

The ShipToLocation entity 27956A includes an Address entity 27964A.There is a 1:c relationship 27966A between the ShipToLocation entity27956A and the Address entity 27964A. The Address entity 27964A includesa PersonName entity 27968A, an Office entity 27970A, a PhysicalAddressentity 27972A, a GeoCoordinates entity 27974A, and a Communicationentity 27976A. There is a 1:c relationship 27978A between the Addressentity 27964A and the PersonName entity 27968A. There is a 1:crelationship 27980A between the Address entity 27964A and the Officeentity 27970A. There is a 1:c relationship 27982A between the Addressentity 27964A and the PhysicalAddress entity 27972A. There is a 1:crelationship 27984A between the Address entity 27964A and theGeoCoordinates entity 27974A. There is a 1:c relationship 27986A betweenthe Address entity 27964A and the Communication entity 27976A.

The ShipFromLocation 27958A is the location from which goods wereshipped. The ShipFromLocation entity 27958A is of type GDTBusinessTransactionDocumentLocation. The ShipFromLocation entity 27958Aincludes the same entities 27988A as the ShipToLocation entity 27956A.

The DeliveryInformation package 27928 summarizes the information for adelivery in the invoicing process. The Delivery Information package27928 includes a DeliveryTerms entity 27990A. There is a 1:crelationship 27992A between the Invoice entity 27942 and theDeliveryTerms entity 27990A. The DeliveryTerms are the conditions andagreements that are valid for executing the delivery and transportingthe ordered goods and for the necessary services and activities. TheDeliveryTerms entity 27990A is of type GDT DeliveryTerms.

The DeliveryTerms entity 27990A includes an Incoterms entity 27994A.There is a 1:c relationship 27996A between the DeliveryTerms entity27990A and the Incoterms entity 27994A.

The PaymentInformation package 27930 summarizes the payment informationin the invoicing process. The PaymentInformation package 27930 includesa CashDiscountTerms entity 27998A and a PaymentForm entity 27900B. Thereis a 1:c relationship 27902B between the Invoice entity 27942 and theCashDiscountTerms entity 27998A. There is a 1:c relationship 27904Bbetween the Invoice entity 27942 and the PaymentForm entity 27900B.

The CashDiscountTerms includes the payment conditions (cash discountrates and payment deadlines). The CashDiscountTerms entity 27998A is oftype GDT CashDiscountTerms. The CashDiscountTerms entity 27998A includesa MaximumDiscount entity 27906B and a NormaIDiscount entity 27908B.There is a 1:c relationship 27910B between the CashDiscountTerms entity27998A and the MaximumDiscount entity 27906B. There is a 1:crelationship 27912B between the CashDiscountTerms entity 27998A and theNormaIDiscount entity 27908B.

The PaymentForm specifies the method of payment for a product. ThePaymentForm entity 27900B includes the element PaymentFormCode, which isthe coded representation of the payment form and is of type GDTPaymentFormCode. The PaymentForm entity 27900B includes a PaymentCardentity 27914B. There is a 1:c relationship 27916B between thePaymentForm entity 27900B and the PaymentCard entity 27914B.

The PriceInformation package 27932 summarizes the information about thetotal amount invoiced for the provided products or services, which arelisted at item level. The Price is the total amount invoiced forproducts and services delivered or provided, including the tax and netportions. The Price entity includes a GrossAmount, a NetAmount, and aTaxAmount. The GrossAmount is the gross amount of an invoice (net amountplus tax amount), and is of type GDT Amount. The NetAmount is the netamount of an invoice, and is of type GDT Amount. The TaxAmount is thetax amount of an invoice, and is of type GDT Amount. ThePriceInformation package 27932 includes a Price entity 27918B. There isa 1:c relationship 27920B between the Invoice entity 27942 and the Priceentity 27918B.

The Tax package 27934 summarizes the information about the tax pricecomponents in the total amount invoiced for products delivered orservices provided. The Tax package 27934 includes a ProductTax entity27922B. There is a 1:cn relationship 27924B between the Invoice entity27942 and the ProductTax entity 27922B. The ProductTax is the tax amountinvoiced for products or services delivered or provided, cumulated forthe invoice items. The ProductTax entity 27922B is of type GDTProductTax.

The Attachment package 27936 groups together the attachment informationrelating to the invoice. The Attachment package 27936 includes anAttachment entity 27926B. There is a 1:cn relationship 27928B betweenthe Invoice entity 27942 and the Attachment entity 27926B. TheAttachment entity 27926B is a document of any type that relates to theinvoice and is transferred with it, and is of type GDT Attachment.

The Description package 27938 groups together the explanatory textsrelating to an invoice. The Description package 27938 includes aDescription entity 27930B and a ConfirmationDescription entity 27932B.There is a 1:c relationship 27934B between the Invoice entity 27942 andthe Description entity 27930B, and a 1:c relationship 27936B between theInvoice entity 27942 and the ConfirmationDescription entity 27932B. TheDescription is a natural language text relating to the invoice, which isvisible to business parties. The Description entity 27930B is of typeGDT Description. The Description can be used for the textual informationrelating to the invoice transferred. An example of this would beinformation stating that the Sales employee responsible is on vacationas of a specific date and indicating the name and telephone number of asubstitute as of this date.

The ConfirmationDescription is a natural language text relating to theinvoice confirmation, which is visible to business parties. TheConfirmationDescription entity 27932B is of type GDT Description. Theinvoicing system does not use ConfirmationDescription in anInvoiceRequest. The invoicing system can use the ConfirmationDescriptionfor the textual information relating to the invoice confirmation. Anexample of this would be the invoice recipient's justification forrejecting a particular invoice.

The InvoiceItem package (“Item package”) 27940 groups together theinformation about the amounts invoiced or credited for products, brokendown according to the type and scope of the goods delivered or theservices provided. The Item package 27940 includes a ProductInformationpackage 27938B, a PriceInformation package 27940B, a Tax package 27942B,a Party package 27944B, a Location package 27946B, a DeliveryInformationpackage 27948B, a BusinessTransactionDocumentReference package 27950B,an Attachment package 27952B, and a Description package 27954B. The Itempackage 27940 also includes an Item entity 27956B. There is a 1:nrelationship 27958B between the Invoice entity 27942 and the Item entity27956B. InvoiceItems 27956B are arranged hierarchically using aHierarchyRelationship 27960B. The HierarchyRelationship 27960B is therelationship between a sub-item and a higher-level parent item in anitem hierarchy. There is a 1:cn relationship 27962B between the Itementity 27956B and its subordinate entities. There is a 1:c relationship27964B between the Item entity 27956B and its superordinate entities.HierarchyRelationship includes a ParentItemID, a ParentItemBillToID, anda TypeCode. The ParentitemID is the reference to a parent item with theitem number assigned by the invoicing party.InvoiceItemHierarchyRelationshipParentItemID is of type GDTBusinessTransactionDocumentItemID. The ParentItemBillToID is thereference to a parent item with the item number assigned by the invoicerecipient. InvoiceItemHierarchyRelationshipParentItemID is of type GDTBusinessTransactionDocumentItemID. The TypeCode is a codedrepresentation of the hierarchical relationship between the sub-item andits higher-level parent item. InvoiceItemHierarchyRelationshipTypeCodeis of type GDT BusinessTransactionDocumentItemHierarchyRelationshipTypeC ode.

The InvoiceItem is part of an invoice containing the prices and taxesfor the quantity of a product that has been delivered or for a servicethat has been provided. In addition, to the information about prices andtaxes, the InvoiceItem includes information about the participatingbusiness partners, the payment conditions, and the delivery terms, ifthey differ from the information provided in the invoice header.

The InvoiceItem entity 27956B includes an ID, a BillToID, a TypeCode, aDeliveryPeriod, and a Quantity. The ID is an invoice item number; aunique identifier that is assigned to the invoice item by the invoicingparty, and is of type GDT BusinessTransactionDocumentItemID. TheBillToID is a unique identifier that is assigned to the invoice item bythe invoice recipient, and is of type GDTBusinessTransactionDocumentItemPartyID. The TypeCode is a codedrepresentation for the invoice item type (a specific invoice item,credit memo item, or shipping costs item), and is of type GDTBusinessTransactionDocumentItemTypeCode. The DeliveryPeriod is thedelivery date of the products invoiced or the time period in which theservice was provided, and is of type GDT DateTimePeriod. The Quantity isthe quantity invoiced, and is of type GDT Quantity.

The InvoiceItemProductInformation package (“ProductInformation package”)27938B summarizes the information for identifying, describing, andclassifying a product in an invoice item. The ProductInformation package27938B includes a Product entity 27966B and a ProductCategory entity27968B. There is a 1:c relationship 27970B between the Item entity27956B and the Product entity 27966B. There is a 1:c relationship 27972Bbetween the Item entity 27956B and the ProductCategory entity 27968B.

The Product identifies, describes, and classifies the product that hasbeen invoiced. The Product entity 27966B is of type GDTBusinessTransactionDocumentProduct. With the exception of groupinghierarchy items, at least either the product number or productdescription (note) is specified when a new item is created. If both theproduct number and description are specified, the description is merelyadditional information in the message and can be ignored by therecipient.

The ProductCategory is the assignment of an invoiced product to ahigher-level, business-specific category. The ProductCategory entity27968B is of type GDT BusinessTransactionDocumentProductCategory. Theproduct category is derived directly from the product if a productnumber is specified for the product. It can differ for the buyer andseller if they have classified the same product differently. This isallowed and should be tolerated by the systems involved.

The InvoiceItemPriceInformation package (“PriceInformation package”)27940B summarizes the information about the amount invoiced for aproduct delivered or a service provided, including the price components.The PriceInformation package 27940B includes a Price entity 27974B.There is a 1:1 relationship 27976B between the Item entity 27956B andthe Price entity 27974B. The Price is the amount invoiced for adelivered product or a service provided, including the tax and netportions. The Price includes a GrossAmount, a NetAmount, a TaxAmount, aNetUnitPrice, an ExchangeRate, and a PricingDate. The GrossAmount is thegross amount of an item (net amount plus tax amount), and is of the typeGDT Amount. The NetAmount is the net amount of an item, and is of thetype GDT Amount. The TaxAmount is the tax amount of an item, and is ofthe type GDT Amount. The NetUnitPrice is the net price for the basequantity of a product and that was used to calculate the net amount. Forexample:

10 for 5 pieces. The NetUnitPrice is of the type GDT Price. TheExchangeRate is information about the exchange rate, and is of the typeGDT ExchangeRate. The PricingDate is the date on which the price iscalculated, and is of the type GDT Date.

The Price entity 27974B also includes a Component entity 27978B. Thereis a 1:cn relationship 27980B between the Price entity 27974B and theComponent entity 27978B. The invoicing system specifies the elementsNetAmount and GrossAmount if the invoice item specified is not agrouping hierarchy item.

The Component is a non-fiscal part of a price in an invoice item. TheComponent entity 27978B is of type GDT PriceComponent. An invoice itemcan contain several price components. A detailed list of the pricecomponents (including, for instance, rounding difference clearing) isprovided to help the invoice recipient understand the composition of theamount invoiced. In B2B standards, such as RosettaNet (PIP 3C3 version1.1) or xCBL 3.0, price components are not available in this form. As aresult, the usual elements in B2B standards, namely, GrossAmount andNetAmount, are stressed explicitly and are shown redundantly alongsidethe detailed list that includes price components. Taxes also are pricecomponents that are shown explicitly because of legal aspects. Taxinformation (ProductTax) is not shown redundantly. The Price entityincludes a Component entity. There is a 1:cn relationship between thePrice entity and the Component entity.

The InvoiceItemTax package (“Tax package”) 27942B summarizes theinformation about the tax price components in the total amount invoicedfor delivered products or services provided. The Tax package 27942Bincludes a ProductTax entity 27982B. There is a 1:cn relationship 27984Bbetween the Item entity 27956B and the ProductTax entity 27982B. TheProductTax is a tax price component of an invoice item that is incurredfor each tax type and rate. The ProductTax entity 27982B is of type GDTProductTax.

The InvoiceItemParty package (“Party package”) 27944B groups togetherthe business partners that can be involved in an invoice item. Theseparties are different from the partners specified at the Invoice level.The Party package 27944B in the Item package 27940 includes a BuyerPartyentity 27986B, a SellerParty entity 27988B, a ProductRecipientPartyentity 27990B, a VendorParty entity 27992B, a ManufacturerParty entity27994B, and a CarrierParty entity 27996B. There is a 1:c relationship27998B between the Item entity 27956B and the BuyerParty entity 27986B.There is a 1:c relationship 27900C between the Item entity 27956B andthe SellerParty entity 27988B. There is a 1:c relationship 27902Cbetween the Item entity 27956B and the ProductRecipientParty entity27990B. There is a 1:c relationship 27904C between the Item entity27956B and the VendorParty entity 27992B. There is a 1:c relationship27906C between the Item entity 27956B and the ManufacturerParty entity27994B. There is a 1:c relationship 27908C between the Item entity27956B and the CarrierParty entity 27996B. Each of these partiesincludes the same elements as those described for the BillToParty entity27946 as denoted by ellipses 27910C, 27912C, 27914C, 27916C, 27918C,27920C.

The Location package 27946B in the Item package 27940 includes aShipToLocation entity 27922C and a ShipFromLocation entity 27924C. Thereis a 1:c relationship 27926C between the Item entity 27956B and theShipToLocation entity 27922C. There is a 1:c relationship 27928C betweenthe Item entity 27956B and the ShipFromLocation entity 27924C. TheShipToLocation entity 27922C and the ShipFromLocation entity 27924Cinclude the same elements as those described for the ShipToLocationentity 27956A as denoted by ellipses 27930C, 27932C.

The DeliveryInformation package 27948B in the Item package 27940includes a DeliveryTerms entity 27934C. There is a 1:c relationship27936C between the Item entity 27956B and the DeliveryTerms entity27934C. The DeliveryTerms entity 27934C includes an Incoterms entity27938C. There is a 1:c relationship 27940C between the DeliveryTermsentity 27934C and the Incoterms entity 27938C.

The InvoiceItemBusinessTransactionDocumentReference package(“BusinessTransactionDocumentReference package”) 27950B groups togetherthe references to business documents that can be required in theinvoicing process at item level. TheBusinessTransactionDocumentReference package 27950B in the Item package27940 includes a PurchaseOrderReference entity 27942C, aSalesOrderReference entity 27944C, a DeliveryReference entity 27946C, aServiceAcknowledgementReference entity 27948C, an OriginInvoiceReferenceentity 27950C, a PurchaseContractReference entity 27952C, aSalesContractReference entity 27954C, a BuyerProductCatalogueReferenceentity 27956C, and a VendorProductCatalogueReference entity 27958C.There is a 1:cn relationship 27960C between the Item entity 27956B andthe PurchaseOrderReference entity 27942C. There is a 1:cn relationship27962C between the Item entity 27956B and the SalesOrderReference entity27944C. There is a 1:c relationship 27964C between the Item entity27956B and the DeliveryReference entity 27946C. There is a 1:crelationship 27966C between the Item entity 27956B and theServiceAcknowledgementReference entity 27948C. There is a 1:crelationship 27968C between the Item entity 27956B and theOriginInvoiceReference entity 27950C. There is a 1:c relationship 27970Cbetween the Item entity 27956B and the PurchaseContractReference entity27952C. There is a 1:c relationship 27972C between the Item entity27956B and the SalesContractReference entity 27954C. There is a 1:crelationship 27974C between the Item entity 27956B and theBuyerProductCatalogueReference entity 27956C. There is a 1:crelationship 27976C between the Item entity 27956B and theVendorProductCatalogueReference entity 27958C.

The PurchaseOrderReference is the reference to a purchase order or anitem within a purchase order. The PurchaseOrderReference entity 27942Cis of type GDT BusinessTransactionDocumentReference. ThePurchaseOrderReference includes the purchase order number and purchaseorder item number assigned by the buyer. There can be more than onePurchaseOrderReference.

The SalesOrderReference is the reference to an order or an item withinan order. The SalesOrderReference entity 27944C is of type GDTBusinessTransactionDocumentReference. The SalesOrderReference includesthe order number and order item number assigned by the seller. There canbe more than one SalesOrderReference.

The DeliveryReference is the reference to a delivery. TheDeliveryReference entity 27946C is of type GDTBusinessTransactionDocumentReference. The DeliveryReference includes thedelivery note number assigned by the seller.

The ServiceAcknowledgementReference is the reference to a confirmationthat a service has been provided, which was created by the seller (forexample, in the service entry system). TheServiceAcknowledgementReference entity 27948C is of type GDTBusinessTransactionDocumentReference. ServiceAcknowledgementReferenceincludes the service acknowledgment number assigned by the serviceprovider.

The OriginInvoiceReference is the reference to an invoice previouslysent. The OriginInvoiceReference entity 27950C is of type GDTBusinessTransactionDocumentReference. An OriginInvoiceReference includesthe invoice number assigned by the invoicing party. This reference isrequired if a credit memo is issued for an amount that has beeninvoiced.

The PurchaseContractReference is the reference to a purchase contract oran item within a purchase contract. The PurchaseContractReference entity27952C is of type GDT BusinessTransactionDocumentReference. Provided ithas not been agreed otherwise, the seller is responsible for determiningthe correct SalesContractReference for a specifiedPurchaseContractReference.

The SalesContractReference is the reference to a sales contract or anitem within a sales contract. The SalesContractReference entity 27954Cis of type GDT BusinessTransactionDocumentReference.

The BuyerProductCatalogueReference is the reference to a buyer's productCatalogue or an item within such a catalogue. TheBuyerProductCatalogueReference entity 27956C is of type GDTCatalogueReference. The BuyerProductCatalogueReference is filled if aninvoice item refers to a Catalogue whose number and item numbers wereassigned by the buyer.

The VendorProductCatalogueReference is the reference to a seller'sproduct Catalogue or an item within such a catalogue. TheVendorProductCatalogueReference entity 27958C is of type GDTCatalogueReference. The invoicing system always fillsVendorProductCatalogueReference if an invoice item refers to a Cataloguewhose number and item numbers were assigned by the seller.

The Attachment package 27952B in the Item package 27940 includes anAttachment entity 27978C. There is a 1:cn relationship 27980C betweenthe Item entity 27956B and the Attachment entity 27978C.

The Description package 27954B in the Item package 27940 includes aDescription entity 27982C and a ConfirmationDescription entity 27984C.There is a 1:c relationship 27986C between the Item entity 27956B andthe Description entity 27982C and a 1:c relationship 27988C between theItem entity 27956B and the ConfirmationDescription entity 27984C.

FIGS. 280A-K depict the element structure for the Invoice interfaces.The element structure is similar to the data model, but providesadditional information regarding the details of the interface. Theelement structure identifies the different packages 28000 in theinterface, and represents the entities at various levels within theinterface. As depicted in FIGS. 280A-K, the Interface interfaces includefive levels 28002, 28004, 28006, 28008, 28010. The element structureidentifies the cardinality or occurrence 28012 between the entitiesand/or attributes of the interface, and provides information (i.e., type28014 and name 28016) regarding the data type that provides the basisfor the entity and/or attribute. The outermost package of this interfaceis an InvoiceMessage package 28018, which includes an InvoiceMessageentity 28020 at the first level 28002. The InvoiceMessage entity 28020is of type message data type (“MDT”) 28022 “InvoiceMessage” 28024.

The InvoiceMessage package 28018 includes a MessageHeader package 28026and an Invoice package 28028. The MessageHeader package 28026 includes aMessageHeader entity 28030, which is of type generic data type (“GDT”)28034 “MessageHeader” 28036. There is one or zero 28032 MessageHeaderentity 28030 for each InvoiceMessage entity 28020.

The MessageHeader entity 28030 includes a MessageID 28038, aReferenceMessageID 28046, and a CreationDateTime 28054. The MessageID28038 is of type GDT 28042 MessageID 28044. The ReferenceMessageID 28046is of type GDT 28050 MessageID 28052. The CreationDateTime 28054 is oftype GDT 28058 DateTime 28060. There is one 28040 MessageID 28038 foreach MessageHeader entity 28030, one or zero 28048 ReferenceMessageID28046 for each MessageHeader entity 28030, and one 28056CreationDateTime 28054 for each MessageHeader entity 28030.

The MessageHeader entity 28030 also includes a SenderParty entity 28062and a RecipientParty entity 28070. The SenderParty entity 28062 is oftype GDT 28066 BusinessDocumentMessageHeaderParty 28068. TheRecipientParty entity 28070 is also of type GDT 28074BusinessDocumentMessageHeaderParty 28076. There is one or zero 28064SenderParty entity 28062 for each MessageHeader entity 28030, and thereis one or zero 28072 RecipientParty entity 28070 for each MessageHeaderentity 28030.

The Invoice package 28028 includes an Invoice entity 28078. The Invoiceentity 28078 is of type GDT 28080 Invoice 28081. There is one 28079Invoice entity 28078 for each InvoiceMessage entity 28020. The Invoiceentity 28078 includes an ID 28082, a BillToID 28090, a TypeCode 28098, aDateTime 28006A, a CancellationInvoiceIndicator 28014A, anAcceptanceStatusCode 28022A, and a Note 28030A. The ID 28082 is of typeGDT 28086 BusinessTransactionDocumentID 28088. The BillToID 28090 is oftype GDT 28094 BusinessTransactionDocumentID 28096. The TypeCode 28098is of type GDT 28002A BusinessTransactionDocumentTypeCode 28004A. TheDateTime 28006A is of type GDT 28010A DateTime 28012A. TheCancellationInvoiceIndicator 28014A is of type GDT 28018AInvoiceCancellationInvoiceIndicator 28020A. The AcceptanceStatusCode28022A is of type GDT 28026A AcceptanceStatusCode 28028A. The Note28030A is of type GDT 28034A Note 28036A. There is one 28084 ID 28082for each Invoice entity 28078. There is one or zero 28092 BillToID 28090for each Invoice entity 28078. There is one 28000A TypeCode 28098 foreach Invoice entity 28078. There is one 28008A DateTime 28006A for eachInvoice entity 28078. There is one or zero 28016ACancellationInvoiceIndicator 28014A for each Invoice entity 28078. Thereis one or zero 28024A AcceptanceStatusCode 28022A for each Invoiceentity 28078. There is one or zero 28032A Note 28030A for each Invoiceentity 28078.

The Party package 28038A includes a BillToParty entity 28056A, aBillFromParty entity 28064A, a BuyerParty entity 28072A, a SellerPartyentity 28080A, a ProductRecipientParty entity 28088A, a VendorPartyentity 28096A, a ManufacturerParty entity 28004B, a PayerParty entity28012B, a PayeeParty entity 28020B, and a CarrierParty entity 28028B.The BillToParty entity 28056A is of type GDT 28060ABusinessTransactionDocumentParty 28062A. There is one 28058A BillToPartyentity 28056A for each Invoice entity 28078. The BillFromParty entity28064A is of type GDT 28068A BusinessTransactionDocumentParty 28070A.There is one 28066A BillFromParty entity 28064A for each Invoice entity28078. The BuyerParty entity 28072A is of type GDT 28076ABusinessTransactionDocumentParty 28078A. There is one or zero 28074ABuyerParty entity 28072A for each Invoice entity 28078. The SellerPartyentity 28080A is of type GDT 28084A BusinessTransactionDocumentParty28086A. There is one or zero 28082A SellerParty entity 28080A for eachInvoice entity 28078. The ProductRecipientParty entity 28088A is of typeGDT 28092A BusinessTransactionDocumentParty 28094A. There is one or zero28090A ProductRecipientParty entity 28088A for each Invoice entity28078. The VendorParty entity 28096A is of type GDT 28000BBusinessTransactionDocumentParty 28002B. There is one or zero 28098AVendorParty entity 28096A for each Invoice entity 28078. TheManufacturerParty entity 28004B is of type GDT 28008BBusinessTransactionDocumentParty 28010B. There is one or zero 28006BManufacturerParty entity 28004B for each Invoice entity 28078. ThePayerParty entity 28012B is of type GDT 28016BBusinessTransactionDocumentParty 28018B. There is one or zero 28014BPayerParty entity 28012B for each Invoice entity 28078. The PayeePartyentity 28020B is of type GDT 28024B BusinessTransactionDocumentParty28026B. There is one or zero 28022B PayeeParty entity 28020B for eachInvoice entity 28078. The CarrierParty entity 28028B is of type GDT28032B BusinessTransactionDocumentParty 28034B. There is one or zero28030B CarrierParty entity 28028B for each Invoice entity 28078.

The Location package 28040A includes a ShipToLocation entity 28036B anda ShipFromLocation entity 28044B. The ShipToLocation entity 28036B is oftype GDT 28040B BusinessTransactionDocumentLocation 28042B. There is oneor zero 28038B ShipToLocation entity 28036B for each Invoice entity28078. The ShipFromLocation entity 28044B is of type GDT 28048BBusinessTransactionDocumentLocation 28050B. There is one or zero 28046BShipFromLocation entity 28044B for each Invoice entity 28078.

The DeliveryInformation package 28042A includes a DeliveryTerms entity28052B, which is of type GDT 28056B DeliveryTerms 28058B. There is oneor zero 28054B DeliveryTerms entity 28052B for each Invoice entity28078.

The PaymentInformation package 28044A includes a CashDiscountTermsentity 28060B, which is of type GDT 28064B CashDiscountTerms 28066B.There is one or zero 28062B CashDiscountTerms entity 28060B for eachInvoice entity 28078. The PaymentInformation package 28044A alsoincludes a PaymentForm entity 28068B, which if of type GDT 28071BPaymentForm 28072B. There is one or zero 28070B PaymentForm entity28068B for each Invoice entity 28078.

The PriceInformation package 28046A includes a Price entity 28088B.There is one 28090B Price entity 28088B for each Invoice entity 28078.The Price entity 28088B includes a GrossAmount 28092B, a NetAmount28000C, a TaxAmount 28008C and an ExchangeRate 28016C. The GrossAmount28092B is of type GDT 28096B Amount 28098B. There is one 28094BGrossAmount 28092B for each Price entity 28088B. The NetAmount 28000C isof type GDT 28004C Amount 28006C. There is one or zero 28002C NetAmount28000C for each Price entity 28088B. The TaxAmount 28008C is of type GDT28012C Amount 28014C. There is one or zero 28010C TaxAmount 28008C foreach Price entity 28088B. The ExchangeRate 28016C is of type GDT 28020CExchangeRate 28022C. There is one or zero 28018C ExchangeRate 28016C foreach Price entity 28088B.

The Tax package 28048A includes a ProductTax entity 28024C, which is oftype GDT 28028C ProductTax 28030C. There are any number 28026C ofProductTax entities 28024C for each Invoice entity 28078.

The Attachment package 28050A includes an Attachment entity 28032C,which is of type GDT 28036C Attachment 28038C. There are any number28034C of Attachment entities 28032C for each Invoice entity 28078.

The Description package 28052A includes a Description entity 28040C anda ConfirmedDescription entity 28048C. The Description entity 28040C isof type GDT 28044C Description 28046C. There is one or zero 28042CDescription entity 28040C for each Invoice entity 28078. TheConfirmedDescription entity 28048C is of type GDT 28052C Description28054C. There is one or zero 28050C ConfirmedDescription entity 28048Cfor each Invoice entity 28078.

The Item package 28054A includes an Item entity 28056C, which is of typeGDT 28058C InvoiceItem 28059C. There is one or more 28057C Item entities28056C for each Invoice entity 28078. The Item entity 28056C includes anID 28060C, a BillToID 28068C, a TypeCode 28076C, a Quantity 28084C, aHierarchyRelationship 28092C, and a DeliveryPeriod 28012D. The ID 28060Cis of type GDT 28064C BusinessTransactionDocumentItemID 28066C, andthere is one 28062C ID 28060C for each Item entity 28056C. The BillToID28068C is of type GDT 28072C BusinessTransactionDocumentItemPartyID28074C, and there is one or zero 28070C BillToID 28068C for each Itementity 28056C. The TypeCode 28076C is of type GDT 28080CBusinessTransactionDocumentItemTypeCode 28082C, and there is one 28078CTypeCode 28076C for each Item entity 28056C. The Quantity 28084C is oftype GDT 28088C Quantity 28090C, and there is one or zero 28086CQuantity 28090C for each Item entity 28056C. There is one or zero 28094CHierarchyRelationship 28092C for each Item entity 28056C. TheHierarchyRelationship 28092C includes a ParentItemID 28096C, which is oftype GDT 28000D BusinessTransactionDocumentItemID 28002C, and a TypeCode28004D, which is of type CDT 28008D ItemHierarchyRelationshipTypeCode28010D. There is one 28098C ParentItemID 28096C for eachHierarchyRelationship 28092C, and there is one 28006D TypeCode 28004Dfor each HierarchyRelationship 28092C. The DeliveryPeriod entity 28012Dis of type GDT 28016D DateTimePeriod 28018D, and there is one or zero28014D DeliveryPeriod entity 28012D for each Item entity 28056C. TheItem package 28054A also includes a ProductInformation package 28020D, aPriceInformation package 28022D, a Tax package 28024D, a Party package28026D, a Location package 28028D, a DeliveryInformation package 28030D,a BusinessTransactionDocumentReference package 28032D, an Attachmentpackage 28034D and a Description package 28036D.

The ProductInformation package 28020D includes a Product entity 28038Dand a Product Category entity 28046D. The Product entity 28038D is oftype GDT 28042D Product 28044D. There is one or zero 28040D Productentity 28038D for each Item entity 28056C. The ProductCategory entity28046D is of type GDT 28050D ProductCategory 28052D. There is one orzero 28048D ProductCategory entity 28046D for each Item entity 28056C.

The PriceInformation package 28022D includes a Price entity 28054D.There is one or zero 28056D Price entity 28054D for each Item entity28056C. The Price entity 28054D includes a GrossAmount 28058D, aNetAmount 28066D, a TaxAmount 28074D, and a NetUnitPrice 28082.

The GrossAmount 28058D is of type GDT 28062D Amount 28064D, and there isone or zero 28060D GrossAmounts 28058D for each Price entity 28054D. TheNetAmount 28066D is of type GDT 28070D Amount 28072D, and there is one28068D NetAmount 28066D for each Price entity 28054D. The TaxAmount28074D is of type GDT 28078D Amount 28080D, and there is one or zero28076D TaxAmount 28074D for each Price entity 28054D. The NetUnitPrice28082D is of type GDT 28086D Price 28088D, and there is one or zero28084D NetUnitPrice 28082D for each Price entity 28054D. The Priceentity 28054D also includes a Component entity 28006E. There are anynumber 28008E of Component entities 28006E for each Price entity 28054D.

The Tax package 28024D includes a ProductTax entity 28014E, which is oftype GDT 28018E ProductTax 28020E. There are any number 28016E ofProductTax entities 28014E for each Item entity 28056C.

The Party package 28026D includes a BuyerParty entity 28022E, aSellerParty entity 28030E, a ProductRecipientParty entity 28038E, aVendorParty entity 28046E, a ManufacturerParty entity 28054E, and aCarrierParty entity 28062E. The BuyerParty entity 28022E is of type GDT28026E BusinessTransactionDocumentParty 28028E. There is one or zero28024E BuyerParty entity 28022E for each Item entity 28056C. TheSellerParty entity 28030E is of type GDT 28034EBusinessTransactionDocumentParty 28036E. There is one or zero 28032ESellerParty entity 28030E for each Item entity 28056C. TheProductRecipientParty entity 28038E is of type GDT 28042EBusinessTransactionDocumentParty 28044E. There is one or zero 28040EProductRecipientParty entity 28038E for each Item entity 28056C. TheVendorParty entity 28046E is of type GDT 28050EBusinessTransactionDocumentParty 28052E. There is one or zero 28048EVendorParty entity 28046E for each Item entity 28056C. TheManufacturerParty entity 28054E is of type GDT 28058EBusinessTransactionDocumentParty 28060E. There is one or zero 28056EManufacturerParty entity 28054E for each Item entity 28056C. TheCarrierParty entity 28062E is of type GDT 28066EBusinessTransactionDocumentParty 28068E. There is one or zero 28064ECarrierParty entity 28062E for each Item entity 28056C.

The Location package 28028D includes a ShipToLocation entity 28070E anda ShipFromLocation entity 28078E. The ShipToLocation entity 28070E is oftype GDT 28074E BusinessTransactionDocumentLocation 28076E, and there isone or zero 28072E ShipToLocation entity 28070E for each Item entity28056C. The ShipFromLocation entity 28078E is of type GDT 28082EBusinessTransactionDocumentLocation 28084E, and there is one or zero28080E ShipFromLocation entity 28078E for each Item entity 28056C.

The DeliveryInformation package 28030D includes a DeliveryTerms entity28086E, which is of type GDT 28090E DeliveryTerms 28092E. There is oneor zero 28088E DeliveryTerms entity 28086E for each Item entity 28056C.

The BusinessTransactionDocumentReference package 28032D includes aPurchaseOrderReference entity 28094E, a SalesOrderReference entity28002F, a DeliveryReference entity 28010F, aServiceAcknowledgementReference entity 28018F, an OriginInvoiceReferenceentity 28026F, a PurchaseContractReference entity 28034F, aSalesContractReference entity 28042F, a BuyerProductCatalogueReferenceentity 28050F, and a SellerProductCatalogueReference entity 28058F. ThePurchaseOrderReference entity 28094E is of type GDT 28098EBusinessTransactionDocumentReference 28000F. There are any number 28096Eof PurchaseOrderReference entities 28094E for each Item entity 28056C.The SalesOrderReference entity 28002F is of type GDT 28006FBusinessTransactionDocumentReference 28008F. There are any number 28004Fof SalesOrderReference entities 28002F for each Item entity 28056C. TheDeliveryReference entity 28010F is of type GDT 28014FBusinessTransactionDocumentReference 28016F. There is one or zero 28012FDeliveryReference entity 28010F for each Item entity 28056C. TheServiceAcknowledgementReference entity 28018F is of type GDT 28022FBusinessTransactionDocumentReference 28024F. There is one or zero 28020FServiceAcknowledgementReference entity 28018F for each Item entity28056C. The OriginInvoiceReference entity 28026F is of type GDT 28030FBusinessTransactionDocumentReference 28032F. There is one or zero 28028FOriginInvoiceReference entity 28026F for each Item entity 28056C. ThePurchaseContractReference entity 28034F is of type GDT 28038FBusinessTransactionDocumentReference 28040F. There is one or zero 28036FPurchaseContractReference entity 28034F for each Item entity 28056C. TheSalesContractReference entity 28042F is of type GDT 28046FBusinessTransactionDocumentReference 28048F. There is one or zero 28044FSalesContractReference entity 28042F for each Item entity 28056C. TheBuyerProductCatalogueReference entity 28050F is of type GDT 28054FCatalogueReference 28056F. There is one or zero 28052FBuyerProductCatalogueReference entity 28050F for each Item entity28056C. The SellerProductCatalogueReference entity 28058F is of type GDT28062F CatalogueReference 28064F. There is one or zero 28060FSellerProductCatalogueReference entity 28058F for each Item entity28056C.

The Attachment package 28034D includes an Attachment entity 28066F,which is of type GDT 28070F Attachment 28072F. There are any number28068F of Attachment entities 28066F for each Item entity 28056C.

The Description package 28038D includes a Description entity 28074F anda ConfirmedDescription entity 28082F. The Description entity 28074F isof type GDT 28078F Description 28080F. There is one or zero 28076FDescription entity 28074F for each Item entity 28056C. TheConfirmedDescription entity 28082F is of type GDT 28086F Description28088F. There is one or zero 28084F ConfirmedDescription entity 28082Ffor each Item entity 28056C.

An example of an Invoice Request message in XML is provided below: <?xmlversion=“1.0” encoding=“utf-8” ?> - <nr1:InvoiceRequestxmlns:nr1=“sap.com/xi/SAPGlobal/Global”> - <MessageHeader>  <IDschemeID=“0402”>00000004440000000020040723063339</ID> <CreationDateTime>2004-07-23T06:33:39Z</CreationDateTime> -<SenderParty>  <InternalID schemeID=“PartnerID”schemeAgencyID=“E5S_300”>6</InternalID>  </SenderParty> -<RecipientParty>  <InternalID schemeID=“PartnerID”schemeAgencyID=“E5S_300”>1000</InternalID>  </RecipientParty> </MessageHeader> - <Invoice>  <ID>NB1_LIM2</ID> <TypeCode>004</TypeCode>  <DateTime>2004-06-30T12:00:00Z</DateTime> <Note>Nachbelastung zu Rechnung 442</Note> - <BillToParty> <BillToID>6</BillToID>  </BillToParty> - <BillFromParty> <BillToID>1999</BillToID>  </BillFromParty> - <SellerParty> <BillToID>1000</BillToID>  </SellerParty> - <ProductRecipientParty> <BillToID>10754</BillToID>  </ProductRecipientParty> - <Price> <GrossAmount currencyCode=“EUR”>1.16</GrossAmount>  </Price> -<ProductTax>  <TypeCode>VAT</TypeCode>  <TypeDescriptionlanguageCode=“de”>16 %</TypeDescription>  <BaseAmountcurrencyCode=“EUR”>1.0</BaseAmount>  <Percent>16.0</Percent>  <AmountcurrencyCode=“EUR”>0.16</Amount> <BusinessTransactionDocumentItemGroupID>V1</BusinessTransactionDocumentItemGroupID>  </ProductTax> - <Item> <ID>1</ID>  <TypeCode>002</TypeCode> - <Product> <TypeCode>1</TypeCode>  <Note>a1</Note>  </Product> - <ProductCategory> <BillToID>LOC01</BillToID>  </ProductCategory>  <QuantityunitCode=“PCE”>1.0</Quantity> - <Price>  <NetAmountcurrencyCode=“EUR”>1.0</NetAmount> - <NetUnitPrice>  <AmountcurrencyCode=“EUR”>1.0</Amount>  <BaseQuantityunitCode=“PCE”>1.0</BaseQuantity>  </NetUnitPrice> - <ExchangeRate> <UnitCurrency>EUR</UnitCurrency>  <QuotedCurrency>USD</QuotedCurrency> <Rate>1.16</Rate>  </ExchangeRate>  </Price> - <ProductTax> <TypeCode>VAT</TypeCode>  <TypeDescription languageCode=“de”>16%</TypeDescription>  <BaseAmount currencyCode=“EUR”>0.0</BaseAmount> <Amount currencyCode=“EUR”>0.0</Amount> <BusinessTransactionDocumentItemGroupID>V1</BusinessTransactionDocumentItemGroupID>  </ProductTax> -<PurchaseOrderReference>  <ID>6500000123</ID>  <ItemID>1</ItemID> </PurchaseOrderReference>  </Item>  </Invoice>  </nr1:InvoiceRequest

6. Use of an Interface

The XI stores the interfaces (as an interface type). At runtime, thesending party's program instantiates the interface to create a businessdocument, and sends the business document in a message to the recipient.The messages are preferably defined using XML. In the example depictedin FIG. 281, the Buyer 28100 uses an application 28106 in its system toinstantiate an interface 28108 and create an interface object orbusiness document object 28110. The Buyer's application 28106 uses datathat is in the sender's component-specific structure and fills thebusiness document object 28110 with the data. The Buyer's application28106 then adds message identification 28112 to the business documentand places the business document into a message 28102. The Buyer'sapplication 28106 sends the message 28102 to the Vendor 28104. TheVendor 28104 uses an application 28114 in its system to receive themessage 28102 and store the business document into its own memory. TheVendor's application 28114 unpacks the message 28102 using thecorresponding interface 28116 stored in its XI to obtain the relevantdata from the interface object or business document object 28118.

From the component's perspective, the interface is represented by aninterface proxy 28200, as depicted in FIG. 282. The proxies 28200 shieldthe components 28202 of the sender and recipient from the technicaldetails of sending messages 28204 via XI. In particular, as depicted inFIG. 283, at the sending end, the Buyer 28300 uses an application 28310in its system to call an implemented method 28312, which generates theoutbound proxy 28306. The outbound proxy 28306 parses the internal datastructure of the components and converts them to the XML structure inaccordance with the business document object. The outbound proxy 28306packs the document into a message 28302. Transport, routing and mappingthe XML message to the recipient 28304 is done by the routing system(XI, Netweaver, etc.).

When the message arrives, the recipient's inbound proxy 28308 calls itscomponent-specific method 28314 for creating a document. The proxy 28308at the receiving end downloads the data and converts the XML structureinto the internal data structure of the recipient component 28304 forfurther processing.

As depicted in FIG. 284, a message 28400 includes a message header 28402and a business document 28404. The message 28400 also may include anattachment 28406. For example, the sender may attach technical drawings,detailed specifications or pictures of a product to a purchase order forthe product. The business document 28404 includes a business documentmessage header 28408 and the business document object 28410. Thebusiness document message header 28408 includes administrative data,such as the message ID and a message description. As discussed above,the structure 28412 of the business document object 28410 is derivedfrom the business object model 28414. Thus, there is a strongcorrelation between the structure of the business document object andthe structure of the business object model. The business document object28410 forms the core of the message 28400.

In collaborative processes as well as Q&A processes, messages shouldrefer to documents from previous messages. A simple business documentobject ID or object ID is insufficient to identify individual messagesuniquely because several versions of the same business document objectcan be sent during a transaction. A business document object ID with aversion number also is insufficient because the same version of abusiness document object can be sent several times. Thus, messagesrequire several identifiers during the course of a transaction.

As depicted in FIG. 285, the message header 28502 in message 28500includes a technical ID (“ID4”) 28506 that identifies the address for acomputer to route the message. The sender's system manages the technicalID 28506.

The administrative information in the business document message header28508 of the payload or business document 28504 includes aBusinessDocumentMessageID (“ID3”) 28512. The business entity orcomponent 28516 of the business entity manages and sets theBusinessDocumentMessageID 28512. The business entity or component 28516also can refer to other business documents using theBusinessDocumentMessageID 28512. The receiving component 28516 requiresno knowledge regarding the structure of this ID. TheBusinessDocumentMessageID 28512 is, as an ID, unique. Creation of amessage refers to a point in time. No versioning is expressed by the ID.Besides the BusinessDocumentMessageID 28512, there also is a businessdocument object ID 28514, which may include versions.

The component 28516 also adds its own component object ID 28518 when thebusiness document object is stored in the component. The componentobject ID 28518 identifies the business document object when it isstored within the component. However, not all communication partners maybe aware of the internal structure of the component object ID 28518.Some components also may include a versioning in their ID 28518.

The ReferencedMessageID refers to a previous message. For example, asdepicted in FIG. 286, a response 28602 to a message 28600 includes areferenced message ID 28604 referring to the original message. Moreover,documents from previous transactions may be referenced in a message. TheBusinessDocumentMessageID 28606 refers to such documents. For example,as depicted in FIG. 287, an order response or order change 28700includes an ID 28702 referring to the original Quote 28704 or an ID28706 referring to the original Vendor Contract 28708 within theBusiness Transaction Document ID.

7. Use of Interfaces Across Industries

Methods and systems consistent with the subject matter described hereinprovide interfaces that may be used across different business areas fordifferent industries. For example, FIG. 310 depicts the messagechoreography 31000 for an Order to Invoice scenario between a buyer31002 and seller 31004. The buyer 31002 creates a purchase order request31006, and sends a PurchaseOrderRequest 31008 to the seller 31004 todeliver goods or render services. The message type 31010 of thePurchaseOrderRequest 31008 is 0101, as defined above. In response, theseller 31004 confirms the purchase order request 31012, and sends aPurchaseOrderConfirmation 31014 to the buyer 31002. The message type31016 of the PurchaseOrderConfirmation 31014 is 0104.

The buyer 31002 may change the purchase order 31018 by sending aPurchaseOrderChangeRequest 31020 to the seller 31004. The message type31022 of the PurchaseOrderChangeRequest 31020 is 0102. In response, theseller 31004 may confirm the purchase order 31024 by sending aPurchaseOrderConfirmation 31026 to the buyer 31002. The message type31028 of the PurchaseOrderConfirmation 31026 is 0104.

The seller 31004 may change a purchase order 31030 by sending aPurchaseOrderConfirmation 31032 to the buyer 31002. The message type31034 of the PurchaseOrderConfirmation 31032 is 0104. In response, thebuyer updates the purchase order request 31036.

The buyer 31002 may cancel a purchase order 31038 by sending aPurchaseOrderCancellationRequest 31040 to the seller 31004. The messagetype 31042 of the PurchaseOrderCancellationRequest 31040 is 0103. Inresponse, the seller 31004 may confirm the purchase order cancellation31044 by sending a PurchaseOrderConfirmation 31046 to the buyer 31002.The message type 31048 of the PurchaseOrderConfirmation 31046 is 0104.

The seller 31004 may create a despatched delivery 31050 and send aDespatchedDeliveryNotification 31052 to the buyer 31002. The messagetype 31054 of the DespatchedDeliveryNotification 31052 is 0202. Inresponse the buyer 31002 receives the despatched delivery 31056.

The seller 31004 may create an invoice 31058 and send an InvoiceRequest31060 to the buyer 31002. The message type 31062 of the InvoiceRequest31060 is 0401. In response, the buyer 31002 receives the invoice 31064,and may send an InvoiceConfirmation 31066 to the seller 31004. Themessage type 31068 of the InvoiceConfirmation 31066 is 0401.

The buyer 31002 may create payment advice 31070 and send aPaymentAdviceNotification 31072 to the seller 31004, who receives thepayment advice 31076. The message type 31074 of thePaymentAdviceNotification 31072 is 0442. The buyer 31002, afterreceiving delivery 31078, may send a ReceiptDeliveryNotification 31080to the seller 31004 to confirm delivery 31084. The message type 31082 ofthe ReceiptDeliveryNotification 31080 is 0203.

The interfaces derived using methods and systems consistent with thesubject matter described herein also may be mapped for use under variousstandards. For example, FIG. 311 depicts the message choreography 31100for an Order to Invoice scenario provided by RosettaNet, i.e., the hightech industry standard. As shown, the buyer 31102 creates a purchaseorder (requisition) 31106, and sends a PurchaseOrderRequest 31108 to theseller 31104. The message type of the PurchaseOrderRequest 31108 is0101, which corresponds to RosettaNet's PIP3A4 message type 31110. Inresponse, the seller 31104 confirms the purchase order request 31112,and sends a PurchaseOrderConfirmation 31114 to the buyer 31102. Themessage type of the PurchaseOrderConfirmation 31114 is 0104, whichcorresponds to RosettaNet's PIP3A4 message type 31116.

The buyer 31102 may then change the purchase order 31118 by sending aPurchaseOrderChangeRequest 31120 to the seller 31104. The message typeof the PurchaseOrderChangeRequest 31120 is 0102, which corresponds toRosettaNet's PIP3A8 message type 31122. In response, the seller 31104may confirm the purchase order 31124 by sending aPurchaseOrderConfirmation 31126 to the buyer 31102. The message type ofthe PurchaseOrderConfirmation 31126 is 0104, which corresponds toRosettaNet's PIP3A8 message type 31128.

The seller 31104 may change a purchase order 31130 by sending aPurchaseOrderConfirmation 31132 to the buyer 31102. The message type ofthe PurchaseOrderConfirmation 31132 is 0104, which corresponds toRosettaNet's PIP3A7 message type 31134. In response, the buyer 31102updates the purchase order request 31136.

The buyer 31102 may cancel a purchase order 31138 by sending aPurchaseOrderCancellationRequest 31140 to the seller 31104. The messagetype of the PurchaseOrderCancellationRequest 31140 is 0103, whichcorresponds to RosettaNet's PIP3A9 message type 31142. In response, theseller 31104 may confirm the purchase order cancellation 31144 bysending a PurchaseOrderConfirmation 31146 to the buyer 31102. Themessage type of the PurchaseOrderConfirmation 31146 is 0104, whichcorresponds to RosettaNet's PIP3A9 message type 31148.

The seller 31104 may create an ASN 31150 and send aDespatchedDeliveryNotification 31152 to the buyer 31102. The messagetype of the DespatchedDeliveryNotification 31152 is 0202, whichcorresponds to RosettaNet's PIP3B2 message type 31154. In response, thebuyer 31102 receives the ASN 31156.

The seller 31104 may create an invoice 31158 and send an InvoiceRequest31160 to the buyer 31102. The message type of the InvoiceRequest 31160is 0401, which corresponds to RosettaNet's PIP3C3 message type 31162. Inresponse, the buyer 31102 receives the invoice 31164.

The buyer 31102 may create a remittance 31166 and send aPaymentAdviceNotification 31168 to the seller 31104, who receives thepayment advice 31172. The message type of the PaymentAdviceNotification31168 is 0442, which corresponds to RosettaNet's PIP3C6 message type31170.

FIG. 312 depicts the message choreography 31200 for an Order to Invoicescenario provided by CIDX, i.e., the chemical industry standard. Asshown, the buyer 31202 creates a purchase order (requisition) 31206, andsends a PurchaseOrderRequest 31208 to the seller 31204. The message typeof the PurchaseOrderRequest 31208 is 0101, which corresponds to CIDX'sOrderCreate message 31210. In response, the seller 31204 confirms thepurchase order 31212, and sends a PurchaseOrderConfirmation 31214 to thebuyer 31202. The message type of the PurchaseOrderConfirmation 31214 is0104, which corresponds to CIDX's OrderResponse message 31216.

The buyer 31202 may change the purchase order 31218 by sending aPurchaseOrderChangeRequest 31220 to the seller 31204. The message typeof the PurchaseOrderChangeRequest 31220 is 0102, which corresponds toCIDX's OrderChange message 31222. In response, the seller 31204 mayconfirm the purchase order 31224 by sending a PurchaseOrderConfirmation31226 to the buyer 31202. The message type of thePurchaseOrderConfirmation 31226 is 0104, which corresponds to CIDX'sOrderResponse message 31228.

The seller 31204 may change a purchase order 31230 by sending aPurchaseOrderConfirmation 31232 to the buyer 31202. The message type ofthe PurchaseOrderConfirmation 31232 is 0104, which corresponds to CIDX'sOrderResponse message 31234. In response, the buyer 31202 updates thepurchase order request 31236.

The seller may create an ASN 31238 and send aDespatchedDeliveryNotification 31240 to the buyer 31202. The messagetype of the DespatchedDeliveryNotification 31240 is 0202, whichcorresponds to CIDX's ShipNotice message 31242. In response the buyer31202 receives the ASN 31244.

The seller 31204 may create an invoice 31246 and send an InvoiceRequest31248 to the buyer 31202. The message type of the InvoiceRequest 31248is 0401, which corresponds to CIDX's Invoice message 31250. In response,the buyer 31202 receives the invoice 31252, and may send anInvoiceConfirmation 31254 to the seller 31204. The message type of theInvoiceConfirmation 31254 is 0203, which corresponds to CIDX'sInvoiceResponse message 31256.

After receiving delivery 31258, the buyer 31202 may send aReceiptDeliveryNotification 31260 to the seller 31204, who confirmsdelivery 31264. The message type of the ReceiptDeliveryNotification31260 is 0203, which corresponds to CIDX's ReceiptNotice message 31262.

A table identifying the relationship between the interfaces derivedusing methods and systems consistent with the subject matter describedherein and the interfaces provided by RosettaNet and CIDX is shownbelow. The number in the brackets identifies the number of fields withinthe interface. Interface RosettaNet CIDX MT101 PurchaseOrderRequestPIP3A4 PurchaseOrder OrderCreate (1030) Request (557) MT102 PIP3A8PurchaseOrder OrderChange (1000) PurchaseOrderChangeRequestChangeRequest (627) MT103 PIP3A9 PurchaseOrder OrderChange (all ItemsPurchaseOrderCancellationRequest CancellationRequest (31) deleted) MT104PIP3A4 PurchaseOrder OrderResponse (1020) PurchaseOrderConfirmationConfirmation (712) MT104 PIP3A8 PurchaseOrder PurchaseOrderConfirmationChangeConfirmation (743) MT104 PIP3A7 PurchaseOrderPurchaseOrderConfirmation UpdateNotification (745) MT104 PIP3A9PurchaseOrder PurchaseOrderConfirmation CancellationConfirmation (34)MT202 PIP3B2 AdvanceShipment ShipNotice (1000)DespatchedDeliveryNotification otification (253) MT203 ReceiptNotice(640) ReceivedDeliveryNotification (Delivery Receipt, Delivery ReceiptResponse) MT401 InvoiceRequest PIP3C3 InvoiceNotification Invoice (800)(391) MT402 InvoiceConfirmation InvoiceResponse (350) MT442 PIP3C6RemittanceAdvice PaymentAdviceNotification otification (117)

As illustrated above, the interfaces derived using methods and systemsconsistent with the subject matter described herein may be mapped ontothe interfaces of different industry standards. Unlike the interfacesprovided by any given standard that do not include the interfacesrequired by other standards, methods and systems consistent with thesubject matter described herein provide a set of consistent interfacesthat correspond to the interfaces provided by different industrystandards. Due to the different fields provided by each standard, theinterface from one standard does not easily map onto another standard.By comparison, to map onto the different industry standards, theinterfaces derived using methods and systems consistent with the subjectmatter described herein include most of the fields provided by theinterfaces of different industry standards. Any missing fields mayeasily be included into the business object model. Thus, by derivation,the interfaces can be extended consistently by these fields. Thus,methods and systems consistent with the subject matter described hereinprovide consistent interfaces that can be used across different industrystandards.

C. Exemplary Interfaces

a) Purchase Requirement Interfaces

Purchase requirement interfaces are used to exchange purchaserequisitions for products (materials, services) between a requester (inthe PTS scenario, an MRP controller, for example) and a buyer, andconfirmations that these requisitions have been fulfilled.

The motivating business scenario for the PurchaseRequirementRequest andPurchaseRequirementConfirmation interfaces is the Procure to Stock (PTS)scenario. In the PTS scenario, a planning system (SCP) or the“requester,” generates purchase requisitions that are procuredexternally by a procurement system (SRM) or the “buyer.”

(1) Message Types

Two messages types are available for mapping an A2A requisition process:(1) the message type PurchaseRequirementRequest is sent from therequester (a requirements planner in the PTS scenario or aplanning/requirements system, for example) to the buyer and is used tostart a new requirements process. From now on, this document will simplyuse the terms ‘requester’ and ‘buyer’; and (2) the message typePurchaseRequirementConfirmation is sent from the buyer to the requester.It informs the requester of the extent to which the requirement has beenfulfilled.

(a) Purchase Requirement Request

A PurchaseRequirementRequest is a request from a requester asking abuyer to procure products (materials or services) externally. Thestructure of the message type PurchaseRequirementRequest is specified bythe message data type PurchaseRequirementMessage. APurchaseRequirementRequest message results in the relevant requisitionbeing created or changed in the procurement system. The procurementsystem accepts changes made to a requisition (except for technicalerrors). If the procurement system (buyer) cannot procure a requisitionor partial quantity of a requisition (rejection), the procurement systemindicates this by outputting the PurchaseRequirementConfirmationmessage.

(b) Purchase Requirement Confirmation

A PurchaseRequirementConfirmation is a confirmation of the buyer thatinforms the requester of the extent to which a requisition has beenfulfilled. The structure of the message typePurchaseRequirementConfirmation is specified by the message data typePurchaseRequirementMessage. If a procurement system (buyer) cannotfulfil a requisition or partial quantity of a requisition, the buyerindicates this by outputting the PurchaseRequirementConfirmationmessage. The buyer cannot cancel a rejection of a requisition.

(2) Message Choreography

FIG. 288 depicts the message choreography for an exemplary purchaserequisition process. The purchase requisition process uses purchaserequirement interfaces to exchange purchase requisitions for products(such as materials and/or services) between a requester 28802 (such as,an MRP controller, for example in the PTS scenario) and a buyer 28804,and to exchange confirmations that these requisitions have beenfulfilled. The buyer 28804 may then interface with a supplier 28806 foractual purchase of the requested products.

The requester 28802 starts the requisition process by sending aPurchaseRequirementRequest message 28808 to the buyer 28804. ThePurchaseRequirementRequest message 28808 requests the buyer 28804 tofulfil a requisition generated by the requester 28802. The requisitionsystem uses the PurchaseRequirementRequest message 28808 whenrequisitions are created or changed. The buyer 28804 uses thePurchaseRequirementConfirmation message 28810 to tell the requester28802 the status of the requisition. For example, thePurchaseRequirementConfirmation message 28810 may indicate whichfollow-on documents for each item have been created and how much of therequired quantity has been procured. The PurchaseRequirementConfirmationmessage 28810 may also include information regarding whether arequisition or partial quantity of a requisition can no longer befulfilled.

The PurchaseRequirementConfirmation message 28810 may need to becommunicated in specified circumstances. If the requirements-generatingsystem manages the relevant follow-on documents itself or receives acopy of them and can carry out quantity offsetting in the requisition(as in the PTS scenario), the requirements-generating system requiresthe PurchaseRequirementConfirmation message 28810 if the requisition ora remaining quantity can no longer be procured. The procurement systemsends the PurchaseRequirementConfirmation message 28810 if a purchaserequisition item has been changed (once a purchase order with referenceto a requisition has been created or changed, for example). The currentprocurement status may be transferred in full with everyPurchaseRequirementRequest message 28808.

(3) Message Data Type Purchase Requirement Message

FIG. 289 shows a data model for the Purchase Requirement Request. Themessage data type PurchaseRequirementMessage includes aPurchaseRequirementMessage package 28900 that groups together thebusiness information relevant for sending a business document in amessage and the PurchaseRequirement object in the business document. Itincludes a MessageHeader package 28902, a PurchaseRequirement package28904, and a PurchaseRequirementMessage entity 28906.

The MessageHeader package 28902 groups together the business informationrelevant for sending a business document in a message. This package istypically not used and, therefore, typically remains empty.

The PurchaseRequirement package 28904 groups together a Party package28908, a Location package 28910, an Item package 28912, and aPurchaseRequirement entity 28914. There is a 1:1 relationship betweenthe PurchaseRequirementMessage entity 28906 and the PurchaseRequiremententity 28914.

A PurchaseRequirement entity 28914 is a requirement for procuringproducts (materials or services). The PurchaseRequirement entity 28914is subdivided into PurchaseRequirementItems entities 28964 that eachspecify an ordered product or additional information relevant for such aproduct, such as information about product category or value limits. Inaddition to the buying party and the seller as well as the proposedseller, additional parties can be involved in the PurchaseRequirement.Locations can be specified for the PurchaseRequirement delivery.PurchaseRequirement entity 28914 is of type GDT: PurchaseRequirement.

The PurchaseRequirement entity 28914 includes an ID, a CreationDateTime,and a Note. The ID is a unique identifier assigned by the requisitionsystem for the requisition. The ID is of type GDT:BusinessTransactionDocumentID. The CreationDateTime is the time at whichthe requisition was created in the requisition system. TheCreationDateTime is of type GDT: DateTime. The Note is a shortdescription/name for the requisition. The Note is of type GDT: Note.

(a) Purchase Requirement Party Package

Party package 28908 groups together the business parties involved in thePurchaseRequirement. It includes a BuyerParty entity 28916, aSellerParty entity 28918, a ProposedSellerParty entity 28920, aRequestorParty entity 28922, a ProductRecipientParty entity 28924, and aManufacturerParty entity 28926. There is a 1:c relationship 28928between the PurchaseRequirement entity 28914 and the BuyerParty entity28916. There is a 1:c relationship 28930 between the PurchaseRequiremententity 28914 and the SellerParty entity 28918. There is a 1:crelationship 28932 between the PurchaseRequirement entity 28914 and theProposedSellerParty entity 28920. There is a 1:c relationship 28934between the PurchaseRequirement entity 28914 and the RequestorPartyentity 28922. There is a 1:c relationship 28936 between thePurchaseRequirement entity 28914 and the ProductRecipientParty entity28924. There is a 1:c relationship 28938 between the PurchaseRequiremententity 28914 and the ManufacturerParty entity 28926.

Either the ID or the ID and address can be transferred for each party.If the ID is transferred, the ID address defined in the master data isused. If the ID and address are transferred, the ID identifies the partyand the address is deemed to be a document address that is different tothe master data address. Where possible, the ID and address should besent to avoid misunderstandings. The receiving application shouldimplement a suitable optimization strategy to prevent many identicaldocument addresses from being created.

A default logic is used for parties: from the header to the items andwithin item hierarchies. Parties specified in the header are valid forthe items for which a corresponding party is not explicitly transferredand that are directly assigned to the header. In accordance with thesame logic, parties transferred at item level are used for subitemsassigned to the relevant item in an item hierarchy. The default logicapplies for the party as a whole, including the contact person. Parts ofa party specified at header level or for a hierarchy item cannot bespecified in more detail at item level. The default logic is asimplified version of the transferred message. As regards logic, partiesat header level and for hierarchy items behave as if they have beenexplicitly transferred for the subitems of the message.

(i) Buyer Party

A BuyerParty entity 28916 is a party that buys goods or services. TheBuyerParty entity 28916 is of type GDT:BusinessTransactionDocumentParty, although it includes the StandardIDand InternalID elements, as well as the Address and ContactPersonentities. The ContactPerson includes the InternalID element and theAddress entity.

The BuyerParty is specified if more than one company processes itspurchases in the recipient system (hosting scenario). In the othercases, the BuyerParty is unique and does not need to be specified.Changes can be made to the BuyerParty/Contact and a differentBuyerParty/Contact can exist for each item. Changes can be made to theaddress of the BuyerParty, but different addresses are not permitted foreach item. If the ShipToLocation, ShipToParty, and RequestorParty havenot been explicitly specified in the requisition process, the address ofthe BuyerParty is used as the ship-to address.

(ii) Seller Party

A SellerParty entity 28918 is a party that sells goods or services. TheSellerParty entity 28918 is of type GDT:BusinessTransactionDocumentParty, although it includes the StandardIDand InternalID elements, as well as the Address and ContactPersonentities. The ContactPerson includes the InternalID element and theAddress entity. If the SellerParty and ShipFromLocation have not beenexplicitly specified in the requisition process, the address of theSellerParty is used as the ship-from address. If the SellerParty isspecified, it is used as the vendor when the requirement is generated inthe procurement system (unlike the preferred vendor). The SellerParty isnormally specified when the vendor was identified in the requirementssystem by a source of supply. In this case, the relevant source ofsupply is also specified in the correspondingBusinessTransactionDocumentReferencePackage entity.

(iii)Proposed Seller Party

A ProposedSellerParty entity 28920 is a preferred party for sellinggoods or services. The ProposedSellerParty entity 28920 is of type GDT:BusinessTransactionDocumentParty, although it includes the StandardIDand InternalID elements, as well as the Address and ContactPersonentities. The ContactPerson includes the InternalID element and theAddress entity. When a requisition is created, a user can specify apreferred vendor. In the procurement system, the professional buyer canuse the preferred vendor as the actual vendor.

(iv) Requestor Party

A RequestorParty entity 28922 is a party that requests the procurementof goods or services. The RequestorParty entity 28922 is of type GDT:BusinessTransactionDocumentParty, although it includes the StandardIDand InternalID elements, as well as the Address and ContactPersonentities. The ContactPerson includes the InternalID element and theAddress entity. If a ShipToLocation and ProductRecipientParty are notexplicitly specified in the requisition process, the RequestorPartyaddress is used as the ship-to address. In the purchasing process, theRequestorParty (requestor) carries out different follow-up actions. Forthis reason, it is specified explicitly (and not just as the Contact).In a SelfService process, the RequestorParty could enter and approve agoods receipt and invoice, for example.

(v) Product Recipient Party

A ProductRecipientParty entity 28924 is a party to which goods aredelivered or for whom services are provided. The ProductRecipientPartyentity 28924 is of type GDT: BusinessTransactionDocumentParty, althoughit includes the StandardID and InternalID elements, as well as theAddress and ContactPerson entities. The ContactPerson includes theInternalID element and the Address entity. If a ShipToLocation is notspecified explicitly in a requisition process, the address of theProductRecipientParty is used as the delivery address. If theProductRecipientParty (goods recipient) is not specified at item orheader level, the RequestorParty is also used as theProductRecipientParty. For a direct material item, theProductRecipientParty is optional. The ShipToLocation, however, ismandatory. In the third-party process (seeBusinessTransactionDocumentItemThirdPartyDealIndicator), theProductRecipientParty is the customer. The ProductRecipientParty is notsynonymous with the ShipToLocation and is to be used when theProductRecipientParty (company or person) is actually different from theBuyerParty.

(vi) Manufacturer Party

A ManufacturerParty entity 28926 is a party that manufactures goods. TheManufacturerParty entity 28926 is of type GDT:BusinessTransactionDocumentParty, although it includes the StandardIDand InternalID elements, as well as the Address and ContactPersonentities. The ContactPerson includes the InternalID element and theAddress entity. The ManufacturerParty can be used for Material itemswith regard to the ManufacturerParty, the default logic (from header toitem to subitems) is used for material items; for other items, theManufacturerParty is ignored. The ManufacturerParty can be used touniquely define the context of a ManufacturerProductID.

(b) Purchase Requirement Location Package

The Location package 28910 groups together the locations that arerelevant for the requisition. The LocationPackage 28910 includes aShipToLocation entity 28940 and a ShipFromLocation entity 28942. Thereis a 1:c relationship 28944 between the PurchaseRequirement entity 28914and the ShipToLocation entity 28940. There is a 1:c relationship 28946between the PurchaseRequirement entity 28914 and the ShipFromLocationentity 28942.

A similar default logic to that used for Parties is also used forlocations. Either the ID or the address, or both can be transferred foreach location. If the ID is transferred, the ID address defined in themaster data is used (if necessary, a new master record is created forthe message recipient). If the address is transferred, it is thisaddress that is used (if necessary, a location is assigned at theaddress recipient). If the ID and address are transferred, the IDidentifies the location and the address is deemed to be a documentaddress that is different to the master data address. Where possible,the ID and address should be sent to avoid misunderstandings. Thereceiving application should implement a suitable optimization strategyto prevent many identical document addresses from being created.

(i) Ship To Location

A ShipToLocation entity 28940 is the location to which goods are to bedelivered or where services are to be provided. The ShipToLocationentity 28940 is of type GDT: BusinessTransactionDocumentLocation,although it includes the StandardID and InternalID elements, as well asthe Address entity. In a direct material item, the ShipToLocation ID isspecified.

(ii) Ship From Location

A ShipFromLocation entity 28942 is the location from where goods are tobe shipped. The ShipFromLocation entity 28942 is of type GDT:BusinessTransactionDocumentLocation, although it includes the StandardIDand InternalID elements, as well as the Address entity. TheShipFromLocation can be used for material items the default logic fromheader to item to subitems is used for the ShipFromLocation for materialitems; for the other items, the ShipFromLocation is ignored.

(c) Purchase Requirement Package

A PurchaseRequirementItem package 28912 includes a ProductInformationpackage 28948, a PriceInformation package 28950, a Party package 25952,a Location package 28954, a BusinessTransactionDocumentReference package28956, an Attachment package 28958, a Description package 28960, aScheduleLine package 28962, and a PurchaseRequirementItem (or Item)entity 28964. There is a 1:n relationship 28966 between thePurchaseRequirement entity 28914 and the Item entity 28964.PurchaseRequirementItem entities 28964 are arranged hierarchically usinga HierarchyRelationship 28968. The HierarchyRelationship 28968 is therelationship between a sub-item and a higher-level parent item in anitem hierarchy. There is a 1:cn relationship 28970 between the Itementity 28964 and its subordinate entities. There is a 1:c relationship28972 between the Item entity 28964 and its superordinate entities.

(i) Purchase Requirement Item

A PurchaseRequirementItem entity 28964 specifies a product requested bythe PurchaseRequirement or provides additional information about such aproduct. The PurchaseRequirementItem entity 28964 includes detailedinformation about a particular product (see ProductInformation package28948) and its price (see PriceInformation package 28950). The quantityof the product and (delivery) dates/times are specified in the scheduleline (see ScheduleLine package). For the PurchaseRequirementItem entity28964 (compared to the information of the PurchaseRequirement entity28914), deviating parties or locations can be defined (see Party package28952 and Location package 28954). The PurchaseRequirementItem entity28964 can contain references to other business documents that arerelevant for the item (see BusinessTransactionDocumentReference package28956). Notes or references to attachments can also be specified for theitem (see Description package 28960 and Attachment package 28958). APurchaseRequirementItem entity 28964 can be subordinate to anotherPurchaseRequirementItem entity 28964 within a hierarchy to represent abusiness relationship between the two items. This could be informationabout a substitute product for an ordered product, for example. Thisrelationship can also be used to group together PurchaseRequirementitems, that is, a PurchaseRequirementItem can group together otherPurchaseRequirementItems. The PurchaseRequirementItem entity 28964 is oftype GDT: PurchaseRequirementItem.

The PurchaseRequirementItem entity 28964 includes an ID, aThirdPartyDealIndicator, and a DirectMaterialIndicator. The ID is therequisition item number; a unique identifier assigned by the requesterfor the purchase requisition item. The ID is of type GDT:BusinessTransactionDocumentItemID. The ThirdPartyDealIndicator specifiesthat the purchase requisition item is used as part of a third-partyprocess. The ThirdPartyDealIndicator is of type GDT:BusinessTransactionDocumentItemThirdPartyDealIndicator. TheDirectMaterialIndicator specifies whether the material in the purchaserequisition item is used as part of a direct material process. TheDirectMaterialIndicator is of type GDT: DirectMaterialIndicator.

From a semantic point of view, items can contain other items. Itemhierarchies are mapped in this way. From a technical point of view, theitem type is not defined recursively, since this cannot be handled bysome commonly-used XML tools. The hierarchies are mapped using theentity HierarchyRelationship. There are various item categories, whichare governed by a variety of constraints. An item can have severalconstraint types. In this case, the item satisfies the constraints ofits constraint types. Which constraint types can be combined with oneanother and how, is specified in the description of the constrainttypes. The following constraint types exist:

(1) Standard items are the items to which no lower-level items have beenassigned in the hierarchy. An item that is not referenced by theParentItemID of another item is a standard item.

(2) Hierarchy items are items to which at least one other lower-levelitem has been assigned in the hierarchy. An item that is referenced bythe ParentItemID of at least one other item is a hierarchy item. Itemsare either standard or hierarchy items.

(3) Subitems are items that are assigned below a hierarchy item and notdirectly assigned to the requisition header. Subitems can be bothstandard items and hierarchy items. Each item that references anotheritem by the ParentItemID is a subitem.

(4) Material items are items whose product is a material. Items whoseProductTypeCode is “1” (Material) are Material items.

(5) DirectMaterial items are material items that are used as part of adirect material process (see DirectMaterialIndicator).

(6) Service items are items whose product is a service. Items whoseProductTypeCode is “2” (service) are service items.

(7) Limit items are items with a cost limit. Limit items are used asplaceholders in a requisition if the exact requirements are unknown atthe time the requisition is issued. This can be the case for repairs,where the time and spare parts required are not known until the repairhas been made.

(8) Grouping hierarchy items are hierarchy items that logically grouptogether other items. Multilevel grouping hierarchies are permitted,that is, a grouping hierarchy item can contain subitems that are alsogrouping hierarchy items. Hierarchy items whose subitems haveHierarchyRelationshipTypeCode “002” (group) are grouping hierarchyitems; subitems with a different HierarchyRelationshipTypeCode are notpermitted. Grouping hierarchy items are not permitted as subitems ofother types of hierarchy items.

(9) BOM hierarchy items are hierarchy items that group together otheritems in a BOM. Multilevel BOM hierarchies are permitted. Hierarchyitems with at least one subitem with HierarchyRelationshipTypeCode “001”(bill of material) are BOM hierarchy items; additional subitems arepermitted with the HierarchyRelationshipTypeCode “003” (discount inkind).

(10) Discount in kind hierarchy items are hierarchy items for which agoods discount is granted in the form of an inclusive or exclusive bonusquantity. Multilevel discount in kind hierarchies are not permitted,that is, no discount in kind can be granted for discount in kind. Thegoods discount is described in the form of one or more subitems in thediscount in kind hierarchy item. Hierarchy items with at least onesubitem with HierarchyRelationshipTypeCode “003” (discount in kind) arediscount in kind hierarchy items; additional subitems are permitted withthe HierarchyRelationshipTypeCode “001” (bill of material). Hierarchyitems are grouping, BOM, or discount in kind hierarchy items. Ahierarchy item can be both BOM and a discount in kind hierarchy item, ifa discount in kind has been granted for a BOM.

(ii) Hierarchy Relationship

A HierarchyRelationship is the relationship between a subitem and ahigher-level parent item in an item hierarchy. The HierarchyRelationshipincludes a ParentItemID and a TypeCode. The ParentItemID is a referenceto a parent item. The ParentItemID is of type GDT:BusinessTransactionDocumentItemID. The TypeCode represents thehierarchical relationship between the subitem and its higher-levelparent item. The TypeCode is of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode.

The ParentItemID is not changed once an item has been created. TheTypeCode is not changed once an item has been created.

(iii)Purchase Requirement Item Product Information Package

A ProductInformation package 28948 groups together the information foridentifying, describing, and classifying a product in a purchaserequisition item. It includes a Product entity 28974 and aProductCategory entity 28976. There is a 1:c relationship 28978 betweenthe Item entity 28964 and the Product entity 28974. There is a 1:crelationship 28980 between the Item entity 28964 and the ProductCategoryentity 28976. The ProductInformation package 28948 is not used ingrouping hierarchy items.

(a) Product

A Product entity 28974 includes the details about a product as generallyunderstood from a commercial point of view in business documents. Theseare the details for identifying a product and product type, and thedescription of the product. The Product entity 28974 is of type GDT:BusinessTransactionDocumentProduct, although it includes the StandardID,InternalID, TypeCode, and Note elements.

For limit items, the description (note) can be used in the Productentity 28974; the product number and ProductTypeCode are not used.Except in limit items, either a product number or a description alongwith the ProductTypeCode (material or service) is always specified. TheProductTypeCode is not changed once an item has been created. With theexception of grouping hierarchy items, at least the product number orthe product description (Note) is specified when a new item is created.If both the product number and description are specified, thedescription is merely additional information in the message and can beignored by the recipient. In substitution product subitems, theProductTypeCode does not differ from the parent item ProductTypeCode.

(b) Product Category

A ProductCategory entity 28976 includes the details about a productcategory as generally understood from a commercial point of view inbusiness transaction documents. It includes details for identifying theproduct category using an internal ID, a standard ID, and IDs assignedby involved parties. The ProductCategory entity 28976 is of type GDT:BusinessTransactionDocumentProductCategory, although it includes theStandardID and InternalID elements. The product category is deriveddirectly from the product if a product number is specified for theproduct.

(iv) Purchase Requirement Item Price Information Package

A PriceInformation package 28950 groups together price-relevantinformation. It includes a Price entity 28982 and aProcurementCostUpperLimit entity 28984. There is a 1:c relationship28986 between the Item entity 28964 and the Price entity 28982. There isa 1:c relationship 28988 between the Item entity 28964 and theProcurementCostUpperLimit entity 28984. The Price package for a purchaserequisition item includes prices; it does not contain any informationabout how the prices are calculated (pricing scales, and so on).

(a) Price

A Price entity 28982 is the purchase order price specified by therequester or buyer. The Price entity 28982 includes a NetUnitPrice,which is the net price (without tax or cash discount) specified by thebuyer for the base quantity of the service or material. The NetUnitPriceis of type GDT: Price.

In BOM hierarchies, the following rules apply for the Price entity28982: (1) if the price is specified for the item at the top of the BOMhierarchy and not the subitems, this price applies; (2) if the price isspecified for standard items (end nodes in the hierarchy tree) in theBOM hierarchy, these prices apply. The price of the entire BOM is thetotal of the individual prices; and (3) if a price is specified atdifferent levels in the BOM hierarchy, the price that appears above theothers in the tree always applies. Differences between the total of theindividual prices and the price at the next highest hierarchy level arepermissible. These may be caused by discounts for the entire BOM.

(b) Procurement Cost Upper Limit

A ProcurementCostUpperLimit entity 28984 is the cost upper limit fordifferent types of procurement costs. The ProcurementCostUpperLimitentity 28984 is of type GDT: ProcurementCostUpperLimit. If a limit isspecified, this implies that the purchase requisition item is a limititem; in other words, the requisition item indicates a requirement for acertain quantity of a particular product or service within a certainperiod. Limit items are used as placeholders in a requisition if theexact requirements are unknown at the time the requisition is issued.This can be the case for repairs, where the time and spare partsrequired are not known until the repair has been made.

(v) Purchase Requirement Item Party Package

The ItemParty package 28952 is similar to the Party package 28908 in thePurchaseRequirement package 28904. The ItemParty package 28952 alsoincludes a BuyerParty entity 28990, a SellerParty entity 28992, aProposedSellerParty entity 28994, a RequestorParty entity 28996, aProductRecipientParty entity 28998, and a ManufacturerParty entity28900A. There is a 1:c relationship 28902A between the Item entity 28964and the BuyerParty entity 28990. There is a 1:c relationship 28904Abetween the Item entity 28964 and the SellerParty entity 28992. There isa 1:c relationship 28906A between the Item entity 28964 and theProposedSellerParty entity 28994. There is a 1:c relationship 28908Abetween the Item entity 28964 and the RequestorParty entity 28996. Thereis a 1:c relationship 28910A between the Item entity 28964 nd theProductRecipientParty entity 28998. There is a 1:c relationship 28912Abetween the Item entity 28964 and the ManufacturerParty entity 28900A.

(vi) Purchase Requirement Item Location Package

The ItemLocation package 28954 is similar to the Location package 28910in the PurchaseRequirement package 28904. The ItemLocation package 28954also includes a ShipToLocation entity 28914A and a ShipFromLocationentity 28916A. There is a 1:c relationship 28918A between the Itementity 28964 and the ShipToLocation entity 28914A. There is a 1:crelationship 28920A between the Item entity 28964 and theShipFromLocation entity 28916A.

(vii) Purchase Requirement Item Business Transaction Document ReferencePackage

A BusinessTransactionDocumentReference package 28956 groups togetherreferences to business documents that are relevant for thePurchaseRequirementItem and have a business relationship with the item.It includes a PurchaseContractReference entity 28922A and anOriginPurchaseOrderReference entity 28924A. None of the entities in theBusinessTransactionDocumentReference package 28956 can be used ingrouping hierarchy items.

If possible, individual items in business documents should be referencedin the requisition message from item level (contract item 10 is directlyreferenced from purchase requisition item 1, for example). If an itemassignment is not recognized, an entire document can be referenced(contract 4711 is referenced in its entirety from purchase requisitionitem 1, for example). In this case, the recipient cannot demand that theitem numbers in both documents be the same (that item 1 in requisition4712 be the same as item 1 in contract 4711, for example). It is theresponsibility of the recipient to try this assignment using othercriteria that are not necessarily unique, such as the product number.

(a) Purchase Contract Reference

A PurchaseContractReference entity 28922A is a reference to a purchasecontract or item in a purchase contract. The PurchaseContractReferenceentity 28922A is of type GDT: BusinessTransactionDocumentReference.

Contract references are not permitted in limit items; these are includedin the ProcurementCostUpperLimit entity. A PurchaseContractReferenceentity 28922A can reference one item, that is, one ItemID ispermissible.

(b) Origin Purchase Order Reference

The OriginPurchaseOrderReference entity 28924A is a reference to theorigin purchase order or to an item within the origin purchase order ina third-party process. The OriginPurchaseOrderReference entity 28924A isof type GDT: BusinessTransactionDocumentReference.

The OriginPurchaseOrderReference entity 28924A can reference one item,that is, one ItemID is permissible. The OriginPurchaseOrderReferenceentity 28924A is used for third-party purchase orders.

The OriginPurchaseOrderReference entity 28924A is passed on to thepurchase orders in a third-party deal, so that the seller can referencethe original purchase order of the ShipToParty with theOriginPurchaseOrderReference.

(viii) Purchase Requirement Item Attachment Package

The Attachment package 28958 groups together the relevant attachmentswith reference to the purchase requisition item. It includes anAttachmentWebAddress entity 28930A. There is a 1:cn relationship 28932Abetween the Item entity 28964 and the AttachmentWebAddress entity28930A.

The AttachmentWebAddress entity 28930A is a Web address for a documentof any type that is related to the transmitted message or a part of themessage, but is not itself transferred as part of the message. TheAttachmentWebAddress entity 28930A is of type GDT: AttachmentWebAddress.

(ix) Purchase Requirement Item Description Package

A Description package 28960 groups together the texts relating to thepurchase requisition item. It includes a Description entity 28934A andan InternalDescription entity 28936A.

The Description entity 28934A is a natural-language text regarding thepurchase requisition item, which is visible to the parties. TheDescription entity 28934A is of type GDT: Description. The Descriptionentity 28934A can be used for the textual information about thetransferred requisition and not just the current message. An example ofthis would be information that the Purchasing employee responsible is onvacation as of a specific date, and indicating the name and telephonenumber of a substitute as of this date.

An InternalDescription entity 28936A is a natural-language textregarding the purchase requisition item, which is visible to the partieswithin the company. The InternalDescription entity 28936A is of typeGDT: Description. The InternalDescription entity 28936A can be used forthe textual information about the transferred requisition and not justthe current message. An example of this is a note indicating that therequisition is required for a particular internal purpose. Unlike theDescription, the InternalDescription is not included in a message thatwould be sent to the vendor.

(x) Purchase Requirement Item Schedule Line Package

A ScheduleLine package 28962 groups the quantity and date informationabout a PurchaseRequirementItem entity 28964. The ScheduleLine package28962 includes a ScheduleLine entity 28942A. There is a 1:1 relationship28944A between the Item entity 28964 and the ScheduleLine entity 28942A.

A ScheduleLine entity 28942A is a line containing the quantity and datesof the performance period requested in a requisition. The ScheduleLineentity 28942A includes a DeliveryPeriod 28946A and a Quantity 28950A.The DeliveryPeriod is the period in which the requester expects aproduct to be delivered or service provided. The DeliveryPeriod is oftype GDT: DateTimePeriod. The Quantity is the required quantity. TheQuantity is of type GDT: Quantity. The quantity is specified, unless theitem in question is a limit item, in which case it can be left empty.Exactly one ScheduleLine is provided in the PurchaseRequirementItem.

(4) Message Data Type Element Structure

FIG. 290 depicts the element structure for PurchaseRequirementRequest.The element structure identifies the different packages 29000 in theinterface, and represents the entities at various levels within theinterface. As shown in FIG. 290, the interface forPurchaseRequirementRequest includes five levels 29002, 29004, 29006,29008, 29010. The element structure identifies the number of occurrences29012 of each element and provides a Datatype name 29014 for eachelement.

The outermost package of this interface is PurchaseRequirementMessagepackage 29016, which includes a PurchaseRequirementMessage entity 29018at the first level 29002. The PurchaseRequirementMessage entity 29018 isof data type MDT: PurchaseRequirementMessage 29020.

The PurchaseRequirementMessage package 29016 includes aPurchaseRequirement package 29022, which includes a PurchaseRequiremententity 29024. The PurchaseRequirement entity 29024 has one occurrence29026 and is of data type PurchaseRequirement 29028.

The PurchaseRequirement entity 29024 includes an ID 29030, aCreationDateTime 29036 and a Note 29042. The ID 29030 has one occurrence29032 and is of data type BusinessTransactionDocumentID 29034. TheCreationDateTime 29036 has one occurrence 29038 and is of data typeDateTime 29040. The Note 29042 has one or zero occurrences 29044 and isof data type Note 29046.

The PurchaseRequirement entity 29024 also includes a Party package29048, a Location package 29050, and an Item package 29052. The Partypackage 29048 includes a BuyerParty entity 29054, a SellerParty entity29096, a ProposedSellerParty entity 29002A, a RequestorParty entity29008A, a ShipToParty entity 29014A, and a ManufacturerParty entity29020A.

The BuyerParty entity 29054 has one or zero occurrences 29056 and is ofdata type BusinessTransactionDocumentParty 29058. The BuyerParty entity29054 also includes a StandardID 29060, an InternalID 29066, an Address29072, and a ContactPerson 29078.

The StandardID 29060 of the BuyerParty entity 29054 has zero or noccurrences 29062 and having a data type of PartyStandardID 29064. TheInternalID 29066 has zero or one occurrences 29068 and a data type ofPartyStandardID 29070. The Address 29072 has zero or one occurrences29074 and a data type of Address 29076. The ContactPerson 29078 alsoincludes an InternalID 29084 and an Address 29090. The InternalID 29084of the ContactPerson 29078 has zero or n occurrences 29086 and a datatype of ContactPersonID 29088. The Address 29090 of the ContactPerson29078 has one or zero occurrences 29092 and a data type of Address29094.

The SellerParty 29096 of the PurchaseRequirement entity 29024 has one orzero occurrences 29098 and a data type ofBusinessTransactionDocumentParty 29000A. The ProposedSellerParty 29002Ahas one or zero occurrences 29004A and a data type ofBusinessTransactionDocumentParty 29006A. The RequestorParty 29008A hasone or zero occurrences 29010A and a data type ofBusinessTransactionDocumentParty 29012A. The ShipToParty 29014A has oneor zero occurrences 29016A and a data type ofBusinessTransactionDocumentParty 29018A. The ManufacturerParty 29020Ahas one or zero occurrences 29022A and a data type ofBusinessTransactionDocumentParty 29024A.

The Location package 29050 includes a ShipToLocation entity 29026A and aShipFromLocation entity 29050A. The ShipToLocation entity 29026A haszero or one occurrences 29028A with a data type ofBusinessTransactionDocumentLocation 29030A. The ShipToLocation entity29026A also includes a StandardID 29032A, an InternalID 29038A and anAddress 29044A. The StandardID 29032A has zero or one occurrences 29034Awith a data type of LocationStandardID 29036A. The InternalID 29038A haszero or one occurrences 29040A with a data type of LocationStandardID29042A. The Address 29044A has zero or one occurrences 29046A with adata type of Address 29048A. The ShipFromLocation entity 29050A has zeroor one occurrences 29052A with a data type ofBusinessTransactionDocumentLocation 29054A.

The Item package 29052 of the PurchaseRequirement entity 29024 includesa Product package 29096A, a Price package 29098A, a Party package29000B, a Location package 29002B, aBusinessTransactionDocumentReference package 29004B, an Attachmentpackage 29006B, a Description package 29008B, and a ScheduleLine package29010B. The Item entity 29056A has a one or n occurrences 29058A with adata type of PurchaseRequirementItem 29060A.

The Item package 29052 also includes an Item entity 29056A, whichincludes an ID 29062A, a ThirdPartyDealIndicator 29068A, aDirectMaterialIndicator 29074A, and a HierarchyRelationship 29080A. TheID 29062A has one occurrence 29064A with a data type ofBusinessTransactionDocumentItemID 29066A. The ThirdPartyDealIndicator29068A has one or zero occurrences 29070A with a data type ofBusinessTransactionDocumentItemThirdPartyDealIndicator 29072A. TheDirectMaterialIndicator 29074A has a zero or one occurrence 29076A witha data type of DirectMaterialIndicator 29078A. The HierarchyRelationship29080A includes a ParentItemID 29084A and a TypeCode 29090A. TheHierarchyRelationship 29080A has a zero or one occurrence 29082A. TheParentItemID 29084A has one occurrence 29086A with a data type ofBusinessTransactionDocumentItemID 29088A. The TypeCode 29090A has oneoccurrence 29092A with a data type ofBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 29094A.

The Product Package 29096A includes a Product entity 29012B and aProductCategory entity 29042B. The Product entity 29012B has one or zerooccurrences 29014B with a data type ofBusinessTransactionDocumentProduct 29016B. The Product entity 29012Balso includes a StandardID 29018B, an InternalID 29024B, a TypeCode29030B, and a Note 29036B. The StandardID 29018B has one or noccurrences 29020B with a data type of ProductStandardID 29022B. TheInternalID 29024B has zero or one occurrences 29026B with a data type ofProductInternalID 29028B. The TypeCode 29030B has zero or oneoccurrences 29032B with a data type of ProductTypeCode 29034B. The Note29036B has zero or one occurrences 29038B with a data type of Note29040B.

The ProductCategory entity 29042B has zero or one occurrences 29044Bwith a data type of BusinessTransactionDocumentProductCategory 29046B.The ProductCategory entity 29042B also has a StandardID 29048B and anInternalID 29054B. The StandardID 29048B has zero or n occurrences29050B with a data type of ProductCategoryStandardID 29052B. TheInternalID 29054B has zero or n occurrences 29056B with a data type ofProductCategoryInternalID 29058B.

The Product package 29096A also includes a Price package 29098A, a Partypackage 29000B, a Location package 29002B, aBusinessTransactionDocumentReference package 29004B, an Attachmentpackage 29006B, a Description package 29008B and a ScheduleLine package29010B.

The Price package 29098A has one or zero occurrences 29062B and includesa NetUnitPrice 29064B. The NetUnitPrice 29064B has one or zerooccurrences 29066B with a data type of Price 29068B. The Price package29098A also includes a ProcurementCostUpperLimit entity 29070B havingzero or one occurrences 29072B and a data type of ProcurementUpperLimit29074B.

The Party package 29000B includes a BuyerParty 29076B, a SellerParty29082B, a ProposedSellerParty 29088B, a RequestorParty 29094B, aShipToParty 29000C and a Manufacturer 29006C. The BuyerParty 29076B hasa one or zero occurrences 29078B with a data type ofBusinessTransactionDocumentParty 29080B. The SellerParty 29082B has zeroor one occurrences 29084B with a data type ofBusinessTransactionDocument Party 29086B. The ProposedSellerParty 29088Bhas zero or one occurrences 29090B with a data type ofBusinessTransactionDocumentParty 29092B. The RequestorParty 29094B hasone or zero occurrences 29096B with a data type ofBusinessTransactionDocumentParty 29098B. The ShipToParty 29000C has azero or one occurrences 29002C with a data type ofBusinessTransactionDocumentParty 29004C. The Manufacturer 29006C haszero or one occurrences 29008C with a data type ofBusinessTransactionDocumentParty 29010C.

The Location package 29002B includes a ShipFromLocation entity 29012Cand a ShipToLocation entity 29018C. The ShipFromLocation entity 29012Chas one or zero occurrences 29014C with a data type ofBusinessTransactionDocumentLocation 29016C. The ShipToLocation 29018Chas one or zero occurrences 29020C with a data type ofBusinessTransactionDocumentLocation 29022C.

The BusinessTransactionDocumentReference package 29004B includes aPurchaseContractReference entity 29024C and anOriginPurchaseOrderReference entity 29030C. ThePurchaseContractReference entity 29024C has zero or one occurrence29026C with a data type of BusinessTransactionDocumentReference 29028C.The OriginPurchaseOrderReference entity 29030C has one or zerooccurrences 29032C with a data type ofBusinessTransactionDocumentReference 29034C.

The Attachment package 29006B has an AttachmentWebAddress entity 29036Chaving one or zero occurrences 29038C with a data type ofAttachmentWebAddress 29040C.

The Description package 29008B has a Description entity 29042C and anInternalDescription entity 29048C. The Description entity 29042C haszero or one occurrences 29044C with a data type of Description 29046C.The InternalDescription entity 29048C has zero or one occurrences 29050Cwith a data type of Description 29052C.

The ScheduleLine package 29010B includes a ScheduleLine entity 29054Chaving a DeliveryPeriod 29058C and a Quantity 29064C. The ScheduleLineentity 29054C has one occurrence 29056C. The DeliveryPeriod 29058C hasone occurrence 29060C with a data type of DateTimePeriod 29062C. TheQuantity 29064C has zero or one occurrences 29066C with a data type ofQuantity 29068C.

b) Source of Supply Notification Interface

A SourceOfSupplyNotification is a message sent to supply planning(Supply Chain Planning) about the available sources of supply. Themotivating business scenario for the source of supply notification isthe Procure to Stock (PTS) scenario. Once a purchase contract has beenreleased in Supplier Relationship Management (SRM), a message withsources of supply resulting from the purchase contract data is sent toSupply Chain Planning (SCP) so that it can be taken into account duringsourcing.

A SourceOfSupplyNotification is a message sent to SCP about theavailable sources of supply. The message type SourceOfSupplyNotificationis based on the message data type SourceOfSupplyMessage. Informationabout sources of supply and changes to sources of supply is sent in itsentirety (CompleteTransmission).

(1) Message Choreography

FIG. 291 depicts a graphical representation 29100 of a Source Of SupplyNotification 29102 between two business entities in accordance withmethods and systems consistent with the subject matter described herein.In the implementation shown in FIG. 291, the first business entity is asupply source manager (or Supplier Relationship Management 29104) andthe second business entity is a supply planner (or Supply Chain Planning29106). The Source Of Supply Notification 29102 is a message sent fromthe Supplier Relationship Management 29104 to Supply Chain Planning29106 about the available sources of supply. The Source of SupplyNotification 29102 may identify a Procure to Stock (PTS) scenario to theSupply Chain Planning 29106. For example, once a purchase contract (notshown in FIG. 291) has been released in or to Supplier RelationshipManagement 29104, a message 29102 with sources of supply resulting fromthe purchase contract data is sent to Supply Chain Planning 29106 sothat Supply Chain Planning 29106 is able to take into account thesources of supply during the stocking or sourcing process. In thisimplementation, the Source Of Supply Notification 29102 is sent once apurchase contract has been released.

The Source Of Supply Notification 29102 is a message type based on themessage data type SourceOfSupplyMessage 29200 shown in FIG. 292. Amessage based on the message data type SourceOfSupplyMessage 29200 isimplemented by two message operations: a SourceOfSupplyNotification-Outoperation and a SourceOfSupplyNotification_In operation. TheSourceOfSupplyNotification_Out operation is in Supplier RelationshipManagement 29104, and the SourceOfSupplyNotification_In operation is inSupply Chain Planning 29106.

(2) Message Data Type Source of Supply Message

The message data type SourceOfSupplyMessage 29200 includes theSourceOfSupply Message entity 29202 in the business document or thebusiness information that is relevant for sending a business document ina message. As shown in FIG. 292, the message data typeSourceOfSupplyMessage 29200 includes a MessageHeader package 29204 and aSourceOfSupply package 29206. The message data typeSourceOfSupplyMessage 29200 provides the structure for the message typeSourceOfSupplyNotification 29102.

(a) Message Header Package

A MessageHeader package 29204 groups the business information that isrelevant for sending a business document in a message. In oneimplementation, the MessageHeader package 29204 may not be relevant forimplementing the SourceOfSupplyNotification 29102.

(b) Source of Supply Package

The SourceOfSupply package 29206 groups information about one or moresources of supply, and includes a SourceOfSupply entity 29208, aBusinessTransactionDocumentReference package 29210, a Party package29212, a Location package 29214, a ProductInformation package 29216, anda PriceInformation package 29218. There is a 1:n relationship 29209between the SourceOfSupplyMessage object 29202 and the SourceOfSupplyentity 29208.

The SourceOfSupply entity 29208 identifies the procurement option for aparticular product or product category. In particular, theSourceOfSupply entity 29208 includes information about prices andship-to/ship-from locations. The SourceOfSupply 29208 is of type GDT:SourceOfSupply.

As discussed in further detail below, the SourceOfSupply entity 29208includes an ActiveIndicator, a DeletedIndicator, a SourcingPriorityCode,a ValidityPeriod, a TargetQuantity, a TargetAmount, aGoodsReceiptProcessingDuration, and a PlannedDeliveryDuration. TheActiveIndicator indicates whether a source of supply may be used forsupply planning, and is of type GDT: ActiveIndicator. TheDeletedIndicator indicates whether or not a source of supply islogically deleted, and is of type GDT: DeletedIndicator. TheSourcingPriorityCode indicates the priority of a source of supply duringsourcing. The sourcing priority may be defined in the purchase contractso that, for example, reference sources of supply may be determined. TheSourcingPriorityCode is of type GDT: BusinessTransactionPriorityCode.The ValidityPeriod indicates the period in which a source of supply isvalid, and is of type GDT: DateTimePeriod. The TargetQuantity identifiesthe notified total quantity of a product. The Buyer and Seller agreedupon this quantity as part of a purchase contract for a source ofsupply. The TargetQuantity is of type GDT: Quantity. The TargetAmountidentifies the notified total value of a product. The Buyer and Selleragreed upon this amount as part of a purchase contract for a source ofsupply. The TargetAmount is of type GDT: Amount. TheGoodsReceiptProcessingDuration indicates the time that elapses from whena product is received to when it is made available for the purpose ofprocurement. The goods receipt processing duration is required forchecking the product and placing it in storage, for example. It is takeninto account during scheduling. The GoodsReceiptProcessingDuration is oftype GDT: Duration. The PlannedDeliveryDuration indicates the plannedtime required for delivering the product from an external source ofsupply. The planned delivery duration may be specified in the purchasecontract so that the earliest availability date may be checked and therelease date for a purchase requisition calculated. ThePlannedDeliveryDuration is of type GDT: Duration.

A source of supply 29208 determines which quantities of which productsmay be procured from which locations, at what price, and when. Thesource of supply 29208 may be external (e.g., a vendor) or internal(e.g., a firm's own plant). The source of supply is used for supplyplanning. The sources of supply listed in a SourceOfSupplyNotification29102 are derived from one base business document. The sources of supply29208 normally correspond to the purchase contract items for individualproducts or product categories.

The following example will be used to clarify the information includedin the SourceOfSupply 29208. DaimlerChrysler and Bosch conclude apurchase contract for the delivery of servo pumps. They agree to a totalpurchase quantity of 500,000 items totalling EUR 50 million. Bosch mayoffer a price of EUR 90 for purchase orders for more than 500 items. Theagreement is valid for DaimlerChrysler ship-to locations in Stuttgartand Boblingen. DaimlerChrysler and Bosch agree to the special price ofEUR 90 for Stuttgart. With the conclusion of the purchase contract,DaimlerChrysler has a procurement option for servo pumps.

(i) Business Transaction Document Reference

The BusinessTransactionDocumentReference package 29210 groups thereferences to business documents on which a source of supply may bebased. The Business TransactionDocumentReference package 29210 includesa PurchaseContractReference entity 29220 and aSchedulingAgreementReference entity 29222.

(c) Purchase Contract Reference

The PurchaseContractReference entity 29220 is a reference to an outlineagreement governing the supply of materials or services by the supplieras required within a certain period. The PurchaseContractReferenceentity 29220 is of type GDT: BusinessTransactionDocumentReference. Thereis a 1:c relationship 29221 between the SourceOfSupply entity 29208 andthe PurchaseContractReference entity 29220. In the example above, thenumber of the purchase contract concluded between DaimlerChrysler andBosch is specified by the PurchaseContractReference entity 29220.

(a) Scheduling Agreement Reference

The SchedulingAgreementReference entity 29222 is a reference to anoutline agreement governing the procurement of materials on predefineddates within a certain period. The SchedulingAgreementReference entity29222 is of type GDT: BusinessTransactionDocumentReference. There isalso a 1:c relationship 29223 between the SourceOfSupply entity 29208and the SchedulingAgreementReference entity 29222.

(ii) Party

The Party package 29212 groups the business partners who may be involvedwith a base business document of a source of supply. The Party package29212 includes a BuyerParty entity 29224 and a SellerParty entity 29226.If the flow of goods does not take place between the locations definedfor the BuyerParty entity 29224 and the SellerParty entity 29226, thesource of supply 29208 may be specified with ShipToLocation 29228 andShipFromLocation 29230 entities in the location package 29214. If asource of supply 29208 refers to a purchase contract, the contractpartners are listed in the respective BuyerParty entity 29224 andSellerParty entity 29226. Continuing with the previous example,DaimlerChrysler as the buyer is listed in the BuyerParty entity 29224and Bosch as the seller is listed in the SellerParty entity 29226.

(a) Buyer Party

The BuyerParty entity 29224 identifies the company or person thatpurchases goods or services. The BuyerParty entity 29224 is of type GDT:BusinessTransactionDocumentParty, where the “InternalID” is used. ABuyerParty 29224 does not have to be listed for an internal source ofsupply 29208. There is a 1:c relationship 29225 between theSourceOfSupply entity 29208 and the BuyerParty entity 29224.

(b) Seller Party

The SellerParty entity 29226 identifies the company or person that sellsgoods or services. The SellerParty entity 29226 is of type GDT:BusinessTransactionDocumentParty, where the “InternalID” is used. ASellerParty 29226 does not have to be listed for an internal source ofsupply 29208. There is a 1:c relationship 29227 between theSourceOfSupply entity 29208 and the SellerParty entity 29226.

(iii) Location

The Location package 29214 includes information about the locationsbetween which goods may flow. The Location package 29214 includes aShipToLocation entity 29228 and a ShipFromLocation entity 29230. If morethan one ship-to or ship-from location is specified, the source ofsupply 29208 is valid for all combinations of these locations. In otherwords, the ship-from locations listed are valid sources of supply forthe ship-to locations. In the example above, for DaimlerChrysler,Stuttgart and Boblingen are listed as ship-to locations 29228 for asource of supply 29208. In this example, if servo pumps are required forthe production location in Hungary, the specified source of supply 29208cannot be used.

The ShipToLocation entity 29228 identifies the location to which goodsare to be delivered or where services are to be provided. TheShipToLocation entity 29228 is of type GDT:BusinessTransactionDocumentLocation, where the “InternalID” is used. Theship-to location 29228 is specified if the ship-to address differs fromthe BuyerParty address and is required for accurately specifying thesource of supply 29208. There is a 1:cn relationship 29229 between theSourceOfSupply entity 29208 and the ShipToLocation entity 29228.

The ShipFromLocation entity 29230 identifies the location from whichgoods may be shipped. The ShipFromLocation entity 29230 is of type GDT:BusinessTransactionDocumentLocation, where the “InternalID” is used. Theship-from location 29230 is specified if the ship-from address differsfrom the SellerParty address and is required for accurately specifyingthe source of supply. There is also a 1:cn relationship 29231 betweenthe SourceOfSupply entity 29208 and the ShipFromLocation entity 29230.

(iv) Product Information

The ProductInformation package 29216 groups the information required foridentifying, describing, and classifying a product that may be procuredfrom a source of supply 29208. The ProductInformation package 29216includes a Product entity 29232 and a ProductCategory entity 29234. Inone implementation, either a product 29232 or product category 29234 isspecified in a source of supply 29208.

The Product entity 29232 identifies, describes, and classifies theproduct or service. The Product entity 29232 is of type GDT:BusinessTransactionDocumentProduct, where the “InternalID” is used.There is a 1:c relationship 29233 between the SourceOfSupply entity29208 and the Product entity 29232.

The ProductCategory entity 29134 identifies the product category for theproduct or service. The ProductCategory entity 29134 is of type GDT:BusinessTransactionDocumentProduct Category, where the “InternalID” isused. There is a 1:c relationship 29235 between the SourceOfSupplyentity 29208 and the ProductCategory entity 29234.

(v) Price Information

The PriceInformation package 29218 groups the information required forcalculating the payment due for a product that may be procured from asource of supply 29208. The PriceInformation package 29218 includes aPrice entity 29236, a Scale entity 29238, and a Line entity 29240. ThePriceInformation package 29218 may be used to transfer an effectiveprice function for a source of supply 29208. During sourcing, thisinformation may be used in Supply Chain Planning 29106 to determine thecheapest source of supply if a decision has to be made between more thanone SourceOfSupply 29208.

(a) Price

The Price entity 29236 identifies the remuneration for a product, whichis valid for a certain period and ship-to location, and may be scaledaccording to quantity. The price entity 29136 includes a ShipToLocation(e.g., in the ShipToLocation entity 29228), a ValidityPeriod, aFixedCostsAmount, and a NetUnitPrice. The ShipToLocation identifies theship-to location for which the pricing scale is valid, and is of typeGDT: BusinessTransactionDocumentLocation. The ValidityPeriod identifiesthe validity period for the pricing scale, and is of type GDT:DateTimePeriod. The FixedCostsAmount identifies the fixed costs for aprocurement transaction, and is of type GDT: Amount. The NetUnitPriceidentifies the net price for a base quantity of a product, and is oftype GDT: Price. As shown in FIG. 292, there is a 1:cn relationship29237 between the SourceOfSupply entity 29208 and the Price entity29236.

The Price entity 29236 may reference or include a PriceScale or Scaleentity 29238 and a PriceScaleLine or Line entity 29240. The NetUnitPriceis specified as an element of the Price entity 29236 if a pricing scalehas not been specified. If a ship-to location-specific price isspecified, the ship-to location is also listed in the Location package29214 and specified with the same identifiers (such as “InternalID”). Asshown in FIG. 292, there is a 1:c relationship 29239 between the Priceentity 29236 and the Scale entity 29238.

(b) Price Scale

The PriceScale entity 29238 includes a set of price scale lines arrangedlinearly in accordance with a scale (axis) base type. The Scale 29238includes a AxisIntervalBoundaryTypeCode, which is a coded representationfor typing the discrete values on a scale as interval boundaries. ThePriceScale entity 29238 delivers the interpretation of scale axis values(scale levels) in a price scale. The AxisIntervalBoundaryTypeCode is oftype GDT: ScaleAxisIntervalBoundaryTypeCode. The PriceScale 29238 mayalso reference or include a Line entity 29240.

(c) Price Scale Line

The PriceScaleLine entity (or Line entity 29240) identifies the price ofa product depending on the quantity. The Line entity 29240 includes aQuantity and a NetUnitPrice. The Quantity is the quantity of the productin the base unit of measure (scale quantity), and is of type GDT:Quantity. The NetUnitPrice is the net price for the quantity of theproduct, in the base unit of measure, which is defined in Quantity, andis of type GDT: Price. A PriceScaleLine 29240 consists of a price scaleaxis value or price scale level (“Quantity”) and a price scale rate(“NetUnitPrice”). As shown in FIG. 292, there is a 1:n relationship29241 between the Scale entity 29238 and the Line entity 29240.

(3) Message Data Type Element Structure

FIGS. 293A-D depict the element structure for the Source Of SupplyNotification 29102. The element structure is similar to the abovedescribed data model of the Source Of Supply Notification as reflectedin FIG. 292, but provides additional information regarding the detailsfor interfacing with or implementing a Source Of Supply Notification. Asshown in FIGS. 293A-D, the element structure identifies the differentpackages 29300 that may be in a respective Source Of Supply Notification29102. The element structure for the Source Of Supply Notificationincludes six levels 29302, 29304, 29306, 29308, 29310, and 29312associated with a respective package 29300. The element structure for aSource Of Supply Notification also identifies the cardinality 29314 anddata type 29316 for the elements at respective levels 29302, 29304,29306, 29308, 29310, and 29312 in a package 29300.

The outermost package of this interface is a SourceOfSupplyMessagepackage 29318, which includes a SourceOfSupplyMessage entity 29320 atthe first level 29302. The SourceOfSupplyMessage entity is of messagedata type SourceOfSupplyMessage 29322.

The SourceOfSupplyMessage package 29318 includes a SourceOfSupplypackage 29324 that has a SourceOfSupply entity 29326. There is one ormore 29328 SourceOfSupply entities 29326, each being of global data type(“GDT”): SourceOfSupply. As shown in FIGS. 293A-B, each SourceOfSupplyentity 29326 includes an ActiveIndicator 29332, a DeletedIndicator29338, a SourcingPriorityCode 29344, a ValidityPeriod 29350, aTargetQuantity 29356, a TargetAmount 29362, aGoodsReceiptProcessingDuration 29368, and a PlannedDeliveryDuration29374. The ActiveIndicator 29332 is of type GDT: ActiveIndicator. TheDeletedIndicator 29338 is of type GDT: DeletedIndicator 29342. TheSourcingPriorityCode 29344 is of type GDT:BusinessTransactionPriorityCode 29348. The ValidityPeriod 29350 is oftype GDT: DateTimePeriod 29354. The TargetQuantity 29356 is of type GDT:Quantity 29360. The TargetAmount 29364 is of type GDT: Amount 29366. TheGoodsReceiptProcessing Duration 29368 is of type GDT: Duration 29372.The PlannedDeliveryDuration 29374 is also of type GDT: Duration 29378.For each SourceOfSupply entity 29326, there is as follows: one 29334ActiveIndicator 29332; one 29340 DeletedIndicator 29338; zero or one29346 SourcingPriorityCode 29344; one 29352 ValidityPeriod 29350; zeroor one 29358 TargetQuantity 29356; zero or one 29364 TargetAmount 29364;zero or one 29370 GoodsReceiptProcessing Duration 29368; and zero or one29376 PlannedDeliveryDuration 29374.

The SourceOfSupply package 29324 also includes aBusinessTransactionDocument Reference package 29380, a Party package29382, a Location package 29386, a Product Information package 29388,and a Price Information package 29388.

The BusinessTransactionDocumentReference package 29380 includes aPurchaseContractReference entity 29390 of type GDT:BusinessTransactionDocumentReference 29394 and aSchedulingAgreementReference entity 29396 of type GDT:BusinessTransactionDocumentReference 29300A. There is zero or one 29392PurchaseContractReference entity 29390 for each SourceOfSupply entity29324. Similarly, there is zero or one 29398SchedulingAgreementReference entity 29396 for each SourceOfSupply entity29324.

The Party package 29382 includes a BuyerParty entity 29302A of type GDT:BusinessTransactionDocumentParty 29306A and a SellerParty entity 29308Aof type GDT: BusinessTransactionDocumentParty 29312A. There is zero orone 29304A BuyerParty entity 29390 for each SourceOfSupply entity 29324.Similarly, there is zero or one 29310A SellerParty entity 29396 for eachSourceOfSupply entity 29324.

The Location package 29384 includes a ShipToLocation entity 29314A oftype GDT: BusinessTransactionDocumentLocation 29318A and aShipFromLocation entity 29320A of type GDT:BusinessTransactionDocumentLocation 29324A. There is any number 29316Aof ShipToLocation entities 29314A for each SourceOfSupply entity 29324.Similarly, there is any number 29322A of ShipFromLocation entities29320A for each SourceOfSupply entity 29324.

The Product Information package 29386 includes a Product entity 29326Aof type GDT: BusinessTransactionDocumentProduct 29330A and aProductCategory entity 29332A of type GDT: ProductCategory 29336A. Thereis zero or one 29328A Product entities 29329114A and zero or one 29334AProduct Categories 29332A for each SourceOfSupply entity 29324.

As shown in FIG. 293C, the Price Information package 29388 includes aPrice entity 29338. There is any number 29340A of Price entities 38A foreach SourceOfSupply entity 29324. Each Price entity 29236 includes: aShipToLocation entity 29342A of a type GDT:BusinessTransactionDocumentLocation 29346A; a ValidityPeriod 29348A of atype GDT: DateTimePeriod 29352A; a FixedCostsAmount entity 29354A of atype GDT: Amount 29358A; and a NetUnitPrice 29360A of a type GDT: Price29364A. For each SourceOfSupply entity 29324, there is zero or one29344A ShipToLocation 29342A, one 29350A ValidityPeriod 29348A, zero orone 29356A FixedCostsAmount 29354A, and zero or one 29360A NetUnitPrice29360A.

Each Price entity 29338 also includes zero or one 29368A PriceScales orScale entities 29368A. Each Scale 29366A includes one 29172AAxisIntervalBoundary Type Code 29370A of a type GDT:ScaleAxisIntervalBoundaryTypeCode 29374A. Each Price entity 29338 mayalso include one or more 29378A of Price Scale Line entities 29376A.Each Line entity 29376A includes a Quantity 29380A of a type GDT:Quantity 29384A and a NetUnitPrice 29386A of a type GDT: Price 29390A.

c) Purchase Order Interfaces

PurchaseOrder interfaces are the interfaces that are required in a B2Bprocess to exchange purchase orders and order confirmations between abuyer and a seller. Traditional methods of communication during anordering process, such as via mail or fax, are cost intensive, prone toerror, and relatively slow, since the data has to be entered manually.Electronic communication between the procurement system and a salessystem eliminates such problems. Purchase order interfaces directlyintegrate the applications that implement the interfaces and form abasis for mapping data to widely-used standard formats, such asRosettaNet. More than just a simple interface structure, the purchaseorder interfaces define the underlying corporate significance and, atthe same time, dispense with the need to exchange proprietaryinformation during straightforward ordering processes. In this way,applications that implement purchase order interfaces can be integratedwithout the need for complex project work.

(1) Message Types

There are a total of four message types for mapping a B2B orderingprocess:

(1) PurchaseOrderRequest; (2) PurchaseOrderChangeRequest;

(3) PurchaseOrderCancellationRequest; and (4) PurchaseOrderConfirmation.The PurchaseOrderRequest is sent from a buyer to a seller, and is usedto initiate a new ordering process. The PurchaseOrderChangeRequest issent from a buyer to a seller, and is used to change a purchase orderduring an ordering process. Changing a purchase order includes creatingnew items, changing existing items, and cancelling items. ThePurchaseOrderCancellationRequest is sent from a buyer to a seller, andis used to cancel a purchase order. The PurchaseOrderConfirmation issent from a buyer to a seller, and is used to confirm a purchase order.It can be sent in direct response to a PurchaseOrderRequest, aPurchaseOrderChangeRequest, or a PurchaseOrderCancellationRequestmessage, or without an immediately preceding message to display changesto the purchase order or its confirmation status. The seller can changea purchase order by creating new items or by changing or rejectingexisting items.

(a) Purchase Order Request

A PurchaseOrderRequest is a buyer's request to the seller to delivergoods or provide services. The structure of the message typePurchaseOrderRequest is specified in the message data typePurchaseOrderMessage. Portions of the maximum PurchaseOrderMessagestructure are used. The PurchaseOrderRequest is the message that a buyeruses to start a new ordering process with a seller.

(b) Purchase Order Change Request

A PurchaseOrderChangeRequest is a change made to the buyer's request tothe seller to deliver goods or provide services. The structure of themessage type PurchaseOrderChangeRequest is specified in the message datatype PurchaseOrderMessage. Portions of the maximum PurchaseOrderMessagestructure are used. The PurchaseOrderChangeRequest is the message that abuyer uses to inform the seller of change requests during an orderingprocess. In a PurchaseOrderChangeRequest, the buyer can change headerdata, add new items, and change or cancel existing items.

(c) Purchase Order Cancellation Request

A PurchaseOrderCancellationRequest is a cancellation of the buyer'srequest to the seller to deliver goods or provide services. Thestructure of the message type PurchaseOrderCancellationRequest isspecified in the message data type PurchaseOrderCancellationMessage. ThePurchaseOrderCancellationRequest is the message that a buyer uses toinform the seller of a purchase order cancellation request during anordering process.

(d) Purchase Order Confirmation

A PurchaseOrderConfirmation is a confirmation, partial confirmation, ora change sent from the seller to the buyer concerning the requesteddelivery of goods or provision of services. The structure of the messagetype PurchaseOrderConfirmation is specified in the message data typePurchaseOrderMessage. Portions of the maximum PurchaseOrderMessagestructure are used. The PurchaseOrderConfirmation is the message that aseller uses to confirm a purchase order with the buyer, or to inform thebuyer of any purchase order change requests during an ordering process.

The seller can use the PurchaseOrderConfirmation message in three ways.First, the seller can explicitly confirm planned delivery dates/times,quantities, and prices with the buyer and propose substitute products.Second, the seller can inform the buyer of any purchase order changerequests. Third, the seller can inform the buyer of the confirmationstatus of the purchase order. Possible statuses include “AP” (Accepted),“AJ” (Pending), and “RE” (Rejected). The confirmation status can be setat the header or item level. Rejection at the header level alsosignifies rejection of all items. Acceptance at the header levelsignifies general acceptance of the purchase order, while individualitems can be accepted, open, or rejected. The same logic applies fromitems to sub-items in item hierarchies. There are no restrictions forchanges to the confirmation status, e.g., a change from “AP” (Accepted)to “RE” (Rejected) is permitted. The confirmation status indicateswhether a seller will fulfil a purchase order. Accordingly, the sellerhas to confirm cancellation of a purchase order with the status “RE”(Rejected). If the confirmation status “AP” (Accepted) is set for apurchase order but no additional information is provided about confirmeddelivery dates/times, quantities, etc., the purchase order is regardedas “confirmed as ordered.”

Each PurchaseOrderConfirmation reflects the status of an item. Thus, ifthe status of a given PurchaseOrderConfirmation item is “AP” (Accepted),the relevant purchase order (“PURCHASE ORDER”) item is confirmed “asordered.” If a change was requested for this item in a differentPurchaseOrderConfirmation message, that change request is invalid.

(2) Message Choreography

The interaction between the purchase order interfaces in an orderingprocess is described in detail below. FIG. 294 depicts the messagechoreography for the purchase order interface. The choreography involvesthree business entities: Supply Chain Planning 29402, SupplierRelationship Mgmt Purchasing 29404, and Supplier 29406. The SupplierRelationship Mgmt Purchasing 29404 sends a SourceOfSupplyNotification29408 to SupplyChain Planning 29402. SupplyChain Planning 29402 sends aPurchaseRequirementRequest 29410 to Supplier Relationship MgmtPurchasing 29404. Supplier Relationship Mgmt Purchasing 29404 sends aPurchaseOrderRequest 29412, a PurchaseOrderChangeRequest 29414, and/or aPurchaseOrderCancellationRequest 29416 to Supplier 29406. Supplier 29406sends a PurchaseOrderConfirmation 29418 to Supplier Relationship MgmtPurchasing 29404. Supplier Relationship Mgmt Purchasing 29404 sends aPurchaseRequirementConfirmation 29420 and a PurchaseOrder Information29422 to SupplyChain Planning 29402. Supplier Relationship MgmtPurchasing 29404 sends a PurchaseOrder Information 29424 to Any System29426.

(a) Process Flow

The buyer starts an ordering process by sending a PurchaseOrderRequestmessage. Once the ordering process has been started, the buyer can use aPurchaseOrderChangeRequest message to send a change request or aPurchaseOrderCancellationRequest message to send a purchase ordercancellation request to the seller at any time. After receiving thePurchaseOrderRequest message, the seller can use aPurchaseOrderConfirmation message to inform the buyer of the status ofthe purchase order or to send change requests at any time. Once anordering process has been started, there are no restrictions with regardto the order in which particular messages have to be sent. The buyerdoes not have to wait for confirmation from the seller before beingallowed to send purchase order change requests, using aPurchaseOrderChangeRequest message.

In each PurchaseOrderRequest or PurchaseOrderChangeRequest message, thebuyer can explicitly request a PurchaseOrderConfirmation message fromthe vendor by setting theFollowUpPurchaseOrderConfirmation/RequirementCode to “Expected.” In thiscase, the seller should send a PurchaseOrderConfirmation in response tothe receipt of a PurchaseOrderRequest, PurchaseOrderChangeRequest, orPurchaseOrderCancellationRequest message. To ensure that the response issent as promptly as possible, no user interaction is required on theseller side. If a buyer's request cannot be automatically accepted orrejected, the confirmation status “AJ” (Pending) can be set. APurchaseOrderConfirmation in response to a PurchaseOrderChangeRequestreconfirms all the items that were transferred with thePurchaseOrderChangeRequest. The seller should also send aPurchaseOrderConfirmation if the confirmation status of the entirepurchase order or of a particular item is changed or if quantities,prices, or deadlines can be explicitly confirmed, or if changes are madeto confirmations that have already been sent.

A PurchaseOrderConfirmation is sent by the seller if the seller rejectsindividual items or the entire purchase order, or if the seller requestschanges to the purchase order.

The buyer uses a PurchaseOrderChangeRequest message to confirm theseller's change requests (by accepting the seller's requests as changes)or to reject them (by not accepting the seller's requests). To avoidendless loops, the buyer should not be permitted to use aPurchaseOrderChangeRequest message to automatically respond to merechanges to the confirmation status or to the explicit confirmation ofdelivery dates/times, quantities, and prices.

(b) Error Handling

A recipient system accepts every formally correct incoming purchaseorder message. The buyer resolves business problems using aPurchaseOrderchangeRequest or PurchaseOrderCancellationRequest message,and the seller resolves business problems using aPurchaseOrderConfirmation message. It is up to the recipient system todistinguish between technical and business errors. Borderline casesinclude incorrect ISO codes for currencies, or languages.

A procurement system cannot reject a PurchaseOrderConfirmationautomatically. Instead, the procurement system uses aPurchaseOrderChangeRequest or provide other suitable mechanisms to avoidendless loops, i.e., to avoid having the procurement system continuouslyreject every confirmation of each rejection.

In order to restart an ordering process that is corrupt as a result of afailed message, the procurement system may provide an option fortransferring the current status of the purchase order, together with allof the associated data, at any time using a PurchaseOrderChangeRequestmessage. In this message, the ItemCompleteTransmissionIndicator may beset to “true.” The sales and distribution (“SD”) system may provide thesame functions for the PurchaseOrderConfirmation. In order to restart aprocess following a failed PurchaseOrderRequest message, the procurementsystem should be able to restart an ordering process at any time using aPurchaseOrderRequest message.

(c) Message Operations

The purchase order messages are implemented by eight message operations,four on the buyer side and four on the seller side. The buyer sideoperations are PurchaseOrderRequest_Out, PurchaseOrderChangeRequest_Out,PurchaseOrderCancellationRequest_Out, and PurchaseOrderConfirmation_In,and the seller side operations are PurchaseOrderRequest_In,PurchaseOrderChangeRequest_In, PurchaseOrderCancellationRequest_In, andPurchaseOrderConfirmation_Out.

(3) Message Data Type Purchase Order Message

The message data type PurchaseOrderMessage groups together the businessinformation that is relevant for sending a business document in amessage and the PurchaseOrder object in the business document. Thismessage data type groups together the MessageHeader package and thePurchaseOrder package, described in detail below.

(a) Message Header Package

A MessageHeader package 29502 groups together the business informationthat is relevant for sending a business document in a message. Itincludes a MessageHeader entity 29508. There is a 1:1 relationshipbetween the PurchaseOrderMessage entity 29506 and the MessageHeaderentity 29508.

(i) Message Header

The MessageHeader groups together business information from theperspective of the sending application to identify the business documentin a message, to provide information about the sender, and to provideany information about the recipient.

The MessageHeader entity 29508 includes a SenderParty entity 29510 and aRecipientParty entity 29512. There is a 1:cn relationship between theMessageHeader entity 29508 and the RecipientParty entity 29512. TheMessageHeader entity 29508 is of type GDT:BusinessDocumentMessageHeader.

The MessageHeader entity 29508 also includes an ID, a ReferenceID, and aCreationDateTime. The MessageID is set by the sending application. Withthe ReferencedMessageID, reference is made in the currentBusinessDocument to a previous BusinessDocument.

(ii) Sender Party

The SenderParty is the party responsible for sending a business documentat business application level. The SenderParty entity 29510 is of typeGDT: BusinessDocumentMessageHeaderParty. The SenderParty entity 29510can be filled by the sending application to name a contact person forany problems with the message. This is particularly useful if anadditional infrastructure (such as a marketplace) is located between thesender and the recipient. The SenderParty entity 29510 is used totransfer the message, and may be ignored by the receiving application.It should be filled by the sender if the PurchaseOrder package cannot beused to transfer the participating parties. The SenderParty entity 29510includes the standard information included with parties, as discussedbelow, as denoted by ellipses 29514.

(iii)Recipient Party

The RecipientParty is the party responsible for receiving a businessdocument at business application level. The RecipientParty entity 29512is of type GDT: BusinessDocumentMessageHeaderParty. The RecipientPartyentity 29512 may be filled by the sending application to name a contactperson for any problems that occur with the message. This isparticularly useful if an additional infrastructure (such as amarketplace) is located between the sender and the recipient. TheRecipientParty entity 29512 is used to transfer the message, and may beignored by the receiving application. It should be filled by the senderif the PurchaseOrder package cannot be used to transfer theparticipating parties. The RecipientParty entity 29512 includes thestandard information included with parties, as discussed below, asdenoted by ellipses 29516.

(b) Purchase Order Package

The PurchaseOrder package 29504 includes a Party package 29518, aLocation package 29520, a DeliveryInformation package 29522, aPaymentInformation package 29524, a PriceInformation package 29523, anAttachment package 29526, a Description package 29528, aFollowUpBusinessTransactionDocument package 29530, an Item package29532, and a PurchaseOrder entity 29534. There is a 1:1 relationshipbetween the PurchaseOrderMessage entity 29506 and the PurchaseOrderentity 29534.

(i) Purchase Order

A PurchaseOrder is a buyer's request (or a change to or confirmation ofsuch a request) to a seller to provide or deliver certain quantities ofproducts at one or several dates. This includes purchase order change,confirmation, or cancellation. The PurchaseOrder is divided intoPurchaseOrderItems that each specify an ordered product or additionalinformation relevant for such a product, such as information about billsof material (BOMs) or discount or value limits (see PurchaseOrderItempackage). In addition to the buying party and the seller, additionalparties can be involved in the PurchaseOrder (see Party package).Locations can be specified for the purchase order delivery (see Locationpackage). Delivery and payment terms are also agreed (seeDeliveryInformation package and PaymentInformation package). Notes orreferences to attachments can be specified for the PurchaseOrder (seeDescription package and Attachment package).

The types of follow-up documents that are expected with regard to thePurchaseOrder package can also be specified (seeFollowUpBusinessTransactionDocument package). The PurchaseOrder entity29534 is of type GDT: PurchaseOrder. The PurchaseOrder entity 29534includes an ID, SellerID, a BuyerPostingDateTime, aBuyerLastChangeDateTime, SellerPostingDateTime,SellerLastChangeDateTime, AcceptanceStatusCode, Note, andItemListCompleteTransmissionIndicator. The ID is a unique identifierspecified by the buyer for the purchase order. The SellerID is theunique identifier specified by the seller for the purchase order. TheBuyerPostingDateTime is the creation date/time of the purchase order atthe buyer. The BuyerPostingDateTime is of type GDT: DateTime. TheBuyerLastChangeDateTime is the date/time of the last change made to thepurchase order by the buyer. The BuyerLastChangeDateTime is of type GDT:DateTime. The SellerPostingDateTime is the creation date/time of thesales order at the seller. The SellerPostingDateTime is of type GDT:DateTime. The SellerLastChangeDateTime is the date/time of the lastchange made to the sales order by the seller. TheSellerLastChangeDateTime is of type GDT: DateTime. TheAcceptanceStatusCode is the coded representation for the status of theseller's acceptance of a purchase order. The AcceptanceStatusCode is oftype GDT: AcceptanceStatusCode. The Note is a short description or thetitle of the purchase order. It is generally used to provide the userwith a simple method for searching for a particular purchase order. TheNote is of type GDT: Note. The ItemListCompleteTransmissionIndicatorspecifies whether all purchase order items are always to be transmitted(items that are not transmitted are implicitly classed as canceled) orwhether only new, changed purchase order items that have been canceledsince the last transmission are to be transmitted. TheItemListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator.

Within any given purchase order, monetary amounts and prices aretypically in the same currency. Preferably, the ID must not be changedonce a purchase order has been created, the SellerID must not be changedonce a purchase order has been created, the BuyerPostingDateTime mustnot be changed once a purchase order has been created, theBuyerLastChangeDateTime can be changed by the buyer only, theSellerPostingDateTime must not be changed once a purchase order has beencreated, and the Note can be changed by the buyer only.

In variations of the Message Type PurchaseOrderRequest, the SellerIDmust not be used, the SellerPostingDateTime must not be used, theSellerLastChangeDateTime must not be used, the AcceptanceStatusCode mustnot be used, the ItemListCompleteTransmissionIndicator must be set to“true,” the ActionCode for all items must be set to “01” (Create), theheader and all the items that are to be ordered must be transmitted,together with all the associated data, and items that were deleted atthe buyer before the purchase order was first sent to the seller mustnot be transmitted.

In variations of the Message Type PurchaseOrderChangeRequest, TheSellerID must not be used, the SellerPostingDateTime must not be used,the SellerLastChangeDateTime must not be used, and theAcceptanceStatusCode must not be used. If anItemListCompleteTransmissionIndicator is set to “true,” the ActionCodefor all items must be set to “01” (Create) the header and all the itemsmust be transmitted, together with all the associated data, and itemsthat are not transmitted are implicitly classed as canceled. If anItemListCompleteTransmissionIndicator is set to “false,” the ActionCodefor the transmitted items must be set to “01” (Create), “02” (Change),or “03” (Delete), the ActionCode “01” (Create) must be set if the itemis being transmitted for the first time, “02” (Change) if the item hasbeen changed since the last transmission, and “03” (Delete) if the itemhas been canceled since the last transmission. In variations where it isset to “false,” the header must be transmitted, together with all theassociated data; new or changed items must be transmitted, together withall the associated data, canceled items must be transmitted, togetherwith the ID and ActionCode, and should be transmitted without anyadditional data; and items that are not transmitted are classed asunchanged and are not implicitly classed as canceled.

In variations of the Message Type PurchaseOrderConfirmation, theAcceptanceStatusCode at header and item level must be set to “AP”(Accepted), “AJ” (Pending), or “RE” (Rejected). If anItemListCompleteTransmissionIndicator is set to “true,” the ActionCodefor all items must be set to “01” (Create); the header and all itemsmust be transmitted, together with all the associated data; and Itemsthat are not transmitted are implicitly classed as canceled.

In some variations, if an ItemListCompleteTransmissionIndicator is setto “false,” the ActionCode for the transmitted items must be set to “01”(Create) or “02” (Change). Then, the ActionCode “01” (Create) must beset if the item is being transmitted for the first time and “02”(Change) if the item has been changed by the seller since the lasttransmission. In those variations, the seller cannot cancel items bysetting the ActionCode to “03” (Delete), but can reject items by settingthe AcceptanceStatusCode “RE” (Rejected). If the header containschanges, it must be transmitted, together with all the associated data.Otherwise, the ID and the AcceptanceStatusCode must be transmitted, butnot the header data. If an item contains changes, it must betransmitted, together with all the associated data, including the ID,ActionCode, AcceptanceStatusCode, ConfirmedNetUnitPrice, andConfirmedScheduleLines. If the confirmed values in ConfirmedNetUnitPriceor ConfirmedScheduleLine have changed, an item must be transmitted,together with the ID, ActionCode, AcceptanceStatusCode,ConfirmedNetUnitPrice, and ConfirmedScheduleLines; the item data shouldnot be transmitted. If the confirmation status has changed, an item mustbe transmitted, together with the ID, ActionCode, andAcceptanceStatusCode. ConfirmedNetUnitPrice and ConfirmedSheduleLinesshould be transmitted, but not the item data. An unchanged item shouldnot be transmitted. Items that are not transmitted are classed asunchanged and are not implicitly classed as canceled.

In some implementations, if items are not transmitted, the confirmationstatus “AP” (Accepted) or “RE” (Rejected) is copied from the header toall items, that is, to accept or reject an entire purchase order, onlythe purchase order number and the AcceptanceStatusCode have to betransmitted at header level.

The PurchaseOrder object in the message data type PurchaseOrderMessageprovides a structure that is not used only for purchase order messagesbut also for changing and confirming a purchase order. The semantic ofthe PurchaseOrder object is, therefore, more generic in order to coverthese aspects.

(ii) Purchase Order Party Package

The Party package 29518 groups together the business parties involved inthe purchase order. It includes a BuyerParty entity 29536, a SellerPartyentity 29538, a ProductRecipientParty entity 29540, a VendorParty entity29542, a ManufacturerParty entity 29544, a BillToParty entity 29546, aPayerParty entity 29548, and a CarrierParty entity 29550.

Either the ID or the ID and address may be transferred for each party.If the ID is transferred, the ID address defined in the master data isused. If the ID and address are transferred, the ID identifies the partyand the address is deemed to be a document address that is differentfrom the master data address. A default logic is used for the partiesfrom the header to the items and within item hierarchies. Partiesspecified in the header are used for the items for which a correspondingparty is not explicitly transferred and that are directly assigned tothe header. In accordance with the same logic, parties transferred atthe item level are used for the subitems assigned to the relevant itemin an item hierarchy. The default logic is used for the party as awhole, including the contact person. Parts of a party specified at theheader level or for a hierarchy item should not be specified in moredetail at the item level. The default logic is a simplified version ofthe transferred message. As regards logic, parties at the header leveland for hierarchy items behave as if they have been explicitlytransferred for the subitems of the message.

(a) Buyer Party

The BuyerParty is a party that buys goods or services. The BuyerPartyentity 29536 is of type GDT: BusinessTransactionParty. The BuyerPartyentity 29536 includes an Address entity 29552 and a ContactPerson entity29554.

The Address entity 29552 includes a PersonName entity 29556, an Officeentity 29558, a PhysicalAddress entity 29560, a GeoCoordinates entity29562, and a Communication entity 29564.

The ContactPerson entity 29554 includes an Address entity 29566. TheAddress entity 29566 includes a PersonName entity 29568, an Officeentity 29570, a PhysicalAddress entity 29572, a GeoCoordinates entity29574, and a Communication entity 29576.

The same BuyerParty may be used for all of the items in a purchaseorder. The BuyerParty typically does not change once a purchase orderhas been created. The BuyerParty should typically be specified.

Changes can be made to the BuyerParty/Contact, and a differentBuyerParty/Contact is permitted for each item. Changes can be made tothe address of the BuyerParty, but different addresses should not bepermitted for each item. If a ProductRecipientParty is not specified inthe ordering process, the BuyerParty may also be used as theProductRecipientParty. If a ProductRecipientParty and ShipToLocation arenot specified in the ordering process, the BuyerParty address may beused as the ship-to address. If a BillToParty is not specified in theordering process, the BuyerParty may also be used as the BillToParty. Ifa BillToParty and PayerParty are not specified in the ordering process,the BuyerParty may also be used as the PayerParty.

(b) Seller Party

The SellerParty is a party that sells goods or services. The SellerPartyentity 29538 is of type GDT: BusinessTransactionDocumentParty. TheSellerParty entity 29538 includes the same type of information as theBuyerParty entity 29536, as denoted by ellipses 29578.

The same Seller Party may be used for the items in a purchase order. TheSeller Party should not be changed once a purchase order has beencreated. The Seller Party should typically be specified.

Changes can be made to the SellerParty/Contact and a differentSellerParty/Contact is permitted for each item. Changes can be made tothe address of the Seller Party, but different addresses should not bepermitted for each item. If a VendorParty is not specified in theordering process, the Seller Party may also be used as the VendorParty.If a VendorParty and ShipFromLocation are not specified in the orderingprocess, the address of the SellerParty may also be used as theship-from address for the material items.

(c) Product Recipient Party

The ProductRecipientParty is a party to which goods are delivered or forwhom services are provided. The ProductRecipientParty entity 29540 is oftype GDT: BusinessTransactionDocumentParty. The ProductRecipientPartyentity 29540 includes the same type of information as the BuyerPartyentity 29536, as denoted by ellipses 29580.

If a ShipToLocation is not explicitly specified in the ordering process,the ProductRecipientParty address may be used as the ship-to address.The ProductRecipientParty is not synonymous with the ShipToLocation andshould be used when the ProductRecipientParty (company or person) isdifferent than the BuyerParty.

(d) Vendor Party

The VendorParty is a party that delivers goods or provides services. TheVendorParty entity 29542 is of type GDT:BusinessTransactionDocumentParty. The VendorParty entity 29542 includesthe same type of information as the BuyerParty entity 29536, as denotedby ellipses 29582.

If a ShipFromLocation is not specified in the ordering process, theaddress of the VendorParty may be used as the ship-from address for thematerial items. The VendorParty is not the company or person that issolely responsible for transporting the goods. Rather, the CarrierPartyis responsible for this. The VendorParty is not synonymous with theShipFromLocation and should be used when the VendorParty (company orperson) is different than the SellerParty.

(e) Manufacturer Party

The ManufacturerParty is a party that manufactures goods. TheManufacturerParty entity 29544 is of type GDT:BusinessTransactionDocumentParty. The ManufacturerParty entity 29544includes the same type of information as the BuyerParty entity 29536, asdenoted by ellipses 29584.

The ManufacturerParty entity 29544 may be used for material items. Thedefault logic (from header to item to subitems) is used for materialitems. For other items, the ManufacturerParty is typically ignored. TheManufacturerParty can be used to uniquely define the context of aManufacturerProductID.

(f) Bill To Party

The BillToParty is a party to which the invoice for goods or services issent. The BillToParty entity 29546 is of type GDT:BusinessTransactionDocumentParty. The BillToParty entity 29546 includesthe same type of information as the BuyerParty entity 29536, as denotedby ellipses 29586.

If a PayerParty is not specified in the ordering process, theBillToParty may also be used as the PayerParty. Conversely, theBillToParty may not be explicitly derived from the PayerParty.

(g) Payer Party

The PayerParty is a party that pays for goods or services. ThePayerParty entity 29548 is of type GDT:BusinessTransactionDocumentParty. The PayerParty entity 29548 includesthe same type of information as the BuyerParty entity 29536, as denotedby ellipses 29588.

(h) Carrier Party

The CarrierParty is a party that transports goods. The CarrierPartyentity 29550 is of type GDT: BusinessTransactionDocumentParty. TheCarrierParty entity 29550 includes the same type of information as theBuyerParty entity 29536, as denoted by ellipses 29590.

The CarrierParty can be used for material items. The default logic (fromheader to item to subitems) is typically used for material items.

(iii) Purchase Order Location Package

The Location package 29520 groups together the locations relevant forthe purchase order. It includes a ShipToLocation entity 29592 and aShipFromLocation entity 29594.

A similar default logic to that used for Parties is also used forlocations. Either the ID or the address, or both can be transferred toeach location. If the ID is transferred, the ID address defined in themaster data is used. If the address is transferred, it is this addressthat is used (if necessary, a location is assigned at the addressrecipient). If the ID and address are transferred, the ID identifies thelocation and the address is deemed to be a document address that isdifferent to the master data address.

(a) Ship To Location

The ShipToLocation is the location to which goods are to be delivered orwhere services are to be provided. The ShipToLocation entity 29592 is oftype GDT: BusinessTransactionDocumentLocation. The ShipToLocation entity29592 includes an Address entity 29596.

The Address entity 29596 includes a PersonName entity 29598, an Officeentity 29500A, a PhysicalAddress entity 29502A, a GeoCoordinates entity29504A, and a Communication entity 29506A.

(b) Ship From Location

The ShipFromLocation is the location from which goods are to be shipped.The ShipFromLocation entity 29594 is of type GDT:BusinessTransactionDocumentLocation. The ShipFromLocation entity 29594includes the same type of information as the ShipToLocation entity29592, as denoted by ellipses 29508A.

The ShipFromLocation entity 29594 may be used for material items. Thedefault logic (from header to item to subitems) is typically used formaterial items. For the other items, the ShipFromLocation may beignored.

(iv) Purchase Order Delivery Information Package

The DeliveryInformation package 29522 groups together the informationfor a delivery required for a purchase order. The DeliveryInformationpackage 29522 includes a DeliveryTerms entity 29510A. A similar defaultlogic to that used for Parties is also used for DeliveryTerms.

The DeliveryTerms entity 29510A includes an Incoterms entity 29512A, aPartialDelivery entity 29514A, a QuantityTolerance entity 29516A, aTransport entity 29518A, and a Description entity 29520A.

The DeliveryTerms are the conditions and agreements that are valid forexecuting the delivery and transporting the ordered goods and for thenecessary services and activities. The DeliveryTerms entity 29510A is oftype GDT: DeliveryTerms. Within the DeliveryTerms, the Incoterms and thetransport may be used for material items.

(v) Purchase Order Payment Information Package

The PaymentInformation package 29524 groups together the paymentinformation about the purchase order. The PaymentInformation package29524 includes a CashDiscountTerms entity 29522A and a PaymentFormentity 29524A.

The CashDiscountTerms are the terms of payment in an ordering process.The CashDiscountTerms entity 29522A is of type GDT: CashDiscountTerms.The CashDiscountTerms entity 29522A includes a MaximumDiscount entity29526A and a NormaIDiscount entity 29528A.

The PaymentForm is the payment form together with the data required. ThePaymentForm entity 29524A includes a PaymentFormCode, which is the codedrepresentation of the payment form. The PaymentFormCode is of type GDT:PaymentFormCode. The PaymentForm entity 29524A also includes aPaymentCard entity 29530A. The PaymentCard entity 29530A is of type GDT:PaymentCard, and is a credit card or a customer card.

(vi) Purchase Order Price Information Package

A PriceInformation package 29552A groups all price information about thepurchase order. The PriceInformation package 29552A includes the Priceentity 29573A.

The Price entity 29573A is the purchase order price specified by thebuyer for the entire order. The Price entity 29573A includes the elementNetAmount. The NetAmount element is the net amount for the orderedproducts without taxes and without cash discount and is of type GDT:Amount. In one implementation, the NetAmount on header level must equalthe sum of the NetAmount of all items, taking into consideration therules for the NetAmount in the item hierarchies.

(vii) Purchase Order Attachment Package

The Attachment package 29526 groups together the attachment informationregarding the purchase order. It includes an Attachment entity 29532Aand an AttachmentWebAddress entity 29534A. There is a 1:cn relationshipbetween the PurchaseOrder entity 29534 and the Attachment entity 29532A,and a 1:cn relationship between the PurchaseOrder entity 29534 and theAttachmentWebAddress entity 29534A.

The Attachment 29532A is any document that refers to the purchase order.The Attachment entity 29532A is of type GDT: Attachment.

The AttachmentWebAddress 29534A identifies the address of a documentthat relates to the order. The document can be of any type. TheAttachmentWebAddress entity 29534A is of type GDT: AttachmentWebAddress.

(viii) Purchase Order Description Package

The Description package 29528 groups together the texts regarding thepurchase order. The Description package29528 includes a Descriptionentity 29536A and an ConfirmationDescription entity 29538A. There is a1:c relationship between the PurchaseOrder entity 29534 and theDescription entity 29536A, and a 1:c relationship between thePurchaseOrder entity 29534 and the ConfirmationDescription entity29538A.

The Description is a natural-language text regarding the purchase order,which is visible to business parties. The Description entity 29536A isof type GDT: Description. The Description can be used for the types oftextual information about the transferred purchase order and not justthe current message. An example of this would be information statingthat the Purchasing employee responsible is on vacation as of a specificdate, and indicating the name and telephone number of a substitute as ofthis date.

A ConfirmationDescription is a natural-language text regarding thepurchase order, which is not visible to business parties. TheConfirmationDescription entity 29538A is of type GDT: Description. Invariations of the Message Type PurchaseOrderRequest andPurchaseOrderChangeRequest, the ConfirmationDescription must not beused. The ConfirmationDescription can be used for all types of textualinformation about the order confirmation. An example of this would bethe seller's justification for rejecting a particular purchase order.

(ix) Purchase Order Follow-Up Message Package

The FollowUpMessage package 29530 groups together the information aboutsubsequent messages that the buyer expects to receive from the sellerwith regard to the purchase order. The FollowUpMessage package 29530includes a FollowUpPurchaseOrderConfirmation entity 29540A, aFollowUpDespatchedDeliveryNotification entity 29542A, aFollowUpServiceAcknowledgementRequest entity 29544A, and aFollowUpInvoiceRequest entity 29546A. There is a respective 1:crelationship between the PurchaseOrder entity 29534 and theFollowUpPurchaseOrderConfirmation entity 29540A, theFollowUpDespatchedDeliveryNotification entity 29542A, theFollowUpServiceAcknowledgementRequest entity 29544A, and theFollowUpInvoiceRequest entity 29546A.

The FollowUpPurchaseOrderConfirmation identifies information aboutwhether and in what form the buyer expects to receive confirmation ofthe purchase order from the seller. TheFollowUpPurchaseOrderConfirmation entity 29540A includes aRequirementCode, which is a coded representation of information aboutwhether the buyer expects to receive confirmation of the purchase orderfrom the seller. The RequirementCode is of type GDT:FollowUpMessageRequirementCode. The RequirementCode may have the values“02” (Expected) and “04” (Unexpected). In variations, if a buyer changesa RequirementCode from “Unexpected” to “Expected” during an orderingprocess, the seller should send the current confirmation status, evenfor purchase order items that have already been delivered or invoiced.If the buyer changes the RequirementCode from “Expected” to“Unexpected,” the seller should not send any more confirmations, exceptif the purchase order is canceled or if the seller changes it. Theseller can transfer the order confirmation either electronically using aPurchaseOrderConfirmation message or by traditional methods ofcommunication, such as e-mail or fax.

The FollowUpDespatchedDeliveryNotification identifies information aboutwhether the buyer wants to be informed by the seller of any outbounddeliveries. The FollowUpDespatchedDeliveryNotification entity 29542Aincludes a RequirementCode, which is a coded representation ofinformation about whether the buyer expects the seller to sendnotification of any outbound deliveries of the ordered goods. TheRequirementCode is of type GDT: FollowUpMessageRequirementCode. TheRequirementCode may have the values “02” (Expected) and “04”(Unexpected). In variations, if the buyer changes the RequirementCodefrom “Unexpected” to “Expected” during an ordering process, the sellershould inform the buyer of all the new outbound deliveries for thepurchase order once the change has been received. If the buyer changesthe RequirementCode from “Expected” to “Unexpected,” the seller shouldnot send any further information about outbound deliveries. The sellercan transfer the confirmation of the outbound delivery eitherelectronically using a DespatchedDeliveryNotification message or bytraditional methods of communication, such as e-mail or fax.Confirmation of the outbound delivery can be sent for material itemsonly, that is, the RequirementCode “Expected” can be ignored for serviceitems.

The FollowUpServiceAcknowledgementRequest identifies information aboutwhether the buyer wants to be informed by the seller of any servicesprovided. The FollowUpServiceAcknowledgementRequest entity 29544Aincludes a RequirementCode, which is a coded representation ofinformation about whether the buyer wants to be informed by the sellerof any services provided. The RequirementCode is of type GDT:FollowUpMessageRequirementCode. The RequirementCode may have the values“02” (Expected) and “04” (Unexpected). The RequirementCode may bechanged by the buyer. If the buyer changes the RequirementCode from“Unexpected” to “Expected” during an ordering process, the seller shouldinform the buyer of the new services provided once the change has beenreceived. If the buyer changes the RequirementCode from “Expected” to“Unexpected,” the seller should not send any further information aboutservices provided. The seller can transfer the confirmation of theservices either electronically using a ServiceAcknowledgementRequestmessage or by traditional methods of communication, such as e-mail orfax. In addition to service items, a confirmation of a service also cancontain planned or unplanned material items for materials that wererequired when the service was provided. In variations, if the buyerchanges the RequirementCode from “Unexpected” to “Expected” during anordering process, the seller should inform the buyer of all the newservices provided once the change has been received. If the buyerchanges the RequirementCode from “Expected” to “Unexpected,” the sellershould not send any further information about services provided. Theseller can transfer the confirmation of the services eitherelectronically using a ServiceAcknowledgementRequest message or bytraditional methods of communication, such as e-mail or fax. In additionto service items, a confirmation of a service can also contain plannedor unplanned material items for materials that were required when theservice was provided.

The FollowUpInvoiceRequest identifies information about whether thebuyer expects to receive an invoice from the seller. TheFollowUpInvoiceRequest entity 29546A includes a RequirementCode and anEvaluatedReceiptSettlementIndicator. The RequirementCode is a codedrepresentation of information about whether the buyer expects to receivean invoice from the seller. The RequirementCode is of type GDT:FollowUpMessageRequirementCode. The EvaluatedReceiptSettlementIndicatorindicates whether or not the purchase order settlement is to beprocessed automatically by the goods receipt, without an invoice. TheEvaluatedReceiptSettlementIndicator is of type GDT:EvaluatedReceiptSettlementIndicator. The RequirementCode may have thevalues “0” (Required) and “05” (Forbidden). If theEvaluatedReceiptSettlementIndicator is set to “true,” theRequirementCode should be set to “Forbidden.” In variations, if thebuyer changes the RequirementCode from “Forbidden” to “Required” duringan ordering process, the buyer and seller must agree upon what exactlyhas to be invoiced. If the buyer changes the RequirementCode from“Required” to “Forbidden,” the seller must not send any further invoicesonce the change has been received. The seller can transfer the invoiceeither electronically using an InvoiceRequest message or by traditionalmethods of communication, such as mail or fax. Whether or not the buyerexpects to receive an invoice from the seller does not depend on thetype of payment method. There are two typical cases in which the buyerdoes not expect to receive an invoice from the seller (1) purchaseorders for goods that are free-of-charge, such as test samples, and (2)purchase orders that are to be settled using the evaluated receiptsettlement (ERS) procedure (see EvaluatedReceiptSettlementIndicator).

(x) Purchase Order Item Package

The PurchaseOrderItem package 29532 includes a ScheduleLine package29548A, a ProductInformation package 29550A, a PriceInformation package29552A, a Party package 29554A, a Location package 29556A, aDeliveryInformation package 29558A, aBusinessTransactionDocumentReference package 29560A, an Attachmentpackage 29562A, a Description package 29564A, a FollowUpMessage package29559A, and a PurchaseOrderItem entity 29566A. There is a 1:cnrelationship between the PurchaseOrder entity 29534 and thePurchaseOrderItem entity 29566A. Items are arranged hierarchically usinga Hierarchy Relationship 29568A. The Hierarchy Relationship 29568A isthe relationship between a sub-item and a higher-level parent item in anitem hierarchy. There is a 1:cn relationship between the Item entity29566A and its subordinate entities, and a 1:c relationship between theItem entity 29566A and its superordinate entities.

(a) Purchase Order Item

The PurchaseOrderItem specifies a product ordered by the purchase orderor additional information about ordered products. This informationincludes specifications on discounts in kind, substitute products, andvalue limits. The PurchaseOrderItem entity 29574 includes detailedinformation about a particular product (see Product package) and itsprice (see PriceInformation package). The quantities of the product and(delivery) dates are specified in the schedule line (see ScheduleLinepackage).

For the PurchaseOrderItem entity 29566A (compared to the information ofthe PurchaseOrder), deviating parties, locations, and delivery terms maybe defined (see Party package, Location package, and DeliveryInformationpackage). The PurchaseOrderItem entity 29566A may contain references toother business documents that are relevant for the item (seeBusinessTransactionDocumentReference package). Notes or references toattachments can also be specified for the PurchaseOrderItem (seeDescription package and Attachment package).

A PurchaseOrderItem entity 29566A can be subordinate to anotherPurchaseOrderItem within a hierarchy to represent a businessrelationship between the two items. This could be information about adiscount in kind or substitute product for an ordered product, forexample. This relationship can also be used to group together purchaseorder items, that is, a PurchaseOrderItem can group together otherPurchaseOrderItems. The PurchaseOrderItem 29566A is of type GDT:PurchaseOrderItem.

The PurchaseOrderItem entity 29566A includes the following elments: ID;SellerID; ActionCode; AcceptanceStatusCode; UnplannedItemPermissionCode;UnconfirmedQuantityCanceledIndicator; andGoodsReceiptBasedInvoiceVerificationIndicator.

The ID elment is the ID is the identifier assigned by the buyer to apurchase order item and is of type GDT:BusinessTransactionDocumentItemID. The identifier is unique within aparticular purchase order and is of type GDT:BusinessTransactionDocumentItemID.

The SellerID element is the identifier assigned by the seller to apurchase order item. The identifier is unique within a particularpurchase order.

The ActionCode is the coded representation of the actions used tocreate, change, and delete items in an ordering process at the messagerecipient. The ActionCode is of type GDT: ActionCode.

The AcceptanceStatusCode is the coded representation for the status ofthe seller's acceptance of a purchase order and is of type GDT:AcceptanceStatusCode.

The UnplannedItemPermissionCode specifies whether unplanned serviceentry, goods receipt, and invoice items are permitted for a purchaseorder item later on in the process. The UnplannedItemPermissionCode isof type GDT: UnplannedItemPermissionCode.

The UnconfirmedQuantityCanceledIndicator indicates that the seller nolonger plans to confirm any quantities that have not yet been confirmed.

The GoodsReceiptBasedInvoiceVerificationIndicator indicates whetherinvoices for the order item should be checked against the goods entry.In the subsequent process, the biller can use this information to decidewhen to send the invoice (for example, immediately when the goods areissued or later, when the bill recipient should already have receivedthe goods).

In one implementation and with respect to the Message Data Type, the IDelement must not be changed once an item has been created; the SellerIDelement must not be changed once an item has been created; and theUnplannedItemPermissionCode element must not be changed once an item hasbeen created.

In one implementation and with respect to the Message TypePurchaseOrderRequest, the SellerID must not be used; theAcceptanceStatusCode must not be used; and theUnconfirmedQuantityCanceledIndicator must not be used.

In one implementation and with respect to the Message TypePurchaseOrderChangeRequest, the AcceptanceStatusCode must not be usedand the UnconfirmedQuantityCanceledIndicator must not be used.

From a semantic point of view, items can contain other items. Thisenables item hierarchies to be mapped. From a technical point of view,the item type is not defined recursively, since this cannot be handledby some commonly-used XML tools. The hierarchies are mapped using theentity HierarchyRelationship. There are various item categories, whichare governed by a variety of constraints. An item can have severalconstraint types. In this case, the item satisfies the constraints ofits constraint types. Which constraint types can be combined with oneanother and how is specified in the description of the constraint types.The following constraint types exist: (1) Standard items are the itemsto which no lower-level items have been assigned in the hierarchy. Anitem that is not referenced by another item, using the ParentItemID is astandard item; (2) Hierarchy items are items to which at least one otherlower-level item has been assigned in the hierarchy. An item that isreferenced by at least one other item, using the ParentItemID is ahierarchy item. Items are typically either standard or hierarchy items;(3) Subitems are items that have been assigned below a hierarchy itemand not directly to the purchase order header. Subitems can be bothstandard items and hierarchy items. A subitem is an item that referencesanother item using the ParentItemID; (4) Material items are items whoseproduct is a material. Items whose ProductTypeCode is “1” (Material) arematerial items; (5) Service items are items whose product is a service.Items whose ProductTypeCode is “2” (Service) are service items; (6)Unspecified product items are items for which it is not specifiedwhether they refer to a material or a service. Items whoseProductTypeCode is not specified are unspecified product items. Itemsare material, service, or unspecified product items. An unspecifiedproduct item satisfies the constraints of a material, service, or limititem; (7) Grouping hierarchy items are hierarchy items that logicallygroup together other items. Multilevel grouping hierarchies arepermitted, that is, a grouping hierarchy item can contain subitems thatare also grouping hierarchy items. Hierarchy items whose subitems haveHierarchyRelationshipTypeCode “002” (Group) are grouping hierarchyitems; subitems with a different HierarchyRelationshipTypeCode are notpermitted. Grouping hierarchy items are not permitted to be subitems ofother types of hierarchy items; (8) Substitute product hierarchy itemsare hierarchy items for which at least one subitem with a substituteproduct exists. Multilevel substitute product hierarchies are notpermitted, that is, a substitute product cannot be substituted.Hierarchy items whose subitems have HierarchyRelationshipTypeCode “006”(Substitute Product) are substitute product hierarchy items; subitemswith a different HierarchyRelationshipTypeCode are not permitted.Substitute product hierarchy items can be used as subitems in groupinghierarchies. Substitute product subitems can be transferred in thePurchaseOrderConfirmation message. The buyer can reject proposedsubstitute products by cancelling the entire associated substituteproduct hierarchy item; (9) BOM hierarchy items are hierarchy items thatgroup together other items in a BOM. Multilevel BOM hierarchies arepermitted. Hierarchy items with at least one subitem withHierarchyRelationshipTypeCode “001” (Bill of Material) are BOM hierarchyitems; additional subitems are permitted with theHierarchyRelationshipTypeCode “003” (Discount in Kind); (10) Discount inkind hierarchy items are hierarchy items for which a goods discount isgranted in the form of an inclusive or exclusive bonus quantity.Multilevel discount in kind hierarchies are not permitted, that is, nodiscount in kind can be granted for discount in kind. The goods discountis described in the form of one or more subitems in the discount in kindhierarchy item. Hierarchy items with at least one subitem withHierarchyRelationshipTypeCode “003” (Discount in Kind) are discount inkind hierarchy items; additional subitems are permitted with theHierarchyRelationshipTypeCode “001” (Bill of Material). Hierarchy itemsare grouping, BOM, or discount in kind hierarchy items. A hierarchy itemcan be both a BOM and discount in kind hierarchy item, if a discount inkind has been granted for a BOM; (11) Limit items are both standard andunspecified product items for which the exact requirements are unknownat the time of ordering. Items with a ProcurementCostUpperLimit arelimit items. Limit items are not permitted to be subitems of BOM ordiscount in kind hierarchy items. No substitute product subitems arepermitted for limit items. Dependencies between elements or entities ofthis item category are described under “Notes” for the relevant elementor entity.

(b) Hierarchy Relationship

A HierarchyRelationship is the relationship between a subitem and ahigher-level parent item in an item hierarchy. The HierarchyRelationship29568A includes a ParentItemID and a TypeCode. The ParentItemID is thereference to the parent item with the item number assigned by the buyer.The ParentItemID is of type GDT: BusinessTransactionDocumentItemID. TheTypeCode represents the hierarchical relationship between the subitemand its higher-level parent item. The TypeCode is of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode. TheParentItemID and the TypeCode typically do not changed once an item hasbeen created.

(c) Purchase Order Item Product Information Package

The ProductInformation package 29550A groups together the informationfor identifying, describing, and classifying a product in an orderingprocess. It includes a Product entity 29570A and a ProductCategoryentity 29572A. There is a 1:c relationship between the PurchaseOrderItementity 29566A and the Product entity 29570A, and a 1:c relationshipbetween the PurchaseOrderItem entity 29566A and the ProductCategoryentity 29572A. The product package is not used in grouping hierarchyitems.

The Product includes the details about a product as generally understoodfrom a commercial point of view in business documents. These are thedetails for identifying a product and product type, and the descriptionof the product. The Product entity 29570A is of type GDT:BusinessTransactionDocumentProduct. For limit items, the description(Note) can be used in the Product entity 29570A. The product number andProductTypeCode are typically not used. The ProductTypeCode typicallydoes not change once an item has been created. With the exception ofgrouping hierarchy items, at least the product number or the productdescription (Note) is specified when a new item is created. If both theproduct number and description are specified, the description isadditional information in the message and can typically be ignored bythe recipient. In substitute product subitems, the ProductTypeCode isthe same as the parent item ProductTypeCode. In substitute productsubitems, the product is the substitute product proposed by the vendorfor the product ordered in the associated substitute product hierarchyitem.

The ProductCategory includes the details about a product category asgenerally understood from a commercial point of view in businesstransaction documents. It includes details for identifying the productcategory using an internal ID, a standard ID, and IDs assigned byinvolved parties. The ProductCategory entity 29572A is of type GDT:BusinessTransactionDocumentProductCategory.

(d) Purchase Order Item Price Information Package

The PriceInformation package 29552A groups together the priceinformation in an order item. The Price package includes a Price entity29574A, a ConfirmedPrice entity 29576A, and a ProcurementCostUpperLimitentity 29578A. There is a respective 1:c relationship 29575A, 29577A,and 29579A between the PurchaseOrderItem entity 29566A and the Priceentity 29574A, the ConfirmedPrice entity 29576A, and theProcurementCostUpperLimit entity 29578A.

The Price is typically not used in grouping hierarchy and discount inkind items. The ProcurementCostUpperLimit is typically used for limititems, whereas the Price and the Confirmed Price are typically not used.The ProcurementCostUpperLimit is typically not used for any items otherthan limit items. The PriceInformation package 29552A for a purchaseorder item includes prices; it typically does not contain anyinformation about how the prices are calculated (pricing scales, and soon).

(i) Price

The Price is the order price specified by the buyer. The Price entity29574A includes a NetUnitPrice, which is the net price specified by thebuyer for the base quantity (without tax or cash discount) of theproduct. The NetUnitPrice is of type GDT: Price. The Price entity 29574Aalso includes a NetAmount, which is an amount specified by the buyer forthe ordered products without taxes and without cash discount. TheNetAmount is of type GDT: Amount.

In BOM hierarchies: (1) if the price is specified for the item at thetop of the BOM hierarchy and not for the subitems, this price applies;(2) if the price is specified for standard items (end nodes in thehierarchy tree) in the BOM hierarchy, these prices apply, where theprice of the entire BOM is the total of the individual prices; and (3)if a price is specified at different levels in the BOM hierarchy, theprice that appears above the others in the tree applies. Differencesbetween the total of the individual prices and the price at the nexthighest hierarchy level are permissible. These may be caused bydiscounts for the entire BOM. In substitute product subitems, the Pricecan be used to transfer substitute product prices. The same rules applyhere as for the Price in BOM hierarchies.

(ii) Confirmed Price

The ConfirmedPrice is the purchase order price confirmed by the seller.The ConfirmedPrice entity 29576A includes a NetUnitPrice, which is thenet price (without tax or cash discount) confirmed by the seller for thebase quantity of the product. The NetUnitPrice is of type GDT: Price. InBOM and substitute product hierarchies, the same rules apply for theConfirmedPrice as for the Price.

(e) Purchase Order Item Party Package

The PurchaseOrderItemParty Package 29554A is similar to the Partypackage 29518 at the header level. The PurchaseOrderItemParty Package29554A includes a BuyerParty entity 29580A, a SellerParty entity 29582A,a ProductRecipientParty entity 29584A, a VendorParty entity 29586A, aManufacturerParty entity 29588A, a BillToParty entity 29590A, aPayerParty entity 29592A, and a CarrierParty entity 29594A. There is arespective 1:c relationship 29581A, 29583A, 29585A, 29587A, 29589A,29591A, 29593A, and 29595A between the PurchaseOrderItem entity 29566Aand the BuyerParty entity 29580A, the SellerParty entity 29582A, theProductRecipientParty entity 29584A, the VendorParty entity 29586A, theManufacturerParty entity 29588A, the BillToParty entity 29590A, thePayerParty entity 29592A, and the CarrierParty entity 29594A. Each ofthe BuyerParty entity 29580A, the SellerParty entity 29582A, theProductRecipientParty entity 29584A, the VendorParty entity 29586A, theManufacturerParty entity 29588A, the BillToParty entity 29590A, thePayerParty entity 29592A, and the CarrierParty entity 29594A includesthe same type of information as the BuyerParty entity 29536 above, asdenoted by ellipses.

(f) Purchase Order Item Location Package

The PurchaseOrderItemLocation Package 29556A is similar to the Locationpackage 29520 at the header level. The PurchaseOrderItemLocation Package29556A includes a ShipToLocation entity 29512B and a ShipFromLocationentity 29514B. There is a 1:c relationship between the PurchaseOrderItementity 29566A and the ShipToLocation entity 29512B, and there is a 1:crelationship between the PurchaseOrderItem entity 29566A and theShipFromLocation entity 29514B. The ShipToLocation entity 29512B and theShipFromLocation entity 29514B include the same type of information asthe ShipToLocation entity 29592, as denoted by ellipses 29516B and29518B.

(g) Purchase Order Item Delivery Information Package

The PurchaseOrderDeliveryLocation Package 29556A is similar to theDeliveryInformation package 29522 at the header level. ThePurchaseOrderDeliveryLocation Package 29556A includes DeliveryTermsentity 29520B. There is a 1:c relationship between the PurchaseOrderItementity 29566A and the DeliveryTerms entity 29520B.

The DeliveryTerms entity 29520B includes an Incoterms entity 29522B, aPartialDelivery entity 29524B, a QuantityTolerance entity 29526B, aTransport entity 29528B, and a Description entity 29530B. There is a 1:crelationship between the DeliveryTerms entity 29520B and the Incotermsentity 29522B. There is a 1:c relationship between the DeliveryTermsentity 29520B and the PartialDelivery entity 29524B. There is a 1:crelationship between the DeliveryTerms entity 29520B and theQuantityTolerance entity 29526B. There is a 1:c relationship between theDeliveryTerms entity 29520B and the Transport entity 29528B. There is a1:c relationship between the DeliveryTerms entity 29520B and theDescription entity 29530B.

(h) Purchase Order Item Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 29560A groups togetherthe references to business documents that are relevant for thePurchaseOrderItem and have a business relationship with the item. TheBusinessTransactionDocumentReference package 29560A includes aQuoteReference entity 29532B, a PurchaseContractReference entity 29534B,SalesContractReference entity 29535B, an OriginPurchaseOrderReferenceentity 29536B, a BuyerProductCatalogueReference entity 29538B, and aSellerProductCatalogueReference entity 29540B. There is a respective 1:crelationship between the PurchaseOrderItem entity 29566A and theQuoteReference entity 29532B, the PurchaseContractReference entity29534B, the OriginPurchaseOrderReference entity 29536B, theBuyerProductCatalogueReference entity 29538B, and theSellerProductCatalogueReference entity 29540B. None of the entities inthe BusinessTransactionDocumentReference package 29560A should be usedin grouping hierarchy items.

Individual items in business documents should be referenced in thepurchase order messages from the item level. If an item assignment isnot recognized, an entire document can be referenced. In this case, therecipient cannot demand that the item numbers in both documents be thesame. It is the responsibility of the recipient to try to make thisassignment using other criteria that are not necessarily unique, such asthe product number. References are used for establishing relationshipsbetween different documents. If a reference has been provided, the datarelevant to the purchase order is transferred from the documentreferenced in the purchase order message (the product number in apurchase order item is transferred even if the product number can bederived directly from a bid reference). The data in the purchase ordermessage can differ in any number of ways from the referenced documents.The recipient is able to respond appropriately to such deviations.

A QuoteReference is a reference to a quotation or an item within aquotation. The QuoteReference entity 29532B is of type GDT:BusinessTransactionDocumentReference. The QuoteReference entity 29532Bmay reference one item, that is, one ItemID is permissible.

A PurchaseContractReference is a reference to a purchase contract oritem in a purchase contract. The PurchaseContractReference entity 29534Bis of type GDT: BusinessTransactionDocumentReference. In limit items,multiple contract references are possible; a maximum of one contractreference is permissible in other item types. APurchaseContractReference entity 29534B can reference one item, that is,one ItemID is permissible. Unless otherwise agreed, the seller isresponsible for determining the correct PurchaseContractReference for aspecified SellerContractReference.

An OriginPurchaseOrderReference is a reference to the origin purchaseorder or to an item within the origin purchase order in a third-partydeal. The OriginPurchaseOrderReference entity 29536B is of type GDT:BusinessTransactionDocumentReference. An OriginPurchaseOrderReferenceentity 29536B can reference one item, that is, one ItemID ispermissible. The OriginPurchaseOrderReference 29536B is used in thepurchase orders in a third-party deal, so that the seller can referencethe original purchase order of the ShipToParty with theOriginPurchaseOrderReference.

A BuyerProductCatalogueReference is a reference to the buyer's productcatalogue or an item within the buyer's product catalogue. TheBuyerProductCatalogueReference entity 29538B is of type GDT:CatalogueReference. A BuyerProductCatalogueReference entity 29538B canreference one item, that is, one ItemID is permissible. TheBuyerProductCatalogueReference entity 29538B should be filled if apurchase order item refers to a catalogue whose number and item numberswere assigned by the buyer. In the ordering process, theBuyerProductCatalogueReference can be used as a substitute productnumber if the product is defined in a catalogue rather than having itsown master record.

A SellerProductCatalogueReference is a reference to the seller's productcatalogue or an item within the seller's product catalogue. TheSellerProductCatalogueReference entity 29540B is of type GDT:CatalogueReference. A SellerProductCatalogueReference entity 29540B canreference one item, that is, one ItemID is permissible. TheSellerProductCatalogueReference entity 29540B should be filled if apurchase order item refers to a catalogue whose number and item numberswere assigned by the seller. In the ordering process, theSellerProductCatalogueReference can be used as a substitute productnumber if the product is defined in a catalogue rather than having itsown master record.

(i) Purchase Order Item Attachment Package

The PurchaseOrderItemAttachment Package is similar to the Attachmentpackage 29526 at the header level. The PurchaseOrderItemAttachmentPackage 29562A includes an Attachment entity 29542B and anAttachmentWebAddress entity 29544B. There is a 1:cn relationship betweenthe PurchaseOrderItem entity 29566A and the AttachmentWebAddress entity29544B, and a 1:cn relationship between the PurchaseOrderItem entity29566A and Attachment entity 29542B.

(j) Purchase Order Item Description Package

The PurchaseOrderItemDescription Package 29564A is similar to theDescription package 29528 at the header level. ThePurchaseOrderItemDescription Package 29564A includes a Descriptionentity 29546B and a ConfirmationDescription entity 29548B. There is a1:c relationship between the PurchaseOrderItem entity 29566A and theDescription entity 29546B, and a 1:c relationship between thePurchaseOrderItem entity 29566A and the ConfirmationDescription entity29548B.

(k) Purchase Order Item Follow-Up Message Package

The FollowUpMessage package 29559A groups together the information aboutsubsequent messages that the buyer expects to receive from the sellerwith regard to the purchase order. The FollowUpMessage package 29559Aincludes a FollowUpPurchaseOrderConfirmation entity 29500C, aFollowUpDespatchedDeliveryNotification entity 29502C, aFollowUpServiceAcknowledgementRequest entity 29504C, and aFollowUpInvoiceRequest entity 29506C. There is a respective 1:crelationship between the PurchaseOrderItem entity 29566A and theFollowUpPurchaseOrderConfirmation entity 29500C, theFollowUpDespatchedDeliveryNotification entity 29502C, theFollowUpServiceAcknowledgementRequest entity 29504C, and theFollowUpInvoiceRequest entity 295406C.

(l) Purchase Order Item Schedule Line Package

A ScheduleLine package 29548A groups together the quantity and dateinformation about a PurchaseOrderItem. The ScheduleLine package 29548Aincludes a ScheduleLine entity 29550B and a ConfirmedScheduleLine entity29552B. There is a 1:n relationship between the PurchaseOrderItem entity29566A and the ScheduleLine entity 29550B, and a 1:cn relationshipbetween the PurchaseOrderItem entity 29566A and theConfirmedScheduleLine entity 29552B.

There is no direct relationship between the ScheduleLine entity 29550Band the ConfirmedScheduleLine entity 29552B. This has the advantage thatthe case “10 pieces for 01/01 and 10 pieces for 02/01” ordered as “20pieces for 02/01” can be confirmed simply and without interpretation onthe part of the applications.

(i) Schedule Line

A ScheduleLine is a line containing the quantity and date of aperformance schedule required by the buyer for a purchase order. TheScheduleLine entity 29550B is of type GDT:PurchaseOrderItemScheduleLine. The ScheduleLine entity 29550B includes aDeliveryPeriod entity 29554B. There is a 1:c relationship 29555B betweenthe ScheduleLine entity 29550B and the DeliveryPeriod entity 29554B.

The ScheduleLine 29550B also includes an ID, SellerID, a DeliveryPeriod,and a Quantity. The ID is the ScheduleLine number assigned by theprocurement system. The ID is of type GDT: ScheduleLineID. The SellerIDis the ScheduleLine number assigned by the sales system. The SellerID isof type GDT: ScheduleLineID. The DeliveryPeriod is the period in whichthe buyer expects a product to be delivered or service provided. TheDeliveryPeriod is of type GDT: DateTimePeriod. The Quantity is thepurchase order quantity. The Quantity is of type GDT: Quantity.

Multiple ScheduleLines for a purchase order item with identicalDeliveryPeriod should not be permitted. All of the ScheduleLines for aparticular item typically use the same unit of measure. ScheduleLinesshould not be used for grouping hierarchy items. In this case, theScheduleLines is explicitly specified for the subitems. ScheduleLines donot have to be specified for limit items. At least one ScheduleLine isspecified for the other item types. Within a ScheduleLine, the quantityis not used for limit items. For the other types of items, the quantityis specified. In the ScheduleLines of subitems for discount in kind andBOM hierarchy items, the DeliveryPeriod of the subitems is identical tothe DeliveryPeriod of the relevant parent items. In the ScheduleLines ofsubstitute product subitems, the DeliveryPeriod of the subitems isidentical to the DeliveryPeriod of the relevant parent items. Thequantities and confirmed quantities of the subitems should be added tothe quantities of the parent items, and where deviations occur, thequantities of subitems are typically regarded as the valid quantities.The ID is optional; i.e., a procurement system does not have to numberthe ScheduleLines.

(ii) Confirmed Schedule Line

A ConfirmedScheduleLine is a line containing the quantity and date of aperformance schedule confirmed by the seller for a purchase order. TheConfirmedScheduleLine entity 29552B is of type GDT:PurchaseOrderItemScheduleLine. There is a 1:cn relationship between thePurchaseOrderItem entity 29566A and the ConfirmedScheduleLine entity29552B. The ConfirmedScheduleLine entity 29552B includes aDeliveryPeriod entity 29556B. There is a 1:c relationship between theConfirmedScheduleLine entity 29552B and the DeliveryPeriod entity29556B.

The ConfirmedScheduleLine entity 29552B also includes an ID, aDeliveryPeriod, and a Quantity. The ID is the ConfirmedScheduleLinenumber assigned by the procurement system. The ID is of type GDT:ScheduleLineID. The DeliveryPeriod is the period in which the sellerprovides the buyer with confirmation of a delivery or the provision of aservice. The DeliveryPeriod is of type GDT: DateTimePeriod. The Quantityis the quantity confirmed by the seller. The Quantity is of type GDT:Quantity.

Multiple ConfirmedScheduleLines are typically not permitted for apurchase order item with identical DeliveryPeriod. The same rules applyfor the use of the ConfirmedScheduleLine for the various item types asdescribed for the ScheduleLine. Confirmation of a partial quantity doesnot mean cancellation of the remaining quantity. It simply means thatthe seller has agreed to this partial quantity and has not yet made adecision about the remaining quantity. In order to cancel a remainingquantity, the seller reduces the quantity of the ScheduleLine (not thatof the ConfirmedScheduleLine) accordingly.

(4) Message Data Type Purchase Order Cancellation Message

The message data type PurchaseOrderCancellationMessage groups togetherthe business information that is relevant for sending a businessdocument in a message and the PurchaseOrderCancellation object in thebusiness document. The message data typePurchaseOrderCancellationMessage includes aPurchaseOrderCancellationMessage package 29602, which includes aPurchaseOrderCancellationMessage entity 29604, aBusinessDocumentMessageHeader package 29606 and aPurchaseOrderCancellation package 29608. The message data typePurchaseOrderMessage makes the structure available for the message typesPurchaseOrderCancellationRequest and the relevant interfaces.

The MessageHeader package 29606 includes a MessageHeader entity 29610.There is a 1:c relationship 29612 between thePurchaseOrderCancellationMessage entity 29604 and the MessageHeaderentity 29610. The ReferenceID element of theBusinessDocumentMessageHeader entity establishes the reference to thepurchase order to be cancelled.

The MessageHeader entity 29610 includes a SenderParty entity 29614 and aRecipientParty entity 29616. There is a 1:c relationship 29618 betweenthe MessageHeader entity 29610 and the SenderParty entity 29614. Thereis a 1:c relationship 29620 between the MessageHeader entity 29610 andthe RecipientParty entity 29616. The SenderParty entity 29614 and theRecipientParty entity 29616 include the same elements as those describedfor the Party entity in the Purchase Order Message as denoted byellipses 29622 and 29624.

A PurchaseOrderCancellation package 29608 groups together thePurchaseOrderCancellation data type, which is a buyer's request to aseller to cancel a purchase order. PurchaseOrderCancellation package29608 includes a PurchaseOrderCancellation entity 29626. There is a 1:1relationship 29628 between the PurchaseOrderCancellationMessage entity29604 and the PurchaseOrderCancellation entity 29626. ThePurchaseOrderCancellation entity 29626 includes an ID, which is a uniqueidentifier specified by the buyer for the purchase order.

FIGS. 297A-ZA depict the element structure for Purchase OrderInterfaces. The element structure is similar to the data model, butprovides additional information regarding the details of the interface.The element structure identifies the different packages 29700 in theinterface, and represents the entities and/or attributes at variouslevels within the interface. As depicted in FIGS. 297A-ZA, the interfacefor Purchase Order Interface includes seven levels 29702, 29704, 29706,29708, 29710, 29712, and 29714. The element structure identifies thecardinality or occurrence 29716 between the entities and/or attributesof the interface, and provides information (i.e., type 29718 and name29720) regarding the data type that provides the basis for the entityand/or attributes. The outermost package of this interface is anPurchaseOrderMessage package 29722, which includesPurchaserOrderMessages entity 29724 at the first level 29702. ThePurchaserOrderMessages entity 29724 is of type message data type (“MDT”)29726 “Purchase Order Message” 29728.

The PurchaseOrderMessage package 29722 includes a MessageHeader package29730 and a PurchaseOrder package 29732. The MessageHeader package 29730includes MessageHeader entity 29734, which is of type AGDT 29738BusinessDocumentMessageHeader 29740. There is one 29736 MessageHeaderentity 29734 for each PurchaseOrderMessage entity 29724.

The MessageHeader entity 29734 includes a MessageID 29742, a ReferenceID29750, and a CreationDateTime 29758. MessageID 29742 is of type GDT29746 BusinessDocumentMessageID 29748. ReferenceID 29750 is of type GDT29754 BusinessDocumentMessageID 29756. CreationDateTime 29758 is of typeGDT 29762 DateTime 29764. There is one 29744 MessageID 29742 for eachMessageHeader entity 29734, one or zero 29752 ReferenceID for eachMessageHeader entity 29734, and one 29760 CreationDateTime 29758 foreach MessageHeader entity 29734.

The MessageHeader entity 29734 also includes a SenderParty entity 29766and a RecipientParty entity 29722A. The SenderParty entity 29766 is oftype AGDT 29770 BusinessDocumentMessageHeaderParty 29772, andRecipientParty entity 29722A is of type AGDT 29726ABusinessDocumentMessageHeaderParty 29728A. There is one or zero 29768SenderParty entity 29766 for each MessageHeader entity 29734. There isany number 29724A of RecipientParty entities 29722A for eachMessageHeader entity 29734.

The SenderParty entity 29766 includes an InternalID 29774, a StandardID29782, and a ContactPerson 29790. The InternalID 29774 is of type CDT29778 PaymentInternalID 29780. StandardID 29782 is of type CDT 29786PartyStandardID 29788. ContactPerson 29790 is of type CDT 29794ContactPerson 29796. There is zero or one 29776 InternalID 29774 foreach SenderParty entity 29766. There is any number 29784 of StandardID29782 for each SenderParty entity 29766. There is zero or one 29792ContactPerson 29790 for each SenderParty entity 29766.

The ContactPerson 29790 includes a BuyerID 29798, a SellerID 29706A, andan Address 29714A. The BuyerID 29798 is of type CDT 29702AContactPersonPartyID 29704A. The SellerID 29706A is of type CDT 29710AContactPersonPartyID 29712A. The Address 29714A is of type AGDT 29718AAddress 29720A. There is respectively one or zero 29700A, 29708A, and29716A BuyerID 29798, SellerID 29706A, and Address 29714A for eachContactPerson 29790.

The PurchaseOrder package 29732 includes a Party package 29710B, aLocation package 29712B, a DeliveryInformation package 29714B, aPaymentInformation package 29716B, an Attachment package 29718B, aDescription package 29720B, a FollowUpBusinessTransactionDocumentpackage 29722B, and an Item package 29724B. The PurchaseOrder package29732 also includes a PurchaseOrder entity 29730A. The PurchaseOrderentity 29730A is of type AGDT 29734A PurchaseOrder 29736A. There is one29732A PurchaseOrder entity 29730A for each PurchaseOrderMessage entity29724.

The PurchaseOrder entity 29730A includes an ID 29738A, a SellerID29746A, a BuyerPostingDateTime 29754A, a BuyerLastChangeDateTime 29762A,a SellerPostingDateTime 29770A, a SellerLastChangeDateTime 29778A, anAcceptanceStatusCode 29786A, a Note 29794A, and anItemListCompleteTransmissionIndicator 29702B. ID is of type GDT 29742ABusinessTransactionDocumentID 29744A. SellerID 29746A is of type GDT29750A BusinessTransactionDocumentID 29752A. BuyerPostingDateTime 29754Ais of type GDT 29758A DateTime 29760A. BuyerLastChangeDateTime 29762A isof type GDT 29766A DateTime 29768A. SellerPostingDateTime 29770A is oftype GDT 29774A DateTime 29776A. SellerLastChangeDateTime 29778A is oftype GDT 29782A DateTime 29784A. AcceptanceStatusCode 29786A is of typeGDT 29790A AcceptanceStatusCode 29792A. Note 29794A is of type GDT29798A Note 29700B. ItemListCompleteTransmissionIndicator 29702B is oftype GDT 29706B CompleteTransmissionIndicator 29708B. There is one29740A ID 29738A for each PurchaseOrder entity 29730A. There isrespectively zero or one 29748A, 29756A, 29764A, 29772A, 29780A, 29788A,29796A, and 29704B SellerID 29746A, BuyerPostingDateTime 29754A,BuyerLastChangeDateTime 29762A, SellerPostingDateTime 29770A,SellerLastChangeDateTime 29778A, AcceptanceStatusCode 29786A, Note29794A, and ItemListCompleteTransmissionIndicator 29702B for eachPurchaseOrder entity 29730A.

The Party package 29710B includes a BuyerParty entity 29726B, aSellerParty entity 29714C, a ProductRecipientParty entity 29724C, aVendorParty entity 29732C, a ManufacturerParty entity 29740C, aBillToParty entity 29748C, a PayerParty entity 29756C, and aCarrierParty entity 29764C.

The BuyerParty entity 29726B is of type AGDT 29730BBusinessTransactionDocumentParty 29732B. The SellerParty entity 29714Cis of type AGDT 29720C BusinessTransactionDocumentParty 29722C. TheProductRecipientParty entity 29724C is of type AGDT 29728CBusinessTransactionDocumentParty 29730C. The VendorParty entity 29732Cis of type AGDT 29736C BusinessTransactionDocumentParty 29738C. TheManufacturerParty entity 29740C is of type AGDT 29744CBusinessTransactionDocumentParty 29746C. The BillToParty entity 29748Cis of type AGDT 29752C BusinessTransactionDocumentParty 29754C. ThePayerParty entity 29756C is of type AGDT 29760CBusinessTransactionDocumentParty 29762C. The CarrierParty entity 29764Cis of type AGDT 29768C BusinessTransactionDocumentParty 29770C. There iszero or one 29728B BuyerParty entity 29726B for each PurchaseOrderentity 29730A. There is zero or one 29716C SellerParty entity 29714C foreach PurchaseOrder entity 29730A. There is zero or one 29726CProductRecipientParty entity 29724C for each PurchaseOrder entity29730A. There is zero or one 29734C VendorParty entity 29732C for eachPurchaseOrder entity 29730A. There is zero or one 29742CManufacturerParty entity 29740C for each PurchaseOrder entity 29730A.There is zero or one 29750C BillToParty entity 29748C for eachPurchaseOrder entity 29730A. There is zero or one 29758C PayerPartyentity 29756C for each PurchaseOrder entity 29730A. There is zero or one29766C CarrierParty entity 29764C for each PurchaseOrder entity 29730A.

The BuyerParty entity 29726B includes a StandardID 29734B, a BuyerID29742B, a SellerID 29750B, an Address 29758B, and a ContactPerson29766B. The StandardID 29734B is of type CDT 29738B PartyStandardID29740B. The BuyerID 29742B is of type CDT 29746B PartyPartyID 29748B.The SellerID 29750B is of type CDT 29754B PartyPartyID 29756B. TheAddress 29758B is of type AGDT 29762B Address 29764B. The ContactPerson29766B is of type CDT 29770B ContactPerson 29772B. There are any number29736B of StandardID 29734B for each BuyerParty 29726B. There is zero orone 29744B BuyerID 29742B for each BuyerParty 29726B. There is zero orone 29752B SellerID 29750B for each BuyerParty 29726B. There is zero orone 29760B Address 29758B for each BuyerParty 29726B. There is zero orone 29768B ContactPerson 29766B for each BuyerParty 29726B.

The ContactPerson 29766B includes a BuyerID 29790B, a SellerID 29798B,and an Address 29706C. The BuyerID is of type CDT 29794BContactPersonPartyID 29796B. The SellerID 29798B is of type CDT 29702CContactPersonPartyID 29704C. The Address 29706C is of type AGDT 29710CAddress 29712C. There is zero or one 29792B BuyerID 29790B for eachContactPerson 29766B. There is zero or one 29700C SellerID 29798B foreach ContactPerson 29766B. There is zero or one 29708C Address 29706Cfor each ContactPerson 29766B.

The Location package 29712B includes a ShipToLocation entity 29772C anda ShipFromLocation entity 29712D. The ShipToLocation entity 29772C is oftype AGDT 29776C BusinessTransactionDocumentShipToLocation 29778C, andthe ShipFromLocation entity 29712D is of type AGDTBusinessTransactionDocumentShipFromLocation 29718D. There is zero or one29774C ShipToLocation entity 29772C for each PurchaseOrder entity29730A, and zero or one 29714D ShipFromLocation entity 29712D for eachPurchaseOrder entity 29730A.

The ShipToLocation entity 29772C includes a StandardID 29780C, a BuyerID29788C, a SellerID 29796C, and an Address 29704D. There are any number29782C of Standard ID 29780C for each ShipToLocation entity 29772C, zeroor one 29790C BuyerID 29788C for each ShipToLocation entity 29772C, zeroor one 29798C SellerID 29796C for each ShipToLocation entity 29772C, andzero or one 29706D Address 29704D for each ShipToLocation entity 29772C.The StandardID 29780C is of type CDT 29784C LocationStandardID 29786C.The BuyerID 29788C is of type CDT 29792C LocationPartyID 29794C. TheSellerID 29796C is of type CDT 29700D LocationPartyID 29702D. TheAddress 29704D is of type AGDT 29708D Address 29710D.

The DeliveryInformation package 29714B includes a DeliveryTerms entity29720D. The DeliveryTerms entity 29720D includes a DeliveryItemGroupID29728D, a DeliveryPriorityCode 29736D, an Incoterms 29744D, aPartialDelivery 29760D, a QuantityTolerance 29780D, aMaximumLeadTimeDuration 29712E, a Transport 29720E, and a Description29748E. The DeliveryItemGroupID 29728D has an occurrence of zero or one29730D for each DeliveryTerms entity 29720D, and is of type GDT 29732DBusinessTransactionDocumentItemGroupID 29734D. The DeliveryPriorityCode29736D has an occurrence of zero or one 29738D for each DeliveryTermsentity 29720D, and is of type GDT 29740D BusinessTransactionPriorityCode29742D. The Incoterms 29744D has an occurrence of zero or one 29746D foreach DeliveryTerms entity 29720D, and is of type GDT 29748D Incoterms29750D. The PartialDelivery 29760D has an occurrence of zero or one29762D for each DeliveryTerms entity 29720D, and is of type AGDT 29764DPartialDelivery 29766D. The QualityTolerance 29780D has an occurrence ofzero or one 29782D for each DeliveryTerms entity 29720D, and is of typeAGDT 29784D QuantityTolerance 29786D. The MaximumLeadTimeDuration 29712Ehas an occurrence or zero or one 29714E for each DeliveryTerms entity29720D, and is of type GDT 29716E Duration 29718E. The Transport 29720Ehas an occurrence of zero or one 29722E for each DeliveryTerms entity29720D. The Description 29748E has an occurrence of zero or one 29750Efor each DeliveryTerms entity 29720D, and is of type GDT 29752EDescription 29754E.

The Incoterms entity 29744D includes a ClassificationCode 29752D and aTransferLocationName 29756D. There is one 29754D ClassificationCode29752D for each Incoterm 29744D, and zero or one 29758DTransferLocationName 29756D for each Incoterm 29744D.

The PartialDelivery 29760D includes a MaximalNumber 29768D and anUnlimitedIndicator 29772D. There is zero or one 29770D MaximalNumber29768D for each PartialDelivery 29760D, and zero or one 29774DUnlimitedIndicator 29772D for each PartialDelivery 29760D. TheUnlimitedIndicator 29772D is of type GDT 29776D UnlimitedIndicator29778D.

The QualityTolerance 29780D includes an OverPercent 29788D, anOverPercentUnlimitedIndicator 29796D, and an UnderPercent 29704E. TheOverPercent 29788D is of type GDT 29792D Percent 29794D, theOverPercentUnlimitedIndicator 29796D is of type GDT 29700EUnlimitedIndicator 29702E, and the UnderPercent 29704E is of type GDT29708E Percent 29710E. There is zero or one 29790D Overpercent 29788Dfor each QualityTolerance 29780D, zero or one 29798DOverPercentUnlimitedIndicator 29796D for each QualityTolerance 29780D,and zero or one 29706E UnderPercent 29704E for each QualityTolerance29780D.

The Transport 29772E includes a ServiceLevelCode 29724E, a ModeCode29732E, and a MeansDescriptionCode 29740E. The ServiceLevelCode 29724Ehas an occurrence of zero or one 29726E for each Transport 29720E, andis of type GDT 29728E TransportServiceLevelCode 29730E. The ModeCode29732E has an occurrence of zero or one 29734E for each Transport29720E, and is of type GDT 29736E TransportModeCode 29738E. TheMeansDescriptionCode 29740E has an occurrence of zero or one 29742E foreach Transport 29720E, and is of type GDT 29744ETransportMeansDescriptionCode 29746E.

The Description 29748E includes a LanguageCode 29756E. There is one29758E LanguageCode 29756E for each Description 29748E.

The Payment Information package 297146B includes a CashDiscountTerms29758E. The CashDiscountTemms 29758E is of type AGDT 29762ECashDiscountTerms 29764E. There is zero or one 29760E CashDiscountTerns29758E for each PurchaseOrder 29730A.

The CashDiscountTerms 29758E includes a PaymentBaseLineDate 29766E, aMaximumCashDiscount 29774E, a NornalCashDiscount 29790E, and aFullPaymentDueDaysValue 29710F. The PaymentBaseLineDate 29766E is oftype GDT 29770E Date 29772E. There is zero or one 29768EPaymentBaseLineDate 29766E for each CashDiscountTerms 29758E. TheMaximumCashDiscount 29774E is of type GDT 29778E CashDiscount 29780E.There is zero or one 29776E MaximumCashDiscount 29774E for eachCashDiscountTerms 29758E. The NormalCashDiscount 29790E is of type GDT29794E CashDiscount 29796E. There is zero or one 29792ENormalCashDiscount 29790E for each CashDiscountTerms 29758E. There iszero or one 29712F FullPaymentDueDaysValue 29710F for eachCashDiscountTerms 29758E.

The MaximumCashDiscount 29774E includes a DaysValue 29782E and a Percent29784E. There is one 29783E DaysValue 29782E for eachMaximumCashDiscount 29774E, and one 29785E Percent 29784E for eachMaximumCashDiscount 29774E. Percent 29784E is of type GDT 29786E Percent29788E.

The NormalCashDiscount 29790E includes a DaysValue 29798E and a Percent29702F. There is one 29700F DaysValue 29798E for each NormalCashDiscount29790E, and one 29704F Percent 29702F for each NornalCashDiscount29790E. Percent 29702F is of type GDT 29706F Percent 29708F.

The PaymentInformation package 29716B further includes a PaymentFormentity 29714F. There is one or zero 29716F PaymentForm entity 29714F foreach PurchaseOrder entity 29730A.

The PaymentForm entity 29714F includes a Code 29718F and a PaymentCard29726F. There is one occurrence 29720F of Code 29718F for eachPaymentForm entity 29714F, and there is zero or one occurrence 29728F ofPaymentCard 29726F for each PaymentForm entity 29714F. The Code 29718Fis of type GDT 29722F PaymentFormCode 29724F. The PaymentCard 29726F isof type AGDT 29730F PaymentCard 29732F.

The PaymentCard 29732F includes an ID 29734F, a ReferenceID 29742F, aSequenceID 29746F, a Holder 29750F, and an ExpirationDate 29754F. Thereis one 29736F ID 29734F for each PaymentCard 29726F, zero or one 29744FReferenceID 29742F for each PaymentCard 29726F, zero or one 29748FSequenceID 29746F for each PaymentCard 29726F, zero or one 29752F Holder29750F for each PaymentCard 29726F, and one 29756F ExpirationDate 29754Ffor each PaymentCard 29726F. The ID is of type GDT 29738F PaymentCardID29740F. The ExpirationDate 29754F is of type GDT 29758F Date 29760F.

The Attachment package 29718B includes an Attachment entity 29762F, oftype GDT 29766F Attachment 29768F and an AttachmentWebAddress entity29762FA of type AttachmentWebAddress 29762FC. There are any number29764F of Attachment entities 29762F AttachmentWebAddress entities29762FA or for each PurchaseOrder entity 29730A.

The Attachment entity 29762F includes an ID 29770F and a Filename29774F. There is one 29772F ID 29770F for each Attachment entity 29762F,and zero or one 29776F Filename 29774F for each Attachment entity29762F.

The Description package 29720B includes a Description entity 29778F anda ConfirmationDescription entity 29790F. There is zero or one occurrence29780F of the Description entity 29778F for each PurchaseOrder entity29730A, and zero or one 29792F ConfirmationDescription entity 29790F foreach Attachment entity 29762F. The Description 29778F is of type GDT29782F Description 29784F. The ConfirmationDescription 29790F is of typeGDT 29794F Description 29796F. The Description 29778F includes aLanguageCode 29786F, and there is one LanguageCode 29786F for eachDescription 29778F. Similarly, the ConfirmationDescription 29790Fincludes a LanguageCode 29798F, and there is one LanguageCode 29798F foreach ConfirmationDescription 29790F.

The FollowUpMessage 29722B includes a FollowUpPurchaseOrderConfirmation29702G, a FollowUpDespatchedDeliveryNotification 29714G, aFollowUpServiceAcknowledgementRequest 29726G, and aFollowUpInvoiceRequest 29742G. There is zero or one 29704GFollowUpPurchaseOrderConfirmation 29702G for each PurchaseOrder 29730A.There is zero or one 29716G FollowUpDespatchedDeliveryNotification29714G for each PurchaseOrder 29730A. There is zero or one 29728GFollowUpServiceAcknowledgementRequest 29726G for each PurchaseOrder29730A. There is zero or one 29744G FollowUpInvoiceRequest 29742G foreach PurchaseOrder 29730A.

The FollowUpPurchaseOrderConfirmation 29702G includes a RequirementCode29706G, which is of type GDT 29710G FollowUpMessageRequirementCode29712G. There is one RequirementCode 29706G for eachFollowUpPurchaseOrderConfirmation 29702G.

The FollowUpDespatchedDeliveryNotification 29714G includes aRequirementCode 29718G, which is of type GDT 29722GFollowUpMessageRequirementCode 29724G. There is one 29720GRequirementCode 29718G for each FollowUpDespatchedDeliveryNotification29714G.

The FollowUpServiceAcknowledgementRequest 29726G includes aRequirementCode 29734G, which is of type GDT 29738GFollowUpMessageRequirementCode 29740G. There is one 29736GRequirementCode 29734G for each FollowUpServiceAcknowledgementRequest29726G.

The FollowUpInvoiceRequest 29742G includes a RequirementCode 29746G,which is of type GDT 29750G FollowUpMessageRequirementCode 29752G. Thereis one 29748G RequirementCode 29746G for each FollowUpInvoiceRequest29742G. The FollowUpInvoiceRequest 29742G also includes anEvaluatedReceiptSettlementIndicator 29754G, which is of type GDT 29758GEvaluatedReceiptSettlementIndicator 29760G. There is zero or one 29756GEvaluatedReceiptSettlementIndicator 29754G for eachFollowUpInvoiceRequest 29742G.

The Item package 29724B includes an Item entity 29762G, which is of typeAGDT 29766G PurchaseOrderItem 29768H. There are any number 29764G ofItem entities 29762 for each PurchaseOrder entity 30A. The Item entity29762G includes an ID 29770G, a SellerID 29778G, an ActionCode 29778G,an AcceptanceStatusCode 29794G, an UnplannedItemPermissionCode 29702H,and a HierarchyRelationship 29710H. ID 29770G has an occurrence of zeroor one 29772G for each Item entity 29762G, and is of type GDT 29774GBusinessTransactionDocumentItemID 29776G. SellerID 29778G has anoccurrence of zero or one 29780G for each Item entity 29762G, and is oftype GDT 29782G BusinessTransactionDocumentItemID 29784G. ActionCode29786G has an occurrence of one 29788G for each Item entity 29762G, andis of type GDT 29790G ActionCode 29792G. AcceptanceStatusCode 29794G hasan occurrence of zero or one 29796G for each Item entity 29762G, and isof type GDT 29798G AcceptanceStatusCode 29700H.UnplannedItemPermissionCode 29702H has an occurrence of zero or one29704H for each Item entity 29762G, and is of type GDT 29706HUnplannedItemPermissionCode 29708H. HierarchyRelationship 29711H has anoccurrence of zero or one 29712H. The Item entity 29724B furtherincludes an UnconfirmrdQuantityCancelledIndicator 29702HA of type GDT29706HA CancelledIndicator 29708HA, and aGoodsReceiptBasedInvoiceVerificationIndicator 29702HB of type GDT29706HB GoodsReceiptBasedInvoiceVerificationIndicator 29708HB. There arezero or one of GoodsReceiptBasedInvoiceVerificationIndicator 29702HB orUnconfirmrdQuantityCancelledIndicator 29702HA for each Item entity29724B.

The HierarchyRelationship 29710H includes a ParentItemID 29714H, aParentItemSellerID 29722H, and a TypeCode 29730H. There is zero or one29716H ParentItemID 29714H for each HierarchyRelationship 29711H. Thereis zero or one 29724H ParentItemSellerID 29722H for eachHierarchyRelationship 29710H. There is one 29732H TypeCode 29730H foreach HierarchyRelationship 29710H. ParentItemID 29714H is of type GDT29718H BusinessTransactionDocumentItemID 29720H. ParentItemSellerID29722H is of type GDT 29726H BusinessTransactionDocumentItemID 29728H.TypeCode 29730H is of type GDT 29734HBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 29736H.

The Item package 29724B includes a ProductInformation package 29738H, aPriceInformation package 29739H, a Party package 29740H, a Locationpackage 29741H, a DeliveryInformation package 29742H, aBusinessTransactionDocumentReference package 29743H, an Attachmentpackage 29744H, a Description package 29746H, and a ScheduleLine package29748H.

The ProductInformation package 29738H includes a Product entity 29750Hand a ProductCategory entity 29790H. The Product entity 29750H is oftype GDT 29754H BusinessTransactionDocumentProduct 29756H, and there isone or zero 29752 Product entity 29750H for each Item entity 29762G. TheProductCategory entity 29790H is of type GDT 29794HBusinessTransactionDocumentProductCategory 29796H, and there is one orzero 29792H ProductCategory entity 29790H for each Item entity 29762G.

The Product entity 29750H includes a StandardID 29754H, a BuyerID29758H, a SellerID 29762H, a ManufacturerID 29766H, a TypeCode 29774H,and a Note 29782H. The StandardID 29754 is of type CDT 29756HProductStandardID 29757H. The BuyerID 29758H is of type CDT 29760HProductPartyID 29761H. The SellerID 29762H is of type CDT 29764HProductPartyID 29765H. The ManufacturerID 29766H is of type CDT 29770HProductPartyID 29772H. The TypeCode 29774H is of type GDT 29778HProductTypeCode 29780H. The Note 29782H is of type GDT 29786H Note29788H. There are any number 29755H of StandardID 29754H for eachProduct entity 29750H. There is zero or one 29759H BuyerID 29758H foreach Product entity 29750H. There is zero or one 29763H SellerID 29762Hfor each Product entity 29750H. There is zero or one 29768HManufacturerID 29766H for each Product entity 29750H. There is zero orone 29776H TypeCode 29774H for each Product entity 29750H. There is zeroor one 29784H Note 29782H for each Product entity 29750H.

The ProductCategory entity 29790H includes a StandardID 29798H, aBuyerID 29706I, and a SellerID 29714I. There is any number of StandardID29798H for each ProductCategory entity 29790H. There is zero or one29708I BuyerID 29706I for each ProductCategory entity 29790H. There iszero or one 29716I SellerID 29714I for each ProductCategory entity29790H. The StandardID is of type CDT 29702I ProductCategoryStandardID29704I. The BuyerID 29706I is of type CDT 29710I ProductCategoryPartyID29712I. The SellerID 29714I is of type CDT 29718I ProductCategoryPartyID29710I.

The PriceInformation package 29739H includes a Price entity 29722I.There is zero or one 29728I Price entity 29722I for each Item entity29762G.

The Price entity 29722I includes a NetUnitPrice 29726I. There is zero orone 29728I NetUnitPrice 29726I for each Price entity 29722I. TheNetUnitPrice 29726I is of type AGDT 29730I Price 29732I.

The NetUnitPrice 29726I includes an Amount 29734I and a BaseQuantity29744I. There is one 29736I Amount 29734I for each NetUnitPrice 29726I,and one 29746I BaseQuantity 29744I for each NetUnitPrice 29726I. Amount29734I is of type GDT 29738I Amount 29740I, and BaseQuantity 29744I isof type GDT 29748I Quantity 29750I. Amount 29734I includes aCurrencyCode 29742I, and there is one CurrencyCode 29742I for eachAmount 29734I. BaseQuantity 29744I includes a UnitCode 29752I, and thereis one UnitCode 29752I for each BaseQuantity 29744I.

The PriceInformation package 29739H also includes a ConfirmedPriceentity 29756I. There is zero or one 29758I ConfirmedPrice 29756I foreach Item entity 29762G. The ConfirmedPrice entity 29756I includes aNetUnitPrice 29760I, which is of type AGDT 29764I Price 297766I. Thereis zero or one 29762I NetUnitPrice 29760I for each ConfirmedPrice entity29756I.

The NetUnitPrice 29760I includes an Amount 29768I and a BaseQuality29782I. The Amount is of type GDT 29772I Amount &74I, and there is one29770I Amount &68I for each NetUnitPrice 29760I. The BaseQuality 29782Iis of type GDT 29786I Quantity 29788I, and there is one 29784IBaseQuality 29782I for each NetUnitPrice 29760I. The Amount 29768includes a CurrencyCode 29776I, and there is one 29778I CurrencyCode29776I for each Amount 29768I. The BaseQuality 29782I includes aUnitCode 29790I, and there is one 29792I UnitCode 29790I for eachBaseQuality 29782I.

The Party package 29740H includes a BuyerParty entity 29794I, aSellerParty entity 29702J, a ProductRecipientParty entity 29710J, aVendorParty entity 29718J, a ManufacturerParty entity 29726J, aBillToParty entity 29734J, a PayerParty entity 29742J, and aCarrierParty entity 29750J. The BuyerParty entity 29794I has anoccurrence of zero or one 29796I for each Item entity 29762G, and is oftype AGDT 29798I BusinessTransactionDocumentParty 29700J. TheSellerParty entity 29702J has an occurrence of zero or one 29704J foreach Item entity 29762G, and is of type AGDT 29706JBusinessTransactionDocumentParty 29708J. The ProductRecipientPartyentity 29710J has an occurrence of zero or one 29712J for each Itementity 29762G, and is of type AGDT 29714JBusinessTransactionDocumentParty 29716J. The VendorParty entity 29718Jhas an occurrence of zero or one 29720J for each Item entity 29762G, andis of type AGDT 29722J BusinessTransactionDocumentParty 29724J. TheManufacturerParty entity 29726J has an occurrence of zero or one 29728Jfor each Item entity 29762G, and is of type AGDT 29730JBusinessTransactionDocumentParty 29732J. The BillToParty entity 29734Jhas an occurrence of zero or one 29736J for each Item entity 29762G, andis of type AGDT 29738J BusinessTransactionDocumentParty 29740J. ThePayerParty entity 29742J has an occurrence of zero or one 29744J foreach Item entity 29762G, and is of type AGDT 29746JBusinessTransactionDocumentParty 29748J. The CarrierParty entity 29750Jhas an occurrence of zero or one 29752J for each Item entity 29762G, andis of type AGDT 29754J BusinessTransactionDocumentParty 29756J.

The Location package 29741H includes a ShipToLocation 29758H and aShipFromLocation 29766J. The ShipToLocation 29758J is of type AGDT29762J BusinessTransactionDocumentShipToLocation 29764J, and there iszero or one 29760J ShipToLocation 29764J for each Item entity 29762G.The ShipFromLocation 29766J is of type AGDT 29770JBusinessTransactionDocumentShipFromLocation 29772J, and there is zero orone 29768H ShipFromLocation 29766J for each Item entity 29762G.

The DeliveryInformation package 29742H includes DeliveryTerms 29774J.There is zero or one 29776J DeliveryTerms 29774J for each Item entity29762G. The DeliveryTerms 29774J is of type AGDT 29778J DeliveryTerms29780J.

The BusinessTransactionDocumentReference package 29743H includes aQuoteReference 29782J, a PurchaseContractReference 29706K, aSalesContractReference 29730K, an OriginPurchaseOrderReference 29754K, aBuyerProductCatalogueReference 29778K, and aSellerProductCatalogueReference 29702L. There is one or zero 29784JQuoteReference 29782J for each Item entity 29762G. There is any numberof PurchaseContractReference 29706K for each Item entity 29762G. Thereis any number of SalesContractReference 29730K for each Item entity29762G. There is zero or one 29756K OriginPurchaseOrderReference 29754Kfor each Item entity 29762G. There is zero or one 29780KBuyerProductCatalogueReference 29778K for each Item entity 29762G. Thereis zero or one 29704L SellerProductCatalogueReference 29702L for eachItem entity 29762G.

QuoteReference 29782J is of type AGDT 29786JBusinessTransactionDocumentReference 29788J. QuoteReference 29782Jincludes an ID 29790J and an ItemID 29798J. There is one ID for eachQuoteReference 29782J, and any number of ItemID 29798J for eachQuoteReference 29782J. The ID is of type GDT 29794JBusinessTransactionDocumentID 29796J, and the ItemID 29798J is of typeGDT 29702K BusinessTransactionDocumentItemID 29704K.

PurchaseContractReference 29706K is of type AGDT 29710KBusinessTransactionDocumentReference 29712K. PurchaseContractReference29706K includes an ID 29714K, which is of type GDT 29718KBusinessTransactionDocumentID, and an ItemID 29722, which is of typeBusinessTransactionDocumentItemID 29728K. There is one 29716K ID foreach PurchaseContractReference 29706K, and any number of ItemID 29722Kfor each PurchaseContractReference 29706K.

SalesContractReference 29730K is of type AGDT 29734KBusinessTransactionDocumentReference 29736K. SalesContractReference29730K includes an ID 29738K and an ItemID 29746K. There is one ID29738K for each SalesContractReference 29730K, and any number of ItemID29746K for each SalesContractReference 29730K. ID is of type GDT 29742KBusinessTransactionDocument ID 29744K, and ItemID 29746K is of typeBusinessTransactionDocumentReference 29760K.

OriginPurchaseOrderReference 29754K is of type AGDT 29758KBusinessTransactionDocumentReference 29760K.OriginPurchaseOrderReference 29754K includes an ID 29762K, which is oftype GDT BusinessTransactionDocumentID, and an ItemID 29770K, which isof type GDT 29774K BusinessTransactionDocumentItemID 29776K. There isone 29764K ID 29762K for each OriginPurchaseOrderReference 29754K, andany number 29772K of ItemID 29770K for each OriginPurchaseOrderReference29754K.

BuyerProductCatalogueReference 29778K is of type AGDT 29782KCatalogueReference 29784K. BuyerProductCatalogueReference 29778Kincludes an ID 29786K and an ItemID 29794K. There is one 29788K ID29786K for each BuyerProductCatalogueReference 29778K, and any number29796K of ItemID 29794K for each BuyerProductCatalogueReference 29778K.ID is of type GDT 29790K CatalogueID 29792K, and ItemID 29794K is oftype GDT 29798K CatalogueItemID 29700L.

SellerProductCatalogueReference 29702L is of type AGDT 29706LCatalogueReference 29708L. SellerProductCatalogueReference 29702Lincludes an ID 29710L and an ItemID 29718L. There is one 29712L ID29710L for each SellerProductCatalogueReference 29702L, and any number29720L of ItemID 29718L for each SellerProductCatalogueReference 29702L.ID is of type GDT 29714L CatalogueID 29716L, and ItemID 29718L is oftype GDT 29722L CatalogueItemID 29724L.

The Attachment package 29744H includes an Attachment entity 29726L,which is of type AGDT 29732L Attachment 29734L. There is any number29728L of Attachment entities 29726L for each Item entity 29762G. TheAttachment package 29744H further includes an AttachmentWebAddress29726LA of type AGDT 29732LA AttachmentWebAddress 29734LA. There arezero or more AttachmentWebAddress entities 29726LA for each Attachmentpackage 29744H.

The Description package 29746H includes a Description entity 29736L anda ConfirmationDescription entity 29748L. There is one or zero 29738LDescription entity 29736L for each Item entity 29762G, and one or zero29750L ConfirmationDescription entity 29748L for each Item entity29762G. Description 29736L is of type GDT 29740L Description 29742L, andConfirmationDescription 29748L is of type GDT 29752L Description 29754L.Description 29736L includes a LanguageCode 29744L, and there is one29746L LanguageCode 29744L for each Description 29736L.ConfirmationDescription 29748L includes a LanguageCode 29756L, and thereis one 29758L LanguageCode 29756L for each ConfirmationDescription29748L.

The ScheduleLine package 29748H includes a ScheduleLine entity 29760Land a ConfirmedScheduleLine entity 29728M. There is any number 29762L ofScheduleLine entity 29760L for each Item entity 29762G, and any number29730M of ConfirmedScheduleLine entity 29728M for each Item entity29762G. ScheduleLine entity 29760L is of type AGDT 29764LPurchaseOrderItemScheduleLine 29766L, and ConfirmedScheduleLine entity29728M is of type AGDT 29732M PurchaseOrderItemScheduleLine 29734M.ScheduleLine entity 29760L includes an ID 29768L, a SellerID 29776L, aDeliveryPeriod 29784L, and a Quantity 29716M. ID 29768L is of type GDT29772L BusinessTransactionDocumentItemScheduleLineID 29774L. There isone or zero 29770L ID 29768L for each ScheduleLine 29760L. SellerID29776L is of type GDT 29780LBusinessTransactionDocumentItemScheduleLineID 29782L. There is one orzero 29778L SellerID 29776L for each ScheduleLine 29760L. DeliveryPeriod29784L is of type AGDT 29788L DateTimePeriod 29790L. There is one 29786LDeliveryPeriod 29784L for each ScheduleLine 29760L. Quantity 29716M isof type GDT 29720M Quantity 29722M. There is one or zeero 29718MQuantity 29716M for each ScheduleLine 29760L.

DeliveryPeriod 29784L includes a StartDateTime 29792L, an EndDateTime29700M, and a Duration 29708M. StartDateTime 29792L is of type GDT29796L DateTime 29798L, EndDateTime 29700M is of type GDT 29704MDateTime 29706M, and Duration 29708M is of type GDT 29712M Duration29714M. There is a respective one or zero 29794L, 29702M, and 29710MStartDateTime 29792L, EndDateTime 29700M, and Duration 29708M for eachDeliveryPeriod 29784L.

The Item package 29724D further includes aFollowUpPurchaseOrderConfirmation entity 29744HA, aFollowUpDespatchedDeliveryNotification entity 29754HA, aFollowUpServiceAcknowledgementRequest entity 29766HA, and aFollowUpInvoiceRequest entity 29776HA at the third level 29706. There iszero or one 29746HAA FollowUpPurchaseOrderConfirmation entity 29744HAfor each PurchaseOrder entity 29730A. FollowUpPurchaseOrderConfirmationentity 29744HA includes a RequirementCode 29748HA at the fourth level29708. The RequirementCode 29748HA is of type GDTFollowUpMessageRequirementCode 29752HA, and there is one 29750HARequirementCode 29748HA for each FollowUpPurchaseOrderConfirrnationentity 29744HA.

There is zero or one 29756HA FollowUpDespatchedDeliveryNotificationentity 29754HA for each PurchaseOrder entity 29730A.FollowUpDespatchedDeliveryNotification entity 29754HA includes aRequirementCode 29760HA at the fourth level 29708. The RequirementCode29760HA is of type GDT FollowUpMessageRequirementCode 29764HA, and thereis one 29762HA RequirementCode 29722D for eachFollowUpDespatchedDeliveryNotification entity 29754HA.

There is zero or one 29768HA FollowUpServiceAcknowledgementRequestentity 29766HA for each PurchaseOrder entity.FollowUpServiceAcknowledgementRequest entity 29766HA includes aRequirementCode 29770HA at the fourth level 29708. The RequirementCode29770HA is of type GDT FollowUpMessageRequirementCode 29774HA, and thereis one 29772HA RequirementCode 29770HA for eachFollowUpServiceAcknowledgementRequest entity 29766HA.

There is zero or one 29778HA FollowUpInvoiceRequest entity 29776HA foreach PurchaseOrder entity 29730A. FollowUpInvoiceRequest entity 29776HAincludes a RequirementCode 29780HA and anEvaluatedReceiptSettlementIndicator 29786HA at the fourth level 29708.The RequirementCode 29780HA is of type GDTFollowUpMessageRequirementCode 29784HA, and there is one 29782HARequirementCode 29780HA for each FollowUpInvoiceRequest entity 29776HA.The EvaluatedReceiptSettlementIndicator 29786HA is of type GDTEvaluatedReceiptSettlementIndicator 29790HA, and there is zero or one29788HA EvaluatedReceiptSettlementIndicator 29786HA for eachFollowUpInvoiceRequest entity 29776HA.

d) Service Acknowledgement Interfaces

In B2B processes, service acknowledgement interfaces are required forsending services entered by the seller so that they can be acknowledgedby the buyer. Traditional methods of communication in an orderingprocess, such as mail or fax, are cost intensive, prone to error, andrelatively slow, since data has to be entered manually. Electroniccommunication between the procurement and sales system largelyeliminates such problems.

The Service Acknowledgement interfaces were developed for the ServiceProcurement business scenario. In the Service Procurement scenario,services are purchased, which are then acknowledged and confirmed usingthe Service Acknowledgement interfaces. The messages ServiceAcknowledgement Request and Service Acknowledgement Confirmationdirectly integrate the applications that implement the interfaces andform a basis for mapping data to widely-used XML standard formats, suchas PIDX or CIDX.

More than just a simple interface structure, the service acknowledgementinterfaces define underlying corporate significance and, at the sametime, dispense with the need to exchange proprietary information instraightforward purchasing processes. In this way, applications thatimplement the service acknowledgement interfaces can be integratedwithout the need for complex project work.

Three message types exist for mapping a B2B service acknowledgementprocess. The message type “ServiceAcknowledgementRequest” is sent by theservice provider to the buyer. It is used for sending services that havebeen entered. The message type “ServiceAcknowledgementConfirmation” issent by the buyer to the seller. It is used for acknowledging a servicethat has been entered. It is a direct response to aServiceAcknowledgementRequest. The buyer sends the A2A message ofmessage type “Service Acknowledgement Information” to all partiesinterested in the confirmation of the service. It is used to informthese parties that an entered service has been confirmed.

The two messages types ServiceAcknowledgementRequest andServiceAcknowledgementConfirmation are based on the same structure, themessage data type ServiceAcknowledgementMessage. The message data typeServiceAcknowledgement is a subset of the message data typeServiceAcknowledgementInformation. The message typeServiceAcknowledgementInformation is based on the message dataServiceAcknowledgementInformation.

A ServiceAcknowledgementRequest is a request from the seller asking thebuyer to acknowledge services that have been entered. The structure ofthe message type ServiceAcknowledgementRequest is specified by themessage data type ServiceAcknowledgementMessage. In one implementation,only parts of the maximum ServiceAcknowledgementMessage structure areused. The ServiceAcknowledgementRequest is used for invoice verificationand for automatically settling a purchase order without the seller'sinvoice.

A ServiceAcknowledgementConfirmation is a confirmation (or rejection) ofthe service entered. The structure of the message typeServiceAcknowledgementConfirmation is specified by the message data typeServiceAcknowledgementMessage. In one implementation, only parts of themaximum ServiceAcknowledgementMessage structure are used. TheServiceAcknowledgementConfirmation is the message used by the buyer toinform the seller that the service acknowledgement is confirmed, pendingdecision, or rejected. The buyer can use theServiceAcknowledgementConfirmation message as follows. The buyer caninform the seller of the confirmation status of the service. Possiblestatuses are “AP” (accepted), “AJ” (pending), and “RE” (rejected). Theconfirmation status can be set at header level only. Rejection at headerlevel also signifies rejection of all items. The data in theServiceAcknowledgementRequest must not be changed. In addition to theconfirmation status, only a free text (ConfirmedDescription) can beentered at header and item level. A ServiceAcknowledgementConfirmationis not absolutely necessary in a B2B service acknowledgement process.

A ServiceAcknowledgementInformation is a notification of theacknowledgement (or rejection) of an entered service. The structure ofthe message type ServiceAcknowledgementInformation is defined by themessage data type ServiceAcknowledgementInformationMessage. TheServiceAcknowledgementInformation is the notification with which thebuyer informs all parties interested in the acknowledgement of theservice.

(1) Message Choreography

FIG. 298 depicts the message choreography for Service AcknowledgementInterfaces. The choreography involves interested applications of anysystem 29800 and two business entities: a seller or service provider(supplier) 29802 and a buyer (Purchasing or SRM) 29804. In theimplementation shown in FIG. 298, the seller 29802 sends a“ServiceAcknowledgementRequest” message 29806 to the buyer 29804. TheServiceAcknowledgementRequest message 29806 is used for sending one ormore entered services. The buyer 29804 then sends a“ServiceAcknowledgementConfirmation” message 29808 to the seller 29802.The ServiceAcknowledgementConfirmation message 29808 is a directresponse to a ServiceAcknowledgementRequest 29806 message and is used toacknowledge a service that has been entered.

Both the ServiceAcknowledgementRequest 29806 and theServiceAcknowledgementConfirmation message 29808 use the same structureof message data type ServiceAcknowledgementMessage. As discussed below,however, each message 29806 and 29808 may use parts of theServiceAcknowledgementMessage structure.

In one implementation, the ServiceAcknowledgementRequest 29806 is arequest from the seller or Purchasing 29802 asking the buyer or Supplier29804 to acknowledge one or more services that have been entered. TheServiceAcknowledgementRequest 29806 is used for ServiceAcknowledgementverification and for automatically settling a purchase order without theseller's ServiceAcknowledgement.

In one implementation, the ServiceAcknowledgementConfirmation 29808 is aconfirmation (or rejection) of the service entered. TheServiceAcknowledgementConfirmation 29808 is the message used by thebuyer or Supplier 29804 to inform the seller or Purchasing 29802 thatthe service acknowledgement is confirmed, pending decision, or rejected.The buyer 29804 may use the ServiceAcknowledgementConfirmation message29808 as follows.

(1) The buyer 29804 may inform the seller 29802 of the confirmationstatus of the service. Possible statuses are “AP” (accepted), “AJ”(pending), and “RE” (rejected). The confirmation status may be set atheader level only. Rejection at header level also signifies rejection ofthe items.

(2) The data in the ServiceAcknowledgementRequest 29806 is not changed.In addition to the confirmation status, a free text(ConfirmedDescription) may be entered at the header and item level asfurther explained below.

In one implementation, the ServiceAcknowledgementConfirmation 29808 isnot required to be sent in response to the ServiceAcknowledgementRequest29806 in the B2B service acknowledgement process.

In accordance with methods and systems consistent with the subjectmatter described herein, a service entry sheet is normally entered oncean ordered service has been provided. The seller 29802 then sends aServiceAcknowledgementRequest message 29806 requesting the buyer 29804to acknowledge this service, which begins the service acknowledgementprocess. Once the ServiceAcknowledgementRequest message 29806 has beenreceived by the buyer 29804, the buyer 29804 may use theServiceAcknowledgementConfirmation message 29808 to accept or reject theservice provided, or to assign it the temporary status “pending.” TheServiceAcknowledgement Confirmation 29808 is not a negotiation tool (asis the case with order management), since the entire service may beaccepted or rejected. The primary function of the ServiceAcknowledgementConfirmation message 29808 is to confirm that the serviceacknowledgement request has been sent correctly; providing informationabout required changes to the service acknowledgement is a secondaryfunction. The ServiceAcknowledgementConfirmation 29808, therefore,includes the data received and checked by the buyer 29804. When aServiceAcknowledgementRequest 29806 is rejected, however, the seller29802 may be informed about change requests in free texts at header anditem level in the ServiceAcknowledgementConfirmation message 29808. Ifthe buyer 29804 rejects a service acknowledgement, the seller 29802 maysend a new ServiceAcknowledgementRequest 29806. If the seller 29802 doesnot receive a response (e.g., another ServiceAcknowledgementConfirmationmessage 29808) from the buyer 29804, the service is considered to havebeen accepted.

The seller 29802 informs the interested applications of any system 29800about accepted service acknowledgements in the form of aServiceAcknowledgementInformation message 29810.

The ServiceAcknowledgement messages are implemented by the followingmessage interfaces. On the buyer's side, the ServiceAcknowledgementmessages are implemented by ServiceAcknowledgementRequest_In,ServiceAcknowledgementConfirmation_Out, andServiceAcknowledgementInformation_Out message interfaces. On theseller's side, the ServiceAcknowledgement messages are implemented byServiceAcknowledgementConfirmation_In andServiceAcknowledgementRequest_Out message interfaces. For applicationsthat are interested in the entry of the service, theServiceAcknowledgement message is implemented by theServiceAcknowledgementInformation_In message interface.

(2) Message Data Type Service Acknowledgement Information Message

The data model for the message data typeServiceAcknowledgementInformationMessage used to implement aServiceAcknowledgementRequest message 29806, aServiceAcknowledgementConfinnation message 29808, and aServiceAcknowledgementInformation message 29810 is depicted in FIG. 299.

The message data type ServiceAcknowledgementInformationMessage 29900groups the business information that is relevant for sending a businessdocument in a message. It includes a MessageHeader package 29902, aServiceAcknowledgement package 29904, and the objectServiceAcknowledgementInformationMessage 29906 in the view that isrequired for the ServiceAcknowledgementInformation. The message datatype ServiceAcknowledgementInformationMessage therefore provides thestructure for the message type ServiceAcknowledgementInformation and theinterface that is based on it. The message data typeServiceAcknowledgementInformationMessage is also the template messagedata type for the message data type ServiceAcknowledgementMessage andthe message types and interfaces that are based on it. TheServiceAcknowledgementMessage is derived as a structural view fromServiceAcknowledgementInformationMessage.

In one implementation, the following rules must be observed to ensurethat all the elements and entities in the message data typeServiceAcknowledgementMessage are used correctly with regard to theirchangeability in the acknowledgement process:

(1) In the ServiceAcknowledgementConfirmation, no data must be changedvis-à-vis the ServiceAcknowledgementRequest. Only the serviceacknowledgement status and a description of the buyer are specified inaddition.

(2) If certain elements or entities in the message data typeServiceAcknowledgementMessage are not to be used in all the messagetypes based on the message data type ServiceAcknowledgementMessage.

Methods and systems consistent with the subject matter described hereinuse the package template for a BusinessTransactionDocument for an SCMMaster Data depicted in FIG. 270B to derive theServiceAcknowledgementInformationMessage interface. There is a 1:crelationship between entities in this Interface unless otherwise notedherein or indicated in the Figures.

(a) Message Header Package

A MessageHeader package 29902 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader package 29902 includes a MessageHeader entity 29908. Thereis a 1:1 relationship between the ServiceAcknowledgementMessage entity29906 and the MessageHeader entity 29908.

A MessageHeader entity 29908 groups together business information fromthe perspective of the sending application to identify the businessdocument in a message, to provide information about the sender, and toprovide any information about the recipient. The MessageHeader entity29908 is of type GDT: BusinessDocumentMessageHeader. The MessageHeaderentity 29908 includes an ID, a ReferencedID, and a CreationDateTime. TheMessageHeader entity 29908 includes a SenderParty entity 29910 and aRecipientParty 29912. There is a 1:cn relationship between theMessageHeader entity 29908 and the RecipientParty entity 29912.

The SenderParty is the party responsible for sending a BusinessDocumentat the business application level. The SenderParty entity 29910 is oftype GDT: BusinessDocumentMessageHeaderParty. The SenderParty entity29910 may be filled by the sending application to name a contact personfor any problems with the message. This is particularly useful if anadditional infrastructure (such as a marketplace) is located between theSenderParty entity 29910 and the RecipientParty entity 29912. TheSenderParty entity 29910 is simply used to transfer the message and maybe ignored by the receiving application. In one implementation, it is tobe filled by the sender particularly if the participating partners arenot transferred with the ServiceAcknowledgement package 29904.

The RecipientParty is the party responsible for receiving a businessdocument at the business application level. The RecipientParty entity29912 is of type GDT: BusinessDocumentMessageHeaderParty. TheRecipientParty entity 29912 may be filled by the sending application toname a contact person for any problems with the message. The Recipiententity 29912 is simply used to transfer the message and can be ignoredby the receiving application. In one implementation, it is to be filledby the sender particularly if the participating partners are nottransferred with the ServiceAcknowledgement package 29904.

The SenderParty entity 29910 and the RecipientParty entity 29910 includeadditional information as denoted by ellipses 29914 and 29916,respectively.

In one implementation, the MessageHeader package 29902 is not needed andtherefore remains empty.

(b) Service Acknowledgement Package

The ServiceAcknowledgement package 29904 includes a Party package299220, a Location package 29922, an Attachment package 29924, aDescription package 29926, and an Item package 29928. TheServiceAcknowledgement package 29904 also includes aServiceAcknowledgement entity 29918. There is a 1:1 relationship betweenthe ServiceAcknowledgementInformationMessage entity 29906 and theServiceAcknowledgement entity 29918. The ServiceAcknowledgement in theview that is required for the ServiceAcknowledgementInformation messageis information about the purchaser's confirmation of an entered service.

In addition to the buyer and seller, other parties identified in theParty package 29920 may participate in the ServiceAcknowledgement. TheServiceAcknowledgement entity 29918 is of type GDT:ServiceAcknowledgementInformation and includes an ID, a BuyerID, aCreationDateTime, a CancellationServiceAcknowledgementIndicator, aAcceptanceStatusCode, and a Note. The ID is a unique identifier assignedby the seller for the service acknowledgement and is of type GDT:BusinessTransactionDocumentID. The BuyerID is a unique identifierassigned by the buyer for the service acknowledgement and is of typeGDT: BusinessTransactionDocumentID. The CreationDateTime is the time atwhich the seller created the service acknowledgement and is of type GDT:DateTime. The CancellationServiceAcknowledgementIndicator indicateswhether or not a service acknowledgement is a cancellation and is oftype GDT:ServiceAcknowledgementCancellationServiceAcknowledgementIndicator. TheAcceptanceStatusCode is the coded representation for the status of theseller's agreement to the service acknowledgement and is of type GDT:AcceptanceStatusCode. The Note is a short description or the title ofthe service acknowledgement. It is generally used to provide the userwith a simple method for searching for a particular serviceacknowledgement. The Note is of type GDT: Note.

(i) Service Acknowledgement Party Package

The Party package 29920 groups together the business parties involved inthe service acknowledgement. The Party package 29920 includes aBuyerParty entity 29930, a SellerParty entity 29932, aProductRecipientParty entity 29934, a VendorParty entity 29936, and aManufacturerParty entity 29938. There is a 1:1 relationship between theServiceAcknowledgement entity 29934 and the BuyerParty entity 29938.Each of the SellerParty entity 29932, the ProductRecipientParty entity29934, the VendorParty entity 29936, and the ManufacturerParty entity29938 includes the same elements as those described below for theBuyerParty entity 29930, as denoted by ellipses 29966, 29968, 29970, and29972.

Either the ID or the ID and address may be transferred for each party29930, 29932, 29934, 29936, and 29938. If the ID is transferred, the IDaddress defined in the master data is used. If the ID and address aretransferred, the ID identifies the party and the address is deemed to bea document address that is different to the master data address. For theparties 29930, 29932, 29934, 29936, and 29938, a default logic appliesfor transferring data from the document header to the items and withinitem hierarchies. Parties specified in the header are used for the itemsfor which a corresponding party is not explicitly transferred and thatare directly assigned to the header. In accordance with the same logic,parties transferred at item level are used for the subitems assigned tothe relevant item in an item hierarchy. The default logic applies forthe party as a whole, including the contact person. Parts of a partyspecified at header level or for a hierarchy item cannot be specified inmore detail at item level.

The BuyerParty is a party that buys goods or services. The BuyerPartyentity 29930 is of type GDT: BusinessTransactionParty. The BuyerPartyentity 29930 includes an Address entity 29940 and a ContactPerson entity29942.

The Address entity 29940 includes a PersonName entity 29944, an Officeentity 29946, a PhysicalAddress entity 29948, a GeoCoordinates entity29950, and a Communication entity 29952.

The ContactPerson entity 29942 includes an Address entity 29954. Similarto the Address entity 29940 in the BuyerParty 29930 discussed above, theAddress entity 29954 includes a PersonName entity 29956, an Officeentity 29958, a PhysicalAddress 29960, a GeoCoordinates entity 29962,and a Communication entity 29964.

The same BuyerParty entity 29930 may be used for theServiceAcknowledgement items. In one implementation, the Contact forBuyerParty entity 29930 is permitted to change from item to item anddifferent addresses in each item are not permitted.

The SellerParty is the party that sells goods or services. TheSellerParty entity 29932 is of type GDT: BusinessTransactionParty. Inone implementation, the same SellerParty entity 29932 is used for theservice acknowledgement items. A different SellerParty entity 29932 maybe used in each item. If a VendorParty entity 29936 is not explicitlyspecified in an ordering process, the SellerParty entity 29932 may alsobe used as the VendorParty entity 29936.

The ProductRecipientParty is a party to which goods are delivered or forwhom services are provided. The ProductRecipientParty entity 29934 is oftype GDT: BusinessTransactionDocumentParty. If a ShipToLocation is notexplicitly specified in a service acknowledgement process, theProductRecipientParty entity 29934 address is used as the ship-toaddress. The ProductRecipientParty is not synonymous with theShipToLocation and in one implementation is to be used when theProductRecipientParty (company or person) is actually different from theBuyerParty entity 29930.

The VendorParty is a party that delivers goods or provides services. TheVendorParty entity 29936 is of type GDT:BusinessTransactionDocumentParty.

The ManufacturerParty is a party that manufactures goods. TheManufacturerParty entity 29938 is of type GDT:BusinessTransactionDocumentParty. The ManufacturerParty entity 29938 maybe used for Material items. The ManufacturerParty entity 29938 may beused for uniquely defining the context of a ManufacturerProductID. Sincematerial items may also appear in this message, they may also bespecified in the message (although the messages are within the serviceprocess).

(ii) Service Acknowledgement Location Package

The Location package 29922 groups together the locations relevant forthe service acknowledgement. The Location package 29922 includes aShipToLocation entity 29972. The ShipToLocation entity 29972 is thelocation at which goods have been delivered or a service provided. TheShipToLocation entity 29972 is of type GDT:BusinessTransactionDocumentLocation.

The ShipToLocation entity 29972 includes an Address entity 29974. TheAddress entity 29974 includes a PersonName entity 29976, an Officeentity 29978, a PhysicalAddress 29980, a GeoCoordinates entity 29982,and a Communication entity 29984.

(iii) Service Acknowledgement Attachment Package

The Attachment package 29924 groups together the attachments relevantfor the service acknowledgement. The Attachment package 29928 includesan Attachment entity 29986. There is a 1:cn relationship between theServiceAcknowledgement entity 29918 and the Attachment entity 29986. TheAttachment entity 29986 is any document that refers to the serviceacknowledgement. The Attachment entity 29986 is of type GDT: Attachment.

(iv) Service Acknowledgement Description Package

The Description package 29926 groups together the texts relevant for theservice acknowledgement. The Description package 29926 includes aDescription entity 29988 and a ConfirmationDescription entity 29990.

The Description is a natural-language text regarding the serviceacknowledgement, which is visible to the business partner. TheDescription entity 29988 is of type GDT: Description. The Descriptionentity 29988 may be used for the textual information about thetransferred purchase order and not just the current message. An exampleof this is a note stating that the Purchasing employee responsible is onvacation as of a specific date and indicating the name and telephonenumber of a substitute as of this date.

The ConfirmationDescription is a natural-language text regarding theservice acknowledgement confirmation, which is visible to the businesspartner. The ConfirmationDescription entity 29990 is of type GDT:Description. The ConfirmationDescription entity 29990 may be used forthe textual information about the service acknowledgement confirmation.Reasons may be specified in the ConfirmationDescription entity 29990 asto why the entry has been rejected, for example.

(v) Service Acknowledgement Item Package

The Item package 29928 includes the Item entity 29992, aProductInformation package 29994, a PricingInformation package 29996, aParty package 29998, a Location package 29900A, aBusinessDocumentObjectReference package 29902A, an Attachment package29904A, and a Description package 29906A. There is a 1:n relationshipbetween the ServiceAcknowledgement entity 29918 and theServiceAcknowledgementItem entity 29992.

ServiceAcknowledgementItem entities are arranged hierarchically using aHierarchy Relationship 29910A. The Item Hierarchy Relationship 28810A isthe relationship between a sub-item and a higher-level parent item in anitem hierarchy. There is a 1:cn relationship between theServiceAcknowledgementItem entity 29992 and its subordinate entities.The ServiceAcknowledgementItem entity 29992 is of type GDT:ServiceAcknowledgementItem.

The ServiceAcknowledgementItem specifies a service (service product)entered by the ServiceAcknowledgement or additional information aboutthe service (service product). The ServiceAcknowledgementItem entity29992 includes detailed information about a product, the price of theproduct, quantity, and date. The ServiceAcknowledgementItem entity 29992may contain references to other business documents relevant for theitem. As described above, a Item ServiceAcknowledgementItem entity 29992may be subordinate to another ServiceAcknowledgementItem entity 29992within a hierarchy, thereby establishing a business relationship betweenthe two items.

The ServiceAcknowledgementItem entity 29992 includes an ID, a BuyerID, aServiceEntryCompletedIndicator, a DeliveryPeriod, and a Quantity. The IDis an identifier assigned by the seller to a service acknowledgementitem. The ID identifier is unique within a particular serviceacknowledgement and is of type GDT: BusinessTransactionDocumentItemID.The BuyerID is an identifier assigned by the buyer to a serviceacknowledgement item. The BuyerID identifier is unique within aparticular service acknowledgement and is of type GDT:BusinessTransactionDocumentItemID. The ServiceEntryCompletedIndicatorspecifies whether or not confirmation for the referenced serviceacknowledgement item is complete and is of type GDT:BusinessTransactionCompletedIndicator. The DeliveryPeriod is a periodfor which the service was entered and is of type GDT: DateTimePeriod.The Quantity is the quantity entered and is of type GDT: Quantity.

ServiceAcknowledgementItem entities 29992 are arranged hierarchicallyusing a HierarchyRelationship 29910A. There are various item categories,which are governed by a variety of constraints. AServiceAcknowledgementItem entity 29992 may have several constrainttypes. The description of the constraint types specifies whichconstraint types may be combined with each other and how.

Methods and systems consistent with the subject matter described hereincontemplate the following constraint types: (1) Standard items; (2)Hierarchy items; (3) Subitems; (4) Material items; (5) Service items;(6) Unspecified product items; (7) Grouping hierarchy items; and (8) BOMhierarchy items.

Standard items are the items to which no lower-level items have beenassigned in the hierarchy. An item that is not referenced by theParentItemID of another item is a standard item.

Hierarchy items are items to which at least one other lower-level itemhas been assigned in the hierarchy. An item that is referenced by theParentItemID of at least one other item is a hierarchy item. The itemsare either standard or hierarchy items.

Subitems are items that have been assigned below a hierarchy item andnot directly to the purchase order header. Subitems may be both standarditems and hierarchy items. Each item that references another item by theParentItemID is a subitem.

Material items are items whose product is a material. Items whoseProductTypeCode is “1” (Material) are Material items.

Service items are items whose product is a service. Items whoseProductTypeCode is “2” (service) are service items.

Unspecified product items are items for which it is not specifiedwhether they refer to a material or a service. Items whoseProductTypeCode is not specified are unspecified product items. Theitems are either material, service, or unspecified product items. Anunspecified product item fulfills the constraints of a material orservice.

Grouping hierarchy items are hierarchy items that logically grouptogether other items. Multilevel grouping hierarchies are permitted,that is, a grouping hierarchy item may contain subitems that are alsogrouping hierarchy items. Hierarchy items whose subitems haveHierarchyRelationshipTypeCode “002” (group) are grouping hierarchyitems; subitems with a different HierarchyRelationshipTypeCode are notpermitted. Grouping hierarchy items are not permitted as subitems ofother types of hierarchy items.

BOM hierarchy items are hierarchy items that group together other itemsin a BOM. Multilevel BOM hierarchies are permitted. Hierarchy items withat least one subitem with HierarchyRelationshipTypeCode “001” (BOM) areBOM hierarchy items; other subitems are permitted withHierarchyRelationshipTypeCode “003” (discount in kind).

(a) Hierarchy Relationship

The HierarchyRelationship 29910A is the relationship between a subitemand a higher-level parent item in an item hierarchy. TheHierarchyRelationship 29910A includes a ParentItemID, aParentItemBuyerID, and a TypeCode. The ParentItemID is the reference toa parent item with the item number assigned by the seller, and is oftype GDT: BusinessTransactionDocumentItemID. The ParentItemBuyerID isthe reference to a parent item with the item number assigned by thebuyer, and is of type GDT: BusinessTransactionDocumentItemID. TheTypeCode represents the hierarchical relationship between the subitemand its higher-level parent item, and is of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode.

(b) Service Acknowledgement Item Product Information Package

The ProductInformation package 29994 groups together the informationrequired for identifying, describing, and classifying a product orservice acknowledgement item. The ProductInformation package 29994includes a Product entity 29912A and a ProductCategory entity 29914A. Inone implementation, the ProductInformation package 29994 is not used ingrouping hierarchy items.

The Product entity 29912A includes the details about a product asgenerally understood from a commercial point of view in businessdocuments. The Product entity 29912A is of type GDT:BusinessTransactionDocumentProduct. With the exception of groupinghierarchy items, at least the product number or the product descriptionis specified when a new item is created. If both the product number anddescription are specified, the description is merely additionalinformation in the message and may be ignored by the recipient.

The ProductCategory entity 29914A includes the details about a productcategory as generally understood from a commercial point of view inbusiness transaction documents. The ProductCategory entity 29914Aincludes details for identifying the product category using an internalID, a standard ID, and IDs assigned by involved parties. TheProductCategory entity 29914A is of type GDT:BusinessTransactionDocumentProductCategory. The product category isderived directly from the product if a product number is specified forthe product. It may differ for the buyer and seller if they haveclassified the same product differently.

(c) Service Acknowledgement Item

Price Information Package The PriceInformation package 29996 groupstogether the price information for a service acknowledgement item. ThePriceInformation package 29996 includes a Price entity 29916A. ThePriceInformation package 29916A is not used in the grouping hierarchy.In one implementation, the PriceInformation package 29996 for a serviceitem includes prices only; it does not contain any information about howthe prices are calculated.

The Price entity 29916A is the price specified by the seller for theservice provided or material used. The Price entity 29916A includes aNetUnitPrice, which is the net price (without tax or cash discount)specified by the seller for the base quantity of the service ormaterial, and is of type GDT: Price.

In BOM hierarchies, the following rules may apply for the Price:

(1) If the price is specified for the item at the top of the BOMhierarchy and not the subitems, this price applies.

(2) If the price is specified for standard items (end nodes in thehierarchy tree) in the BOM hierarchy, these prices apply. The price ofthe entire BOM is the total of the individual prices.

(3) If a price is specified at different levels in the BOM hierarchy,the price that appears above the others in the tree applies. Differencesbetween the total of the individual prices and the price at the nexthighest hierarchy level are permissible. These may be caused bydiscounts for the entire BOM.

(d) Service Acknowledgement Item Party Package

The SeviceAcknowledgementItem Party package 29998 includes elementssimilar at header level to the ServiceAcknowledgement Party package29920, such as a BuyerParty entity 29918A, a SellerParty entity 29920A,a ProductRecipientParty entity 29922A, a VendorParty entity 29924A, anda ManufacturerParty entity 29926A.

Each of the BuyerParty entity 29918A, the SellerParty entity 29920A, theProductRecipientParty entity 29922A, the VendorParty entity 29924A, andthe ManufacturerParty entity 29926A of Party package 29998 includes thesame elements as those described above for the BuyerParty entity 29930of Party package 29920, as denoted by ellipses 29928A, 29930A, 29932A,29934A, and 29936A in Party package 29998.

(e) Service Acknowledgement Item Location Package

The SeviceAcknowledgementItem Location package 29900A includes elementssimilar at header level to the ServiceAcknowledgement Location package29922, such as a ShipToLocation entity 29938A. The ShipToLocation entity29938A is of type GDT: BusinessTransactionDocumentLocation.ShipToLocation entity 29938A of Location package 29900A includes thesame elements as those described above for the ShipToLocation entity29922 of Location package 29922 as denoted by ellipse 29924B in Locationpackage 29900A.

(f) Service Acknowledgement Item Business Document Object ReferencePackage

The ServiceAcknowledgementItemBusinessDocumentObjectReference package(“BusinessDocumentObjectReference package”) 29902A groups togetherreferences to business documents that are relevant for theServiceAcknowledgementItem entity 29992 and have a business relationshipwith the item. The BusinessDocumentObjectReference package 29902Aincludes a PurchaseOrderReference entity 29942A, anOriginServiceAcknowledgementReference entity 29944A, aPurchaseContractReference entity 29946A, a SalesContractReference entity29948A, a BuyerProductCatalogueReference entity 29950A, aSellerProductCatalogueReference entity 29952A, a ProjectReference entity29954A, and a ProjectElementAssignment entity 29956A. In oneimplementation, none of the entities in theBusinessDocumentObjectReference package may be used in groupinghierarchy items.

The PurchaseOrderReference entity 29942A is a reference to a purchaseorder or item in a purchase order. The PurchaseOrderReference entity29942A is of type GDT: BusinessTransactionDocumentReference. In oneimplementation, the PurchaseOrderReference entity 29926B references oneitem such that one ItemID is required.

The OriginServiceAcknowledgementReferenceentity 29944A is the referenceto a service acknowledgement that was sent previously. TheOriginServiceAcknowledgementReference entity 29944A is of type GDT:BusinessTransactionDocumentReference. In one implementation, thecontraints on the message data type is that anOriginServiceAcknowledgementReference can reference one item only;therefore, no more than one ItemID is permissible.

The PurchaseContractReference entity 29946A is a reference to a purchasecontract or item in a purchase contract. The PurchaseContractReferenceentity 29946A is of type GDT: BusinessTransactionDocumentReference. Inone implementation, the PurchaseContractReference entity 29946Areferences one item such that one ItemID is required. Provided it hasnot been agreed otherwise, the seller is responsible for determining thecorrect SalesContractReference entity 29948A for a specifiedPurchaseContractReference entity 29946A.

The SalesContractReference entity 29946A is a reference to a salescontract or an item within a sales contract. The SalesContractReferenceentity 29946A is of type GDT: BusinessTransactionDocumentReference. Inone implementation, the SalesContractReference entity 29930B referencesone item such that one ItemID is required.

The BuyerProductCatalogueReference entity 29950A is a reference to thebuyer's product catalog or an item within the buyer's product catalog.The BuyerProductCatalogueReference entity 29950A is of type GDT:CatalogueReference. In one implementation, theBuyerProductCatalogueReference entity 29950A references one item suchthat one ItemID is required. The BuyerProductCatalogueReference entity29950A is filled when a service acknowledgement item refers to a catalogwhose number and item numbers were assigned by the buyer. In the serviceacknowledgement process, the BuyerProductCatalogueReference entity29950A may be used as a substitute product number if a separate masterrecord has not been created for a product and the product is defined ina catalog.

The SellerProductCatalogueReference entity 29952A is a reference to theseller's product catalog or an item within the seller's product catalog.The SellerProductCatalogueReference entity 29952A is of type GDT:CatalogueReference. The SellerProductCatalogueReference entity 29952Areferences one item such that one ItemID is required. TheSellerProductCatalogueReference entity 29952A is filled when a serviceacknowledgement item refers to a catalog whose number and item numberswere assigned by the seller. In the service acknowledgement process, theSellerProductCatalogueReference entity 29952A may be used as asubstitute product number if a separate master record has not beencreated for a product and the product is defined in a catalog.

The ProjectReference entity 29954A is a unique reference to a project oran element within project. The ProjectReference entity 29954A is of typeGDT: ProjectReference. In one implementation, the ProjectReferenceentity 29954A is not used in the ServiceAcknowledgementMessage.

The ProjectElementAssignment entity 29956A is the assignment of twoelements within a project that is referred to by an item of the serviceacknowledgement. The ProjectElementAssignment entity 29956A is of typeGDT: ProjectElementAssignment. In one implementation, theProjectElementAssignment entity 29956A is not used in theInvoiceMessage. In one implementation, either a ProjectReference entity29954A or a ProjectElementAssignment 29956A may be specified. In thiscase, only one role (e.g., ProjectElementTypeCodes=“2”) may be assignedto a task (e.g., ProjectElementTypeCodes=“1”). TheProjectElementAssignment entity 29956A is passed along a purchasingprocess through to the goods receipt, service entry, and invoicing, sothat a project system can always be informed about the ongoingdevelopment of the request.

(g) Service Acknowledgement Item Accounting Package

The ServiceAcknowledgementItemAccountingObjectSetAssignment package29904A groups the account assignment information that is needed forfinancial accounting. It contains the AccountingObjectSetAssignmententity 29958A. TheServiceAcknowledgementItemAccountingObjectSetAssignment package 29904Acontains all information about the account assignment objects infinancial accounting that the service acknowledgement item refers to.The amount can be distributed by percentages and assigned to differentobjects (such as cost center, order, and so on). The sum of all accountassignments must equal 100%.

The AccountingObjectSetAssignment entity 29958A is the assignment of anitem net amount from a service acknowledgement or of partial amounts(based on percentage, value, or quantity) to a set of account assignmentobjects (AccountingObjectSet). The AccountingObjectSetAssignment entity29958A is of type GDT: AccountingObjectSetAssignment. There is a 1:cnrelationship between the AccountingObjectSetAssignment entity 29958A andthe ServiceAcknowledgementItem entity 29992. In one implementation, theAccountingObjectSetAssignment is not used in theServiceAcknowledgementMessage. For example, 40% of the item amount of aservice acknowledgement can be assigned to cost center CC1000 and profitcenter PC3050, while 60% of the item amount is assigned to customerorder 100002345.

(h) Service Acknowledgement Item AttachmentPackage

The SeviceAcknowledgementItemAttachment package 29960A includes elementssimilar at header level to the ServiceAcknowledgementAttachment package29924, such as an Attachment entity 29960A. There is a 1:cn relationshipbetween the Attachment entity 29960A and the ServiceAcknowledgementItementity 29992. The Attachment entity 29960A is of type GDT:BusinessTransactionDocumentLocation.

(i) Service Acknowledgement Item Description Package

The Description package 29908A groups together the explanatory textsregarding a service acknowledgement item. The Description package 29908Aincludes a Description entity 299562A and a ConfirmationDescriptionentity 29964A.

The Description entity 29962Ais a natural-language text regarding aservice acknowledgement that may be visible to the business partner. TheDescription entity 29962A is of type GDT: Description. The Descriptionmay be used for the types of textual information about the serviceacknowledgement item. An example is an accurate description of a faultin need of repair.

The ConfirmationDescription entity 29964A is a natural-language textregarding the confirmation of a service acknowledgement item that may bevisible to the business partner. The ConfirmationDescription entity29964A is of type GDT: Description. The ConfirmationDescription entity29964A may be used for the textual information about the confirmation ofa service acknowledgement item. An example of this would be the seller'sjustification for rejecting a particular service acknowledgement item.

(3) Message Data Type Element Structure

FIGS. 300A-L depict the element structure for aSeviceAcknowledgementRequest and a ServiceAcknowledgementConfirmation.The element structure is similar to the above described data model ofthe message data type ServiceAcknowledgementMessage as reflected inFIGS. 299A-J, but provides additional information regarding the detailsfor interfacing with or implementing a ServiceAcknowledgementMessage,such as a SeviceAcknowledgementRequest and aServiceAcknowledgementConfirmation. As shown in FIGS. 300A-L, theelement structure identifies the different packages 30000 that may be ina respective ServiceAcknowlegementRequest andServiceAcknowledgementConfirmation. The element structure for theServiceAcknowlegementRequest and ServiceAcknowledgementConfirmationincludes five levels 30002, 30004, 30006, 30008 and 30010 each ofassociated with a respective package 30000. The element structureidentifies the cardinality 30012 and data type information (i.e., type30014 and name 30016) for the elements at the respective levels 30002,30004, 30006, 30008 and 30010 in a package 30000.

The outermost package of this interface is a ServiceAcknowledgementpackage 30020, which includes a ServiceAcknowledgementMessage entity30022 at the first level 30002. The ServiceAcknowledgementMessage entity30022 is of message data type (“MDT”) 30024ServiceAcknowledgementMessage 30026.

The ServiceAcknowledgementMessage package 30020 includes a MessageHeaderpackage 30028 and a ServiceAcknowledgement package 30030. TheMessageHeader package 30028 includes a MessageHeader entity 30032, whichis of type generic data type (“AGDT”) 30036“BusinessDocumentMessageHeader” 30038. There is one 30034 MessageHeaderentity for each ServiceAcknowledgementMessage entity 30022.

The MessageHeader entity 30032 includes an ID 30040, a Reference ID30048, and a CreationDateTime 30056. The ID 30040 is of type GDT 30044BusinessDocumentMessageID 30046. The ReferenceID 30048 is of type GDT30052 BusinessDocumentMessageID 30054. The CreationDateTime 30056 is oftype GDT 30060 DateTime 30062. There is one 30042 ID 30040 for eachMessageHeader entity 30032, one or zero 30050 ReferenceID 30052 for eachMessageHeader entity 30032, and one 30058 CreationDateTime 30056 foreach MessageHeader entity 30032.

The MessageHeader entity 30032 also includes a SenderParty entity 30064and a RecipientParty entity 30020A. The SenderParty entity 30064 is oftype AGDT 30068 BusinessDocumentMessageHeaderParty 30070. TheRecipientParty entity 30020A is also of type AGDT 30024ABusinessDocumentMessageHeaderParty 30026A. There is one or zero 30066SenderParty entity 30064 for each MessageHeader entity 30032, and thereis any number 30022A of RecipientParty entities 30020A for eachMessageHeader entity 30032.

The SenderParty entity 30064 includes an InternalID 30072, a StandardID30080, and a ContactPerson 30088. The InternalID 30072 is of type GDT30076 PartyInternalID 30078. The StandardID 30080 is of type GDT 30084PartyStandardlID 30086. The ContactPerston 30088 is of type AGDT 30092ContactPerson 30094. There is one or zero 30074 InternalID 30072 foreach SenderParty entity 30064, any number 30082 of StandardIDs 30080 foreach SenderParty entity 30064, and one or zero 30090 ContactPerson 30088for each SenderParty entity 30064.

The ContactPerson 30088 includes a BuyerID 30096, a VendorID 30004A, andan Address 30012A. The BuyerID 30096 is of type CDT 30000AContactPersonPartyID 30002A. The VendorID 30004A is of type CDT 30006AContactPersonPartyID 30010A. The Address 30012A is of type AGDT 30016AAddress 30018A. There is one or zero 30098 BuyerID 30096 for eachContactPerson 30088, one or zero 30006A of VendorID 30004A for eachContactPerson 30088, and one or zero 30014A Address 30012A for eachContactPerson 30088.

The ServiceAcknowledgement package 30030 includes aServiceAcknowledgement entity 30028A. There is one 30030AServiceAcknowledgement entity 30028A for eachServiceAcknowledgementMessage entity 30022A. The ServiceAcknowledgemententity 30028A is of type AGDT 30032A ServiceAcknowledgement 30034A. TheServiceAcknowledgement entity 30028A includes an ID 30036A, a BuyerID30046A, a CreationDateTime 30054A, aCancellationServiceAcknowledgementIndicator 30051A, anAcceptanceStatusCode 30064A, and a Note 30074A. The ID 30036A is of typeGDT 30040A BusinessTransactionDocumentID 30042. The BuyerID 30046A is oftype GDT 30050A BusinessTransactionDocumentID 30052A. TheCreationDateTime 30054A is of type GDT 30058A DateTime 30060A. TheCancellationServiceAcknowledgementIndicator 30051A is of type GDT 30055ACancellationServiceAcknowledgementIndicator 30057A. TheAcceptanceStatusCode 30064A is of type GDT 30068A AcceptanceStatusCode30070A. The Note 30074A is of type GDT 30078A Note 30080A. There is one30038A ID 30036A for each ServiceAcknowledgement entity 30028A. There isone or zero 30048A BuyerID 30046A for each ServiceAcknowledgement entity30028A. There is zero or one 30056A CreationDateTime 30054A for eachServiceAcknowledgement entity 30028A. There is zero or one 30053ACancellationServiceAcknowledgementIndicator 30057A for eachServiceAcknowledgement entity 30028A. There is zero or one 30066AAcceptanceStatusCode 30064A for each ServiceAcknowledgement entity30028A. There is one or zero 30076A Note 30074A for eachServiceAcknowledgement entity 30028A. ID 30036A may be associated withPIDX element FieldTicketProperties-FieldTicketNumber 30044A.CreationDateTime 30054A may be associated with PIDX elementFieldTicketProperties-FieldTicketDate 30062A. AcceptanceStatusCode30064A may be associated with PIDX elementFieldTicketResponseLineItem-LineStatusCode 30072A.

The ServiceAcknowledgement package 30030 also includes a Party package30082A, a Location package 30084A, an Attachment package 30086A, aDescription package 30088A, and an Item package 30090A.

The Party package 30082A includes a BuyerParty entity 30092A, aSellerParty entity 30066B, a ProductRecipientParty entity 30076B, aVendorParty entity 30086B, and a ManufacturerParty entity 30096B. TheBuyerParty entity 30092A is of type AGDT 30096ABusinessTransactionDocumentParty 30098A. There is one or zero 30094ABuyerParty entity 30092A for each ServiceAcknowledgement entity 30028A.The SellerParty entity 30066B is of type AGDT 30070BBusinessTransactionDocumentParty 30072B. There is one or zero 30068BSellerParty entity 30066B for each ServiceAcknowledgement entity 30028A.The ProductRecipientParty entity 30076B is of type AGDT 30080BBusinessTransactionDocumentParty 30082B. There is one or zero 30078BProductRecipientParty entity 30076B for each ServiceAcknowledgemententity 30028A. The VendorParty entity 30086B is of type AGDT 30090BBusinessTransactionDocumentParty 30092B. There is one or zero 30088BVendorParty entity 30086B for each ServiceAcknowledgement entity 30028A.The ManufacturerParty entity 30096B is of type AGDT 30000CBusinessTransactionDocumentParty 30002C. There is one or zero 30098BManufacturerParty entity 30096B for each ServiceAcknowledgement entity30028A. BuyerParty 30092A may be associated with PIDX elementPartnerInformation (all Parties) 30000B. SellerParty 30066B may beassociated with PIDX element PartnerInformation 30074B.ProductRecipientParty 30076B may be associated with PIDX elementPartnerInformation 30084B. VendorParty 30086B may be associated withPIDX element PartnerInformation and CountryOfOrigin 30094B.ManufacturerParty 30096B may be associated with PIDX elementPartnerInformation 30004C.

The BuyerParty entity 30092A includes a StandardID entity 30002B, aBuyerID entity 30010B, a SellerID entity 30018D, an Address entity30026B and a ContractPerson entity 30034B. The StandardID entity 30002Bis of type CDT 30006B PartyStandardID 30008D. The BuyerID entity 30010Bis of type CDT 30014B PartyPartyID 30008D. The SellerID entity 30018D isof type CDT 30022B PartyPartyID 30024B. The Address entity 30026B is oftype AGDT 30030B Address 30032B. The ContactPerston entity 30034B is oftype AGDT 30038B ContractPerson 30040B. There is any number 30004B ofStandardID entities 30002B for each BuyerParty entity 30092A, one orzero 30012B BuyerID entity 30010B for each BuyerParty entity 30092A, oneor zero 30020B SellerID entity 30018B for each BuyerParty entity 30092A,one or zero 30028B Address entity 30026B for each BuyerParty entity30092A, and one or zero 30036B ContractPerson entity 30034B for eachBuyerParty entity 30092A.

The ContractPerson entity 30034B includes a BuyerID entity 30042B, aSellerID entity 30050B, and an Address entity 30058B. The BuyerID entity30042B is of type CDT 30046B ContactPersonPartyID 30048B. The SellerIDentity 30050B is of type CDT 30054B ContactPersonPartyID 30056B. TheAddress entity 30058B is of type AGDT 30062B Address 30064B. There isone or zero 30044B BuyerID entity 30042B for each ContractPerson entity30034A, one or zero 30052B SellerID entity 30050B for eachContractPerson entity 30034B, and one or zero 30060B Address entity30058B for each ContractPerson entity 30034B.

The Location Package 30084A includes a ShipToLocation entity 30006C. TheShipToLocation entity 30006C is of type AGDT 30010CBusinessTransactionDocumentLocation 30012C. There is one or zero 30008CShipToLocation entity 30006C for each ServiceAcknowledgement entity30028A.

The ShipToLocation entity 30006C includes a StandardID entity 30016C, aBuyerID entity 30024C, a SellerID entity 30032C, and an Address entity30040C. The StandardID entity 30016C is of type CDT 30020CLocationStandardID 30022C. The BuyerID entity 30024C is of type CDT30028C LocationPartyID 30030C. The SellerID entity 30032C is of type CDT30036C LocationPartyID 30038C. The Address entity 30040C is of type AGDT30044C Address 30046C. There is any number 30018C of StandardID entities30016C for each ShipToLocation entity 30006C, one or zero 30026C BuyerIDentity 30024C for each ShipToLocation entity 30006C, one or zero 30034CSellerID entity 30032C for each ShipToLocation entity 30006C, and one orzero 30042C Address entities 30040C for each ShipToLocation entity30006C. ShipToLocation 30006C may be associated with PIDX elementCountryOfFinalDestination 30014C.

The Attachment package 30086A includes an Attachment entity 30048C,which is of type AGDT 30052C Attachment 30054C. There is any number30050C of Attachment entities 30048C for each ServiceAcknowledgemententity 30028A. Attachment 30048C may be associated with PIDX elementFieldTicketProperties-Attachment 30056C.

The Description package 30088A includes a Description entity 30058C anda ConfirmedDescription entity 30068C. The Description entity 30058C isof type GDT 30062C Description 30064C. There is one or zero 30060CDescription entity 30058C for each ServiceAcknowledgement entity 30028A.The ConfirmedDescription entity 30068C is of type GDT 30072C Description30074C. There is one or zero 30070C ConfirmedDescription entity 30068Cfor each ServiceAcknowledgement entity 30028A. Description 30058C may beassociated with PIDX element FieldTicketProperties-Comment and-JobSummary 30066C.

The Item package 30090A includes an Item entity 30076C. There is one ormore 28060C Item entities 28058C for each ServiceAcknowledgement entity30028A. The Item entity 30076C is of type AGDT 30080CServiceAcknowledgementItem 30082C.

The Item entity 30076C includes an ID 30084C, a BuyerID 30094C, aServiceEntryCompletedIndicator 30002D, a DeliveryPeriod 30010D, aQuantity 30020D, and a HierarchyRelationship 30030D. The ID 30084C is oftype GDT 30088C BusinessTransactionDocumentItemID 30090C, and there isone 30086C ID 30084C for each Item entity 30076C. The BuyerID 30094C isof type GDT 30098C BusinessTransactionDocumentItemPartyID 30000D, andthere is one or zero 30096C BuyerID 30094C for each Item entity 30076C.The ServiceEntryCompletedIndicator 30002D is of type GDT 30006DBusinessTransactionCompletedIndicator 30008D, and there is one or zero30004D ServiceEntryCompletedIndicators 30002D for each Item entity30076C. The DeliveryPeriod entity 30010D is of type GDT 30014DDateTimePeriod 30016D, and there is one or zero 30012D DeliveryPeriodentity 30010D for each Item entity 30076C. The Quantity 30020D is oftype GDT 30024D Quantity 30026D, and there is one or zero 30022DQuantity 30026D for each Item entity 30076C. There is one or zero 30032DHierarchyRelationship 30030D for each Item entity 30076C. TheHierarchyRelationship 30030D includes a ParentItemID 30036D, which is oftype GDT 30040D BusinessTransactionDocumentItemID 30042D, aParentItemBuyerID 30044D, which is of type GDT 30048DBusinessTransactionDocumentItemID 30050D, and a TypeCode 30052D, whichis of type GDT 30056DBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 30058D.There is one or zero 30038D ParentItemID 30036D for eachHierarchyRelationship 30030D. There is one or zero 30046DParentItemBuyerID 30044C for each HierarchyRelationship 30030D. There isone 30054D TypeCode 30052D for each HierarchyRelationship 30030D. ID30084C may be associated with PIDX elementFieldTicketLineItem-LineItemNumber 30092C. DeliveryPeriod 30010D may beassociated with PIDX element FieldTicketLineItem-ServiceDateTime 30018D.Quantity 30020D may be associated with PIDX elementFieldTicketProperties-FieldTicketQuantity 30028D. HierarchyRelationship30030D may be associated with PIDX element FieldTicketSubLineItem30034D.

The Item package 30090A also includes a ProductInformation package30060D, a PriceInformation package 30062D, a Party package 30064D, aLocation package 30066D, a BusinessTransactionDocumentReference package30068D, an Attachment package 30070D and a Description package 30072D.

The ProductInformation package 30060D includes a Product entity 30074Dand a ProductCategory entity 30032E. The Product entity 30074D is oftype AGDT 30078D BusinessTransactionDocumentProduct 30080D. There is oneor zero 30076D Product entity 30074D for each Item entity 30076C. TheProductCategory entity 30032E is of type AGDT 30036EBusinessTransactionDocumentProductCategory 30038E. There is one or zero30034E ProductCategory entity 30032E for each Item entity 30076C.

The Product entity 30074D includes a StandardID entity 30084D, a BuyerIDentity 30092D, a SellerID entity 30000E, a ManufacturerID 30008E, aTypeCode entity 30016E and a Note entity 30024E. The StandardID entity30084D is of type CDT 30088D ProductStandardID 30090D. The BuyerIDentity 30092D is of type CDT 30096D ProductPartyID 30098D. The SellerIDentity 30000E is of type CDT 30004E ProductPartyID 30006E. TheManufacturerID entity 30008E is of type CDT 30012E ProductPartyID30014E. The TypeCode entity 30016E is of type GDT 30020E ProductTypeCode30022E. The Note entity 30024E is of type GDT 30028E Note 30030E. Thereis any number 30086D of StandardID entities 30084D for each Productentity 30074D, one or zero 30094D BuyerID entity 30092D for each Productentity 30074D, one or zero 30002E SellerID entity 30000E for eachProduct entity 30074D, one or zero 30010E The ManufacturerID entity30008E for each Product entity 30074D, one or zero 30018E TypeCodeentity 30016E for each Product entity 30074D and one or zero 30026E Noteentity 30024E for each Product entity 30074D.

The ProductCategory entity 30032E includes a StandardID entity 30040E, aBuyerID entity 30048E, and a SellerID entity 30056E. The StandardIDentity 30040E is of type CDT 30044E ProductCategoryStandardID 30046E.The BuyerID entity 30048E is of type CDT 30052E ProductCategoryPartyID30054E. The SellerID entity 30056E is of type CDT 30060EProductCategoryPartyID 30062E. There is any number 30042E of StandardIDentities 30040E for each ProductCategory entity 30032E, one or zero30050E BuyerID entity 30048E for each ProductCategory entity 30032E, andone or zero 30058E SellerID entity 30056E for each ProductCategoryentity 30032E. Product 30074D may be associated with PIDX elementFieldTicketProperties-LineItemInformation 30082D.

The PriceInformation package 30062D includes a Price entity 30064E.There is one or zero 30066E Price entity 30064E for each Item entity30076C. The Price entity 30064E includes a NetUnitPrice 30070E. TheNetUnitPrice 30070E is of type AGDT 30074E Price 30076E. There is one orzero 30072E NetUnitPrice 30070E for each Price entity 30064E. Price30064E may be associated with PIDX element FieldTicketLineItem-Pricing30068E. NetUnitPrice 30070E may be associated with PIDX elementPrimaryCurrency 30078E. The Price entity 30064E includes a NetAmount30071E. The NetAmount 30071E is of type GDT 30075E Amount 30077E. Thereis one or zero 30073E NetAmount 30071E for each Price entity 30064E.

The Party package 30064D includes a BuyerParty entity 30080E, aSellerParty entity 30090E, a ProductRecipientParty entity 30000F, aVendorParty entity 30010F, and a ManufacturerParty entity 30020F. TheBuyerParty entity 30080E is of type AGDT 30084EBusinessTransactionDocumentParty 30086E. There is one or zero 30082EBuyerParty entity 30080E for each Item entity 30076C. The SellerPartyentity 30090E is of type AGDT 30094E BusinessTransactionDocumentParty30096E. There is one or zero 30092E SellerParty entity 30090E for eachItem entity 30076C. The ProductRecipientParty entity 30000F is of typeAGDT 30004F BusinessTransactionDocumentParty 30006F. There is one orzero 30002F ProductRecipientParty entity 30000F for each Item entity30076C. The VendorParty entity 30010F is of type AGDT 30014FBusinessTransactionDocumentParty 30016F. There is one or zero 30012FVendorParty entity 30010F for each Item entity 30076C. TheManufacturerParty entity 30020F is of type AGDT 30024FBusinessTransactionDocumentParty 30026F. There is one or zero 30022FManufacturerParty entity 30020F for each Item entity 30076C. BuyerParty30080E may be associated with PIDX element PartnerInformation 30088E.SellerParty 30090E may be associated with PIDX elementPartnerInformation 30098E. ProductRecipientParty 30000F may beassociated with PIDX element PartnerInformation 30008F. VendorParty30010F may be associated with PIDX element PartnerInformation andCountryOfOrigin 30018F. ManufacturerParty 30020F may be associated withPIDX element PartnerInformation 30028F.

The Location package 30066D includes a ShipToLocation entity 30030F. TheShipToLocation entity 30030F is of type AGDT 30034FBusinessTransactionDocumentLocation 30036F, and there is one or zero30032F ShipToLocation entity 30030F for each Item entity 30076C.

The BusinessTransactionDocumentReference package 30068D includes aPurchaseOrderReference entity 30038F, aOriginServiceAcknowledgementReference 30061F, aPurchaseContractReference entity 30048F, a SalesContractReference entity30058F, a BuyerProductCatalogueReference entity 30066F, and aSellerProductCatalogueReference entity 30074F. ThePurchaseOrderReference entity 30038F is of type AGDT 30042FBusinessTransactionDocumentReference 30044F. There one or zero 30040F ofPurchaseOrderReference entities 30038F for each Item entity 30076C. ThePurchaseContractReference entity 30048F is of type AGDT 30052FBusinessTransactionDocumentReference 30054F. There is one or zero 30050FPurchaseContractReference entity 30048F for each Item entity 30076C. TheOriginServiceAcknowledgementReference 30061F is of type GDT 30065FBusinessTransactionDocumentReference 30067F. There is one or zero 30063FOriginServiceAcknowledgementReference 30061F for each Item entity30076C. The SalesContractReference entity 30058F is of type AGDT 30062FBusinessTransactionDocumentReference 30064F. There is one or zero 30060FSalesContractReference entity 30058F for each Item entity 30076C. TheBuyerProductCatalogueReference entity 30066F is of type AGDT 30070FCatalogueReference 30072F. There is one or zero 30068FBuyerProductCatalogueReference entity 30066F for each Item entity30076C. The SellerProductCatalogueReference entity 30074F is of typeAGDT 30078F CatalogueReference 30080F. There is one or zero 30076FSellerProductCatalogueReference entity 30074F for each Item entity30076C. PurchaseOrderReference 30028F may be associated with PIDXelement FieldTicketLineItem-PurchaseOrderInformation 30046F.PurchaseContractReference 30048F may be associated with PIDX elementFieldTicketLineItem-ReferenceInformation 30056F.

The Accounting package 30071D includes an AccountingObjectSetAssignment30083FF, which is of type GDT 30087F AccountingObjectSet 30089F. Thereis one or zero 30085F AccountingObjectSetAssignment 30083FF for eachItem entity 30076C.

The Attachment package 30070D includes an Attachment entity 30082F,which is of type AGDT 30086F Attachment 30088F. There is one or zero30084F Attachment entities 30082F for each Item entity 30076C.Attachment 30082F may be associated with PIDX elementFieldTicketLineItem-Attachment 30090F.

The Description package 30072D includes a Description entity 30092F anda ConfirmedDescription entity 30002G. The Description entity 30092F isof type GDT 30096F Description 30098F. There is one or zero 30094FDescription entity 30092F for each Item entity 30076C. TheConfirmedDescription entity 30002G is of type GDT 30006G Description30008G. There is one or zero 30004G ConfirmedDescription entity 30002Gfor each Item entity 30076C. Description 30092F may be associated withPIDX element FieldTicketLineItem-Comment and -JobSummary 30000G.

e) RFQ, RFQ Cancellation, RFQ Result, Quote Interfaces

Request for quotation (“RFQ”) interfaces are the interfaces that arerequired in a B2B process to exchange RFQs and quotations between abuyer and a bidder and finally to communicate the quotation acceptance.More than just a simple interface structure, the RFQ interfaces definethe underlying business logic and, at the same time, dispense with theneed to exchange proprietary information in straightforward RFQprocesses. In this way, applications that implement the RFQ interfacescan be integrated without the need for complex project work.

(1) Message Choreography

FIG. 301 depicts the message choreography for the RFQ Interfaces. Thechoreography involves two business entities: a buyer (Purchasing or SRM)30102 and a bidder (Supplier) 30104. In one implementation, there arefive messages that are used to map a B2B RFQ process: (1) RFQRequest;(2) RFQChangeRequest; (3) RFQCancellationRequest; (4) QuoteNotification;and (5) RFQResultNotification. In the implementation shown in FIG. 301,the buyer 30102 sends an RFQRequest message 30106 to the bidder 30104,which is used to start a new RFQ process. In response, the bidder 30104may send an RFQAcceptanceConfirmation message 30108 to the buyer 30102to inform the buyer 30102 whether the bidder 30104 intends to submit aquotation. This provides the buyer 30102 with an early indication ofwhether the bidders that were expected to participate are in factparticipating. In the case of a public RFQ process, the bidder 30104 canalso use this message to apply to participate and to ask for the RFQdocuments to be sent.

The buyer 30102 may send an RFQChangeRequest message 30110 to the bidder30104, which is used to change an RFQ during an RFQ process. Changing anRFQ includes creating new items, changing existing items, and deletingitems. This message is also used when a buyer returns the bidder'squotation for revision.

The buyer 30102 may also send an RFQCancellationRequest message 30112 tothe bidder 30104, which is used to cancel an RFQ that is no longerrequired.

The bidder 30104 may send a QuoteNotification message 30114 to the buyer30102, which includes the bidder's quotation in response to the buyer'sinvitation to submit a quotation. The buyer 30102 may send aRFQResultNotification message 30116 to the bidder 30104, which eitherincludes a notification about the RFQ items for which the bidder'squotation has been accepted including the extent of the award or anegative notification if the bidder's quotation was not successful. Inresponse, the bidder 30104 may send an RFQResultAcceptanceConfirmationmessage 30118 to the buyer 30102 and includes the bidder's acceptance orrejection of the quotation accepted by the buyer 30102. This message maybe used particularly if the quotation accepted by the buyer represents apart of the bidder's quotation, since individual items and/or partialquantities in the RFQ are being distributed to several bidders.

The structures of the first five message types to be implemented arespecified in the four message data types RFQMessage,RFQCancellationMessage, QuoteMessage, and RFQResultMessage. Thestructure of the two message types RFQRequest and RFQChangeRequest isspecified by the message data type RFQMessage. The parts of thestructure that are used differ depending on the message. The descriptionof the RFQMessage below specifies which parts are used in which message.

The structure of the message type RFQCancellationRequest is specified inthe message data type RFQCancellationRequest, which has a relativelysimple structure. In one implementation, this message type includes theRFQ number. The structure of the message type QuoteNotification isspecified in the message data type QuoteMessage. The structure of themessage type RFQResultNotification is specified in the message data typeRFQResultMessage.

An RFQRequest is a request from a buyer to a bidder to participate in anRFQ process for a product. The structure of the message type RFQRequestis specified in the message data type RFQMessage. The RFQRequest is sentonce for each invited bidder. Since the RFQ can be used for contractualnegotiations, the structure may also include contract-specific fields.These fields contain information for creating a contract from asuccessful quotation. The addressee for a message can also be atendering platform, for example, which means that the actual bidders arenot known when the RFQRequest is issued. RFQs issued by publicauthorities are published with general access. Rather than being inviteddirectly, bidders may apply to participate, via the platform. One aim ofthe platform may be to avoid giving certain bidders preferentialtreatment as a result of not inviting or informing, or by implicitlyexcluding, other bidders.

An RFQChangeRequest is a change to the buyer's request to a bidder toparticipate in an RFQ process for a product. The structure of themessage type RFQChangeRequest is specified in the message data typeRFQMessage. The RFQChangeRequest is sent once for each invited bidder inone implementation. This is independent of whether a quotation hasalready been submitted. In the case of a publication platform (such as abulletin board), which is used to publish an RFQ, the RFQChangeRequestis sent to the platform and to the bidders who have already submitted aquotation. In the case of a tendering platform, in one implementation,which also manages the quotation process (such as in the public sector),the RFQChangeRequest is sent to the tendering platform. The platformthen provides the bidders with information. The scenario that appliesdepends on the configuration. In one implementation, an RFQChangeRequestcan be sent as often as required and at any time, provided thatRFQCancellationRequest or RFQResultNotification messages have not beensent. This message can be used to return a quotation from a particularbidder to this bidder for revision. This message asks the bidder inquestion to revise the quotation and resubmit it, before the buyer canconsider it. The RFQChangeRequest is the basis for remaining quotations.Any quotations that have already been submitted are returned to thebidders as a result of this message. Regardless of whether the changesaffect the submitted quotation, a quotation is resubmitted in oneimplementation. The revised quotation might be identical to thequotation that was submitted before the RFQ was changed.

An RFQCancellationRequest is a cancellation of an RFQ for a product by abuyer. The structure of the message type RFQCancellationRequest isspecified in the message data type RFQCancellationMessage. TheRFQCancellationRequest can be sent at any time up to the submissiondeadline. After the RFQCancellationRequest has been sent, no furthermessages are expected. This message is sent to the invited bidders,regardless of whether a quotation already exists. In the case of atendering platform, the RFQCancellationRequest is sent to the tenderingplatform and to the bidders who have already submitted a quotation. TheRFQCancellationRequest message has its own structure, that is, thestructure of the RFQCancellationMessage, with the object ID of thecancelled RFQ.

A QuoteNotification is a quotation submitted by a bidder to a buyer inresponse to the RFQ for a product issued by the buyer. The structure ofthe message type QuoteNotification is specified in the message data typeQuoteMessage. In one implementation, each invited bidder can submitprecisely one quotation. If the bidder wants to make changes to asubmitted quotation, the bidder asks the buyer who issued the RFQ toreturn the quotation for revision. The QuoteNotification can besubmitted up to the submission deadline. A quotation can be exchangedbetween the buyer and the bidder as many times as required, up to thesubmission deadline. The QuoteNotification message has a separatestructure, the QuoteMessage. One reason behind having another structurein addition to the RFQMessage is to encourage bidders to submitquotations on their own initiative, not necessarily in response to anRFQRequest.

An RFQResultNotification is a notification by a buyer to a bidder of thetype and extent of the acceptance or rejection of the quotation. Thestructure of the message type RFQResultNotification is specified in themessage data type RFQResultMessage. The RFQResultNotification is sentonce for each bidder to the bidders that have submitted a quotation.Successful bidders are sent precise information about the quotationacceptance. Unsuccessful bidders are sent a standard rejection. In thecase of a tendering platform, a copy of the RFQResultNotification forthe successful bidders can also be sent to the tendering platform sothat the result can be published. In the public sector, the decisionregarding whose quotation has been accepted is made public.

The interaction between the RFQ interfaces in an RFQ process isdescribed in detail below. Generally, the buyer initiates the RFQprocess and invites bidders to submit quotations. Up to the submissiondeadline, the bidder and buyer exchange quotations, queries, revisedquotations, and changes to the RFQ. Once the submission deadline haspassed, the buyer compares the quotations and decides to accept thequotation submitted by one particular bidder or several bidders. Thebuyer can also decide to reject all quotations.

The buyer starts an RFQ process by sending an RFQRequest message. Eachinvited bidder or addressed public platform receives a separateinvitation. Once the RFQ process has been started, the buyer can sendchange requests at any time, using an RFQChangeRequest message.Quotations that have already been submitted are then resentautomatically to the bidder in question. The bidder then resubmits thequotation, in one implementation, before it can be considered by thebuyer (even if the RFQChangeRequest does not affect the bidder'squotation).

At any time up to the submission deadline, the buyer can end the RFQprocess by sending an RFQCancellationRequest message. If the submissiondeadline has already passed, the RFQCancellationRequest is no longerused. However, the buyer can decide against all the quotations submittedand therefore reject them. Provided the RFQ has not been set tocomplete, the buyer can make changes to the RFQ in order to obtainadditional quotations or revisions to the submitted quotations byextending the submission deadline. Alternatively, the buyer can create anew RFQ with the same contents or with different contents.

After receiving the RFQRequest message, the bidder can send a quotationto the buyer, using the QuoteNotification message. In oneimplementation, each invited bidder is allowed to submit one quotationin response to an RFQRequest. To make changes to a submittedQuoteNotification, the bidder asks the buyer who issued the RFQ toreturn the quotation for revision. The bidder can enter any queries inthe quotation and wait for the quotation to be returned, together with anote from the buyer. The quotation can be exchanged any number of times.To withdraw the quotation, the bidder contacts the buyer, who thendeletes the quotation.

The buyer can also take the initiative and return a submitted quotationto the bidder, using the RFQChangeRequest, asking for revisions to bemade. In this case, the bidder resubmits the quotation for it to beconsidered in the quotation comparison.

At any time up to the submission deadline, changes and quotations can beexchanged as often as required. However, while the buyer is allowed tosend an RFQChangeRequest at any time, or several RFQChangeRequests insuccession, an RFQChangeRequest is followed by the QuoteNotification. Inone implementation, the QuoteNotification cannot be sent several timesin succession.

The quotation process is completed either as a result of theRFQCancellationRequest being sent or the submission deadline passing.Once the submission deadline has passed, the buyer compares thequotations that have been submitted and decides to accept thequotation(s) from one bidder or several bidders. The buyer can alsodecide to reject all of the submitted quotations. The buyer can splitthe order quantities as required, up to item level.

In the case of public authority tendering platforms, the steps thatstipulate that the buyer is allowed to view the quotations before thesubmission deadline no longer apply. The quotations are not transferredto the buyer until the opening date of the quotation comparison. Priorto this, the quotations may be kept in encrypted form. In oneimplementation, the bidder can ask for the quotation to be returned forrevision or for it to be deleted because the bidder wants to withdrawit. The result of the RFQ is communicated using theRFQResultNotification message. This message informs the successfulbidders which quotation has been accepted and details the specific itemsand the order quantity involved. Unsuccessful bidders are sent arejection.

In the RFQ process, messages may be transferred exactly once in order(“EOIO”) and serialized using message queues. Each RFQ process may haveits own message queue (as opposed to one queue for all RFQ processes) sothat one failed message does not block the other RFQ messages in theentire system.

A recipient system may accept every formally correct incoming RFQmessage. Business problems are resolved on the buyer side, using anRFQChangeRequest or RFQCancellationRequest message, and on the sellerside, using a QuoteNotification message. It is up to the recipientsystem to distinguish between technical and business errors. Borderlinecases may include incorrect ISO codes for currencies, and languages. Inorder to restart an RFQ process that is corrupt as a result of a failedmessage, the procurement system provides an option for transferring thecurrent status of the RFQ, together with the associated data, at anytime using an RFQChangeRequest message. In order to restart a processfollowing a failed RFQRequest message, the procurement system should beable to restart an RFQ process at any time using an RFQRequest message.The RFQResultNotification has legal implications. Following a failedRFQResultNotification, the procurement system should therefore be ableto repeat this message.

(2) Message Data Type RFQ Message

The message data type RFQMessage groups together the businessinformation relevant for sending a business document in a message andthe RFQ object in the document. As depicted in FIG. 302, the RFQMessagepackage 30202 includes a MessageHeader package 30204, an RFQ package30206 and an RFQMessage entity 30208.

(a) Message Header Package

A MessageHeader package 30208 groups together the business informationthat is relevant for sending a business document in a message. Itincludes a MessageHeader entity 30210. There is a 1:1 relationship 30212between the RFQMessage 30208 and the MessageHeader entity 30210.

A MessageHeader entity 30210 groups the business information from theperspective of the sending application to identify the business documentin a message, to provide information about the sender, and to provideany information about the recipient. The MessageHeader entity 30210includes a SenderParty entity 30214 and a RecipientParty entity 30216.There is a 1:c relationship 30218 between the MessageHeader entity 30210and the SenderParty entity 30214. There is a 1:cn relationship 30220between the MessageHeader entity 30210 and the RecipientParty entity30216. The MessageHeader entity 30210 is of type GDT:BusinessDocumentMessageHeader. The MessageHeader entity 30210 includesan ID, a ReferenceID, and a CreationDateTime.

The MessageID is set by the sending application. With theReferenceMessageID, reference is made in the current BusinessDocument toa previous BusinessDocument. The ReferenceMessageID should be filled inorder to avoid inconsistencies that can arise as a result of sendingmessages in the pipeline at the same time, e.g., the buyer changes theRFQ and sends the message with the changes (RFQChangeRequest) to thebidders. At the same time, a bidder sends a QuoteNotification. Withoutthe ReferenceMessageID in the message header in the QuoteNotificationand in the case of longer transmission times for the messages, it may nolonger be possible to determine clearly whether the QuoteNotificationsent by the bidder refers to the old RFQ or to the new, changed RFQ.

The SenderParty is the party responsible for sending a business documentat business application level. The SenderParty entity 30214 is of typeGDT: BusinessDocumentMessageHeader-Party. The SenderParty entity 30214can be filled by the sending application to name a contact person forany problems with the message. This is particularly useful if anadditional infrastructure (such as a marketplace or a tenderingplatform) is located between the sender and the recipient. TheSenderParty entity 30214 is used to transfer the message and can beignored by the receiving application. It should be filled by the senderparticularly if the participating parties are not transferred with theRFQ package 30206.

The RecipientParty is the party responsible for receiving a businessdocument at business application level. The RecipientParty entity 30216is of type GDT: BusinessDocument-MessageHeaderParty. The RecipientPartyentity 30216 can be filled by the sending application to name a contactperson for any problems that occur with the message. This isparticularly useful if an additional infrastructure (such as amarketplace or a tendering platform) is located between the sender andthe recipient. The RecipientParty entity 30216 is used to transfer themessage and can be ignored by the receiving application. It should befilled by the sender particularly if the participating parties are nottransferred with the RFQ package 30206.

(i) RFQ Package

The RFQ package 30206 includes a Party package 30222, a Location package30224, a DeliveryInformation package 30226, a PaymentInformation package30228, a ProductInformation package 30230, a PriceInformation package30239, a BusinessTransactionDocumentReference package 30232, aFollowUpBusinessTransactionDocument package 30234, an Attachment package30236, a Description package 30238, and an Item package 30240. The RFQpackage 30206 also includes an RFQ entity 30244. There is a 1:1relationship 30246 between the RFQMessage entity 30208 and the RFQentity 30244.

The RFQ entity 30244 is a request (or a change to a request) from abuyer to a bidder to submit a quotation for the products (goods orservices) specified in the RFQ. In addition to the buying party and thebidder, additional parties can be involved in the RFQ entity 30244 (seeParty package 30222 below). The delivery location can also be specified(see Location package 30224 below). Delivery and payment terms are alsoagreed upon (see DeliveryInformation package 30226 andPaymentInformation package 30228 below). The RFQ entity 30244 cancontain a reference to a Quote if the bidder has a question or if thebuyer has changed the RFQ entity 30244 (seeBusinessTransactionDocumentReference package 30232 andFollowUpBusinessTransactionDocumentReference package 30234 below). Notesor references to attachments can be specified for the RFQ (seeAttachment package 30236 and Description package 30238 below). The RFQentity 30244 is of type GDT: RFQ.

The RFQ entity 30244 includes an ID, a VersionID, a PostingDateTime, aLastChangeDateTime, a PublishDateTime, a DisplayDateTime, aBiddingStartDateTime, a QuoteSubmissionDateTime, a QuoteOpeningDateTime,a QuoteBindingDateTime, a ContractValidityDateTimePeriod, a Note, anRFQPublicIndicator, a QuoteChangeAllowedIndicator, aQuoteUnplannedItemPermissionCode, a QuotePriceBiddingCondition-Code, aQuoteQuantityBiddingConditionCode, a QuoteItemBiddingConditionCode,RequestedQuoteCurrencyCode, and a ContractTargetAmount. The ID is aunique identifier specified by the buyer for the RFQ. The ID is of typeGDT: BusinessTransactionDocumentID. The VersionID is the uniqueidentifier that the buyer assigns to the version fo a RFQ. The VersionIDis of type GDT: VersionID.

The PostingDateTime is the creation date/time of the RFQ at the buyer.The PostingDateTime is of type GDT: DateTime, as are the followingelements in this paragraph. The LastChangeDateTime is the date/time ofthe last change made to the RFQ by the buyer. The PublishDateTime is thedate/time when the RFQ is sent. The DisplayDateTime is the date/time asof which the published RFQ is displayed on a tendering platform. TheBiddingStartDateTime is the date/time as of which quotations can besubmitted. The QuoteSubmissionDateTime is the date/time after theBiddingStartDateTime up to which quotations can be submitted. TheQuoteOpeningDateTime is the date/time when the quotations are opened anddisplayed for the quotation comparison. The QuoteBindingDateTime is thedate/time up to which bidders are bound to the quotations they havesubmitted.

The ContractValidityDateTimePeriod is the validity period of thecontract that is to be assigned using the RFQ. TheContractValidityDateTimePeriod is of type GDT: DateTimePeriod. The Noteis a short description or the title of the RFQ. It is generally used toprovide the user with a simple method for searching for a particularRFQ. The Note is of type GDT: Note. The RFQPublicIndicator specifieswhether the RFQ process is a closed RFQ process with bidders that havebeen explicitly invited or an open RFQ process in which bidders who havenot been explicitly invited can also participate. The RFQPublicIndicatoris of type GDT: BusinessTransactionDocumentPublicIndicator. TheQuoteChangeAllowedIndicator is indicator that the buyer assigns to anRFQ to indicate whether the bidder may change quotes after they havebeen issued. In one implementation, “True” means that quotes may bechanged and “False” means that only quotes that have not been changedare valid. The QuoteChangeAllowedIndicator is of type GDT:AllowedIndicator. The QuoteUnplannedItem-PermissionCode specifieswhether the bidder's quotation is allowed to contain own items withalternative quotations. The QuoteUnplannedItemPermissionCode is of typeGDT: UnplannedItemPermissionCode. The QuotePriceBiddingConditionCodespecifies whether the bidder is allowed to specify pricing information.If the RFQ is used to check the bidder's ability to meet certaintechnical requirements, for example, prices might not be required. TheQuoteQuantityBiddingConditionCode specifies whether the bidder isallowed to enter in the quotation a quantity other than the requestedquantity. The QuoteItemBiddingConditionCode specifies whether the bidderhas to submit a quotation for all items. TheQuotePriceBidding-ConditionCode and QuoteItemBiddingConditionCode are oftype GDT: BiddingConditionCode. The ContractTargetAmount is the targetamount in contractual negotiations. The ContractTargetAmount is of typeGDT: Amount. The RequestedQuoteCurrencyCode is the currency that thebuyer defines in the RFQ. The bidder's quote must be in this currency.The RequestedQuoteCurrencyCode is of type GDT: CurrencyCode.

The ContractTargetAmount in the QuoteNotification is informationprovided to the buyer by the bidder. The ContractTarget-Amount is usedif a contract is to be negotiated and assigned using an RFQ. Differencesbetween the RFQContractTargetAmount and the QuoteContractTargetAmountare allowed and are subject to the business framework of the negotiationprocess as defined by the buyer and bidder. There are no dependenciesbetween how the ContractTargetAmount is used at header and/or itemlevel. The bidder decides which information to supply to the buyer.

(ii) RFQ Party Package

The Party package 30222 groups together the business parties that occurin one of the RFQ messages. The party package 30222 includes aBuyerParty entity 30248, a BidderParty entity 30250, aBidderPortalProviderParty entity 30252, a ProductRecipientParty entity30254, a VendorParty entity 30256, a ManufacturerParty entity 30258, anda PayerParty entity 30260. There is a respective 1:c relationship 30262,30264, 30266, 30268, 30270, 30272, and 30274 between the RFQ entity30244 and the BuyerParty entity 30248, the BidderParty entity 30250, theBidderPortalProviderParty entity 30252, the ProductRecipientParty entity30254, the VendorParty entity 30256, the ManufacturerParty entity 30258,and the PayerParty entity 30260.

In one implementation, either the ID or the ID and address can betransferred for each party. If the ID is transferred, the ID addressdefined in the master data is used. If the ID and address aretransferred, the ID identifies the party and the address is deemed to bea document address that is different to the master data address. The IDand address may be sent to avoid misunderstandings. The receivingapplication may implement a suitable optimization strategy to ensurethat the system does not create many identical document addresses.

A default logic is used for the parties: from the header to the itemsand within item hierarchies. Parties specified in the header are usedfor the items for which a corresponding party is not explicitlytransferred and that are directly assigned to the header. In accordancewith the same logic, parties transferred at item level are used forsubitems assigned to the relevant item in an item hierarchy. The defaultlogic is used for the party as a whole, including the contact person. Inone implementation, parts of a party specified at header level or for ahierarchy item cannot be specified in more detail at item level. Thedefault logic may be a simplified version of the transferred message. Asregards logic, parties at header level and for hierarchy items behave asif they have been explicitly transferred for the subitems of themessage. This also means that if changed items are transmitted ratherthan all items, the parties are used for the transmitted items. Changesmade to parties also apply to items relevant for the party in question.

A BuyerParty is a party that buys goods or services. The BuyerPartyentity 30248 is of type GDT: BusinessTransactionParty. The sameBuyerParty entity 30248 is used for all the items in an RFQ in oneimplementation. The BuyerParty is not changed once an RFQ has beencreated. Changes can be made to the BuyerParty/Contact entity and adifferent BuyerParty/Contact entity is permitted for each item. Changescan be made to the address of the BuyerParty, but different addressesare not permitted for each item. If a ProductRecipientParty is notexplicitly specified in an RFQ process, the BuyerParty is also used asthe ProductRecipientParty. If a ProductRecipientParty and ShipToLocationare not explicitly specified in the RFQ process, the BuyerParty addressis also used as the ship-to address. If a PayerParty is not explicitlyspecified in an RFQ process, the BuyerParty is also used as thePayerParty.

The BuyerParty entity 30248 includes an Address entity 30276 and aContact entity 30278. There is a 1:c relationship 30280 between theBuyerParty entity 30248 and the Address entity 30276, and there a 1:crelationship 30282 between the BuyerParty entity 30248 and Contactentities 30278. The Address entity 30276 includes a PersonName entity30284, an Office entity 30286, a PhysicalAddress entity 30288, aGeoCoordinates entity 30290 and a Communication entity 30292. There is arespective 1:c relationship 30294, 30296, 30298, 30200A, and 30202Abetween the Address entity 30276 and the PersonName entity 30284, theOffice entity 30286, the PhysicalAddress entity 30288, theGeoCoordinates entity 30290 and the Communication entity 30292.

The Contact entity 30278 includes an Address entity 30204A. There is a1:c relationship 30205A between the Contact entity 30278 and the Addressentity 30204A. The Address entity 30204A includes a PersonName entity30206A, an Office entity 30208A, a PhysicalAddress entity 30210A, aGeoCoordinates entity 30212A, and a Communication entity 30214A. Thereis a respective 1:c relationship 30216A, 30218A, 30220A, 30222A, and30224A between the Address entity 30204A and the PersonName entity30206A, the Office entity 30208A, the PhysicalAddress entity 30210A, theGeoCoordinates entity 30212A, and the Communication entity 30214A.

The BidderParty is a party that bids for goods or services. TheBidderParty entity 30250 is of type GDT:BusinessTransactionDocumentParty. The same BidderParty entity 30250 maybe used for all the items in an RFQ. The BidderParty entity 30250 is notchanged once an RFQ has been created. Changes can be made to theBidderParty/Contact entity and a different BidderParty/Contact entity ispermitted for each item. Changes can be made to the address of theBidderParty, but different addresses are not permitted for each item. Ifa VendorParty is not explicitly specified in an RFQ process, theBidderParty is also used as the VendorParty. If a VendorParty andShipFromLocation are not explicitly specified in an RFQ process, theaddress of the BidderParty is used as the ship-from address for thematerial items. The BidderParty entity 30250 includes the same elementsas that described above for the BuyerParty entity 30248, as denoted byellipses 30226A.

A BidderPortalProviderParty is a party that runs a portal that bringsbusiness partners together for a business transaction. TheBidderPortalProviderParty entity 30252 is of type GDT:BusinessTransactionDocumentParty. The BidderPortalProviderParty entity30252 is explicitly specified if an RFQ is to be sent to a publictendering platform. The BidderPortalProviderParty entity 30252 includesthe same elements as that described above for the BuyerParty entity30248, as denoted by ellipses 30228A.

The ProductRecipientParty is the party to which goods are delivered orfor whom services are provided. The ProductRecipientParty entity 30254is of type GDT: BusinessTransactionDocumentParty. If a ShipToLocation isnot explicitly specified in an RFQ process, the ProductRecipientPartyentity 30254 address is used as the ship-to address. TheProductRecipientParty is not synonymous with the ShipToLocation andshould be used when the ProductRecipientParty (company or person) isdifferent than the BuyerParty. The ProductRecipientParty entity 30254includes the same elements as that described above for the BuyerPartyentity 30248, as denoted by ellipses 30230A.

A VendorParty is a party that delivers goods or provides services. TheVendorParty entity 30256 is of type GDT:BusinessTransactionDocumentParty. If a ShipFromLocation is notexplicitly specified in an RFQ process, the address of the VendorPartyentity 30256 is used as the ship-from address for the material items.The VendorParty entity 30256 is not the company or person that isresponsible for transporting the goods. The CarrierParty entity isresponsible for this; however, this party is not typically used in theRFQ interfaces. The VendorParty is not synonymous with theShipFromLocation and should be used when the VendorParty (company orperson) is actually different than the BidderParty. The VendorPartyentity 30256 includes the same elements as that described above for theBuyerParty entity 30248, as denoted by ellipses 30232A.

A ManufacturerParty is a party that manufactures goods. TheManufacturerParty entity 30258 is of type GDT:BusinessTransactionDocumentParty. The ManufacturerParty entity 30258 canbe used for material items. With regard to the ManufacturerParty entity30258, the default logic (from header to item to subitems) is used formaterial items; for other items, the ManufacturerParty entity 30258 isignored. The ManufacturerParty entity 30258 can be used to uniquelydefine the context of a ManufacturerProductID entity. TheManufacturerParty entity 30258 includes the same elements as thatdescribed above for the BuyerParty entity 30248, as denoted by ellipses30234A.

A PayerParty is a party that pays for goods or services. The PayerPartyentity 30260 is of type GDT: BusinessTransactionDocumentParty. ThePayerParty is used for the ContractPayer. The ContractPayer is the partypaying for contractual negotiations. The PayerParty entity 30260includes the same elements as that described above for the BuyerPartyentity 30248, as denoted by ellipses 30236A.

(iii)RFQ Location Package A Location package 30224 groups together thelocations that can occur in one of the RFQ messages. The Locationpackage 30224 includes a ShipToLocation entity 30238A. There is a 1:crelationship 30240A between the RFQ entity 30244 and the ShipToLocationentity 30238A. The ShipToLocation entity 30238A includes an Addressentity 30242A. There is a 1:c relationship 30244A between theShipToLocation entity 30238A and the Address entity 30242A.

A similar default logic to that used for Parties is also used forlocations. In one implementation, either the ID or the address, or bothcan be transferred to each location. If the ID is transferred, the IDaddress defined in the master data is used. If the address istransferred, it is this address that is used (if necessary, a locationis assigned at the address recipient). If the ID and address aretransferred, the ID identifies the location and the address is deemed tobe a document address that is different to the master data address. TheID and address may be sent to avoid misunderstandings. The receivingapplication should implement a suitable optimization strategy to ensurethat the system does not create many identical document addresses.

The ShipToLocation is the location to which goods are to be delivered orwhere services are to be provided. The ShipToLocation entity 30238A isof type GDT: BusinessTransaction-DocumentLocation.

The Address entity 30242A includes a PersonName entity 30246A, an Officeentity 30248A, a PhysicalAddress entity 30250A, a GeoCoordinates entity30252A, and a Communication entity 30254A. There is a respective 1:crelationship 30256A, 30258A, 30260A, 30262A, and 30264A between theAddress entity 30242A and the PersonName entity 30246A, the Officeentity 30248A, the PhysicalAddress entity 30250A, the GeoCoordinatesentity 30252A, and the Communication entity 30254A.

(iv) RFQ Delivery Information Package

A DeliveryInformation package 30226 groups together the informationabout a required delivery in an RFQ process. The DeliveryInformationpackage 30226 includes a DeliveryTerms entity 30266A. There is a 1:crelationship 30268A between the RFQ entity 30244 and the DeliveryTermsentity 30266A.

The DeliveryTerms is the condition and agreement that is valid forexecuting the delivery and transporting the tendered goods and for thenecessary services and activities. The DeliveryTerms entity 30266A istype GDT: DeliveryTerms. It includes an Incoterms entity 30270A. Thereis a 1:c relationship 30272A between the DeliveryTerms entity 30266A andthe Incoterms entity 30270A. The Incoterms is allowed to be used formaterial items. The default logic takes the Incoterms entity intoaccount for material items. For other items, Incoterms may be ignored.

(v) RFQ Payment Information Package

A PaymentInformation package 30228 groups together the paymentinformation in an RFQ process. The PaymentInformation package 30228includes a CashDiscountTerms entity 30274A and a PaymentForm entity30276A. There is a 1:c relationship 30278A between the RFQ entity 30244and the CashDiscountTerms entity 30274A, and a 1:c relationship 30280Abetween the RFQ entity 30244 and the PaymentForm entity 30276A.

The CashDiscountTerms is the term of payment in an RFQ process. TheCashDiscountTerms entity 30274A is type GDT: CashDiscountTerms.

A PaymentForm is the payment form together with the data required. ThePaymentForm entity 30276A includes a PaymentFormCode, which is the codedrepresentation of the payment form. The PaymentFormCode is of type GDT:PaymentFormCode.

(vi) RFQ Price Information Package

The PriceInformation package 30239 groups together all price informationin a quotation item. It contains a PriceSpecification Element 30203B.The PriceInformation package 30239 for an RFQ item contains only prices;it does not contain any information about how the prices are calculated(pricing scales, and so on).

(vii) RFQ Product Information Package

The ProductInformation package 30230 groups together the productcategory. The ProductInformation package 30230 includes aProductCategory entity 30282A. There is a 1:c relationship 30284Abetween the RFQ entity 30244 and the ProductCategory entity 30282A.

The ProductCategory includes the details about a product category asgenerally understood from a commercial point of view in businesstransaction documents. The ProductCategory entity 30282A includesdetails for identifying the product category using an internal ID, astandard ID, and IDs assigned by involved parties. The ProductCategoryentity 30282A is of type GDT:BusinessTransactionDocumentProductCategory. The product category atheader level can be used to classify the RFQ and provide the bidderswith an initial indication of what is involved in the RFQ. The productcategory can differ between the buyer and seller.

(viii) RFQ Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 30232 groups togetherbusiness document references that can occur in one of the RFQ messages.The BusinessTransactionDocumentReference package 30232 includes aQuoteReference entity 30286A. There is a 1:c relationship 30288A betweenthe RFQ entity 30244 and the QuoteReference entity 30286A.

A QuoteReference is a reference to a quotation. The QuoteReferenceentity 30286A is of type GDT: BusinessTransactionDocument-Reference.

In one implementation, a QuoteReference can reference one quotation,that is, one ID is permissible. As far as the referenced quotation isconcerned, there are no conflicts with a QuoteReference at item level.If a reference is used at both header and item level, it refers to one(the same) quotation.

The reference to a quotation is required at both header and item level,since RFQs do not always have item data. The QuoteReference is used whenquestions and answers are exchanged between the bidder and buyer and ifthe RFQ is changed.

(ix) RFQ Follow-Up Business Transaction Document Package

A FollowUpBusinessTransactionDocument package 30234 groups together theinformation about which business transaction documents the buyer isexpecting as a result of the RFQ process. TheFollowUpBusinessTransactionDocument entity 30234 includes aFollowUpPurchaseOrder entity 30290A and a FollowUpPurchaseContractentity 30292A. There is a 1:c relationship 30294A between the RFQ entity30244 and the FollowUpPurchaseOrder entity 30290A, and a 1:crelationship 30296A between the RFQ entity 30244 and theFollowUpPurchaseContract entity 30292A. In theFollowUpBusinessTransactionDocument package 30234, the buyer providesthe bidders with information about whether the RFQ is to result in acontract or a purchase order. However, the buyer can also leave thisopen by not providing any information.

The FollowUpPurchaseOrder provides information about whether the buyerexpects a purchase order as a result of the RFQ process. TheFollowUpPurchaseOrder entity 30290A includes a RequirementCode, which isa coded representation of information about whether the buyer expects apurchase order as a result of the RFQ process. The RequirementCode is oftype GDT: FollowUpBusinessTransactionDocumentRequirementCode. TheRequirementCode entity can be changed by the buyer.

The FollowUpPurchaseContract provides information about whether thebuyer expects a contract as the result of the RFQ process. TheFollowUpPurchaseContract entity 30292A includes a RequirementCode, whichis a coded representation of information about whether the buyer expectsa contract as a result of the RFQ process. The RequirementCode is oftype GDT: FollowUpBusinessTransactionDocumentRequirementCode. TheRequirementCode can be changed by the buyer.

(x) RFQ Attachment Package

The Attachment package 30236 groups together the attachment informationregarding the RFQ. The Attachment package 30236 includes an Attachmententity 30298A. The Attachment is any document that refers to the RFQ.The Attachment entity 30298A is of type GDT: Attachment. There is a 1:crelationship 30200B between the RFQ entity 30244 and the Attachmententity 30298A.

(xi) RFQ Description Package

The Description package 30238 groups together the texts regarding theRFQ. The Description package 30238 includes a Description entity 30202B.The Description is a natural-language text regarding the RFQ, which isvisible to parties. The Description entity 30202B is of type GDT:Description. There is a 1:c relationship 30203B between the RFQ entity30244 and the Description entity 30202B.

The Description can be used for textual information about thetransferred RFQ and not just the current message. An example of thiswould be information stating that the employee responsible in Purchasingwill be on vacation as of a specific date, and indicating the name andtelephone number of a substitute as of this date. The Description canalso be used for communication between the buyer and bidder in order toprocess queries, for example. In the case of a public tenderingplatform, measures are taken to ensure that individual communicationswith individual bidders, which contain explanatory information about theRFQ, are also made available to other RFQ participants. This is ensuredby sending a copy of the description to the tendering platform, where itis published.

(xii) RFQ Item Package

An RFQItem package 30240 includes a ProductInformation package 30204B, aParty package 30206B, a Location package 30208B, a DeliveryInformationpackage 30210B, a BusinessTransactionDocumentReference package 30212B,an Attachment package 30214B, a Description package 30216B, aPartyInforamation Package 30217B, and a ScheduleLine package 30218B. TheItem package 30240 also includes an RFQItem entity 30220B. There is a1:cn relationship 30222B between the RFQ entity 30244 and the RFQItementity 30220B. RFQItem entities are arranged hierarchically using aHierarchy Relationship 30224B. The Hierarchy Relationship 30224B is therelationship between a sub-item and a higher-level parent item in anitem hierarchy. There is a 1:cn relationship 30226B between the RFQItementity 30220B and its subordinate entities, and there is a 1:crelationship 30228B between the RFQItem entity 30220B and itssuperordinate entities.

The RFQItem specifies a product tendered by an RFQ with additionalinformation on such a product. The RFQItem entity 30220B includesdetailed information about a particular product (see ProductInformationpackage 30204B). The quantity of the product and (delivery) dates/timesare specified in the schedule line. For the RFQItem (compared to theinformation of the RFQ), deviating parties, locations, and deliveryterms can be defined (see Party package 30206B, Location package 30208B,and DeliveryInformation package 30210B). The RFQItem can containreferences to other business documents that are relevant for the item(see BusinessTransactionDocumentReference package 30212B). Notes orreferences to attachments can also be specified for the RFQItem (seeAttachment package 30214B and Description package 30216B). The RFQItementity 30220B is of type GDT: RFQItem.

The RFQItem entity 30220B includes an ID and a ContractTargetAmount. TheID is a unique identifier specified by the buyer for an item within anRFQ. The ID is of type GDT: BusinessTransactionDocumentItemID. TheContractTargetAmount is the target amount in contractual negotiations.The ContractTargetAmount is of type GDT: Amount.

A HierarchyRelationship 30224B includes a ParentItemBuyerID, aParentItemVendorID, and a TypeCode. The ParentItemBuyerID is thereference to a parent item with the item number assigned by the buyer.The ParentItemBuyerID is of type GDT: BusinessTransactionDocumentItemID.The ParentItemVendorID is the reference to a parent item with the itemnumber assigned by the seller. The ParentItemVendorID is of type GDT:BusinessTransactionDocumentItemID. The TypeCode represents thehierarchical relationship between the subitem and its higher-levelparent item. The TypeCode is of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode. TheParentItemBuyerID, ParentItemVendorID and TypeCode are generally notchanged once an item has been created. Either the ParentItemBuyerID orthe ParentItemVendorID is specified.

(a) RFQ Item Product Information Package

A ProductInformation package 30204B groups together the product and theproduct category. The ProductInformation package 30204B includes aProduct entity 30230B and a ProductCategory entity 30232B. There is a1:c relationship 30234B between the Item entity 30220B and the Productentity 30230B, and a 1:c relationship 30236B between the Item entity30220B and the ProductCategory entity 30232B.

A Product includes the details about a product as generally understoodfrom a commercial point of view in business documents. These are thedetails for identifying a product and product type, and the descriptionof the product. The Product entity 30230B is of type GDT:BusinessTransactionDocumentProduct.

A ProductCategory includes the details about a product category asgenerally understood from a commercial point of view in businesstransaction documents. The ProductCategory entity 30232B includesdetails for identifying the product category using an internal ID, astandard ID, and IDs assigned by involved parties. The ProductCategoryentity 30232B is of type GDT:BusinessTransaction-DocumentProductCategory. The product category isderived directly from the product if a product number is specified forthe product. It can differ for the buyer and seller if they haveclassified the same product differently. This is allowed and should betolerated by the systems involved. The product category at item levelcan differ from the product category at header level.

(xiii) RFQ Price Information Package

The PriceInformation package 30217B groups together all priceinformation in a quotation item. It contains a PriceSpecificationElement 30208C. The PriceInformation package 30217B for an RFQ itemcontains only prices; it does not contain any information about how theprices are calculated (pricing scales, and so on).

(a) RFQ Item Party Package

The Party package 30206B groups together the business parties that canoccur in one of the RFQ messages at the item level and represents partof the Party package 30222 at the header level. The party package 30206Bincludes a BuyerParty entity 30238B, a BidderParty entity 30240B, aProductRecipientParty entity 30242B, a VendorParty entity 30244B, and aManufacturerParty entity 30246B. There is a respective 1:c relationship30248B, 30250B, 30252B, 30254B, and 30256B between the Item entity30220B and the BuyerParty entity 30238B, the BidderParty entity 30240B,the ProductRecipientParty entity 30242B, the VendorParty entity 30244B,and the ManufacturerParty entity 30246B. Each of the BuyerParty entity30238B, the BidderParty entity 30240B, the ProductRecipientParty entity30242B, the VendorParty entity 30244B, and the ManufacturerParty entity30246B includes the same elements as that described above for theBuyerParty entity 30248 as denoted by ellipses 30258B, 30260B, 30262B,30264B, and 30266B.

(b) RFQ Item Location Package

Similar to the Location package 30224 at the header level, the Locationpackage 30208B at the item level includes a ShipToLocation entity30268B. There is a 1:c relationship 30270B between the Item entity30220B and the ShipToLocation entity 30268B. The ShipToLocation entity30268B includes the same elements as that described above for theShipToLocation entity 30238A as denoted by ellipses 30272B.

(c) RFQ Item Delivery Information Package

Similar to the DeliveryInformation package 30226 at the header level,the DeliveryTerms package 30210B at the item level includes aDeliveryTerms entity 30274B. There is a 1:c relationship 30276B betweenthe Item entity 30220B and the DeliveryTerms entity 30274B. TheDeliveryTerms contains a MaximumLeadTimeDuration, which is the maximumlead time from the time of the order to the receipt of the delivery.This duration can be agreed in RFQs or contractual negotiations andrepresents the basis (that is binding) for the calculation of thereceived delivery date for an order date. The MaximumLeadTimeDuration isof type GDT: Duration.

The DeliveryTerms entity 30274B includes an Incoterms entity 30278B.There is a 1:c relationship 30280B between the DeliveryTerms entity30274B and the Incoterms entity 30278B.

(d) RFQ Item Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 30212B groups togetherthe business document references that can occur in one of the RFQmessages. The BusinessTransaction-DocumentReference package 30212Bincludes a QuoteReference entity 30282B, a PurchaseContractReferenceentity 30284B, and a BuyerProductCatalogueReference entity 30286B. Thereis a respective 1:c relationship 30288B, 30290B, and 30292B between theItem entity 30220B and the QuoteReference entity 30282B, thePurchaseContractReference entity 30284B, and theBuyerProductCatalogueReference entity 30286B.

A QuoteReference is a reference to the quotation or the item within thequotation. The QuoteReference entity 30282B is of type GDT:BusinessTransactionDocumentReference. In one implementation, aQuoteReference entity 30282B can reference one item, that is, one ItemIDis permissible. As far as the referenced quotation is concerned, thereare no conflicts with a QuoteReference entity 30286A at the headerlevel. If a quotation reference is maintained at both the header anditem levels, it refers to one (the same) quotation.

The PurchaseContractReference is a reference to a purchase contract oritem in a purchase contract. The PurchaseContractReference entity 30284Bis of type GDT: BusinessTransaction-DocumentReference. In oneimplementation, a PurchaseContractReference entity 30284B can referenceone item, that is, one ItemID is permissible. Unless otherwise agreed,the seller is responsible for determining the correctPurchaseContractReference for a specified SellerContractReference.

A BuyerProductCatalogueReference is a reference to the buyer's productcatalog or an item within the buyer's product catalog. TheBuyerProductCatalogueReference entity 30286B is of type GDT:CatalogueReference. In one implementation, aBuyerProductCatalogueReference entity 30286B can reference one item,that is, one ItemID is permissible. The BuyerProductCatalogueReferenceentity 30286B should be filled if an RFQItem entity 30220B refers to acatalog whose number and item numbers were assigned by the buyer. In theRFQ process, the BuyerProductCatalogueReference entity 30286B can beused as a substitute product number if the product is defined in acatalog rather than having its own master record.

(e) RFQ Item Attachment Package

The RFQItemAttachment package 30214B includes an Attachment entity30294B. There is a 1:c relationship 30296B between the Item entity30220B and the Attachment entity 30294B.

(f) RFQ Item Description Package

The RFQItemDescription package 30216B includes a Description entity30298B. There is a 1:c relationship 30200C between the Item entity30220B and the Description entity 30298B.

(g) RFQ Item Schedule Line Package

The ScheduleLine package 30218B groups together the quantity and dateinformation about an RFQItem. The ScheduleLine package 30218B includes aScheduleLine entity 30202C. There is a 1:c relationship 30204C betweenthe Item entity 30220B and the ScheduleLine entity 30202C.

A ScheduleLine is a line containing the quantity and date of theperformance schedule requested by the buyer in an RFQ. The ScheduleLineentity 30202C is of type GDT: RFQItemScheduleLine. The ScheduleLineentity 30202C includes a DeliveryPeriod entity 30206C. There is a 1:1relationship 30208C between the ScheduleLine entity 30202C and theDeliveryPeriod entity 30206C.

The ScheduleLine entity 30202C includes an ID, a DeliveryPeriod, and aQuantity. The ID is the ScheduleLine number assigned by the procurementsystem. The ID is of type GDT:BusinessTransactionDocumentItemScheduleLineID. The DeliveryPeriod is theperiod in which the buyer expects a product to be delivered or serviceprovided. The DeliveryPeriod is of type GDT: DateTimePeriod. TheQuantity is the RFQ quantity or the target quantity in contractualnegotiations. The Quantity is of type GDT: Quantity.

In one implementation, one ScheduleLine is allowed for each RFQ item.When used more than once, the information in the ScheduleLine andDeliveryInformation is consistent (for example, if used twice, thedelivery date is identical in both cases). The ID is optional; aprocurement system does not have to number the ScheduleLine entities.

(3) Message Data Type RFQ Cancellation Message The message data typeRFQCancellationMessage groups together the business information relevantfor sending a business document in a message and the RFQCancellationobject in the document. As depicted in FIG. 303, the RFQMessage package30302 includes a MessageHeader package 30304, an RFQCancellation package30306, and an RFQCancellationMessage entity 30308. The message data typeRFQCancellationMessage makes the structure available for the messagetype RFQCancellationRequest and the relevant interfaces.

(a) Message Header Package

The MessageHeader package 30304 includes a MessageHeader entity 30310.There is a 1:1 relationship 30312 between the RFQCancellationMessageentity 30308 and the MessageHeader entity 30310. The MessageHeaderentity 30310 includes a SenderParty entity 30314 and a RecipientPartyentity 30316. There is a 1:c relationship 30318 between theMessageHeader entity 30310 and the SenderParty entity 30314. There is a1:cn relationship 30320 between the MessageHeader entity 30310 and theRecipientParty entity 30316.

(b) RFQ Cancellation Package

The RFQCancellation package 30306 groups together the RFQCancellations.The RFQCancellation is a cancellation of an RFQ from a buyer to abidder.

The RFQCancellation package 30306 includes an RFQCancellation entity30322. There is a 1:1 relationship 30324 between theRFQCancellationMessage entity 30308 and the RFQCancellation entity30322. The RFQCancellation entity 30322 is of type GDT: RFQCancellation.The RFQCancellation entity 30322 includes an ID, which is a uniqueidentifier specified by the buyer for the RFQ. The ID is of type GDT:BusinessTransactionDocumentID.

(4) Message Data Type Quote Message

The message data type QuoteMessage groups together the businessinformation relevant for sending a business document in a message andthe Quote object in the document. As depicted in FIG. 304, theQuoteMessage package 30402 includes a MessageHeader package 30404, aQuote package 30406, and a QuoteMessage entity 30408. The message datatype QuoteMessage makes the structure available for the message typeQuoteNotification and the relevant interfaces.

(a) Message Header Package

The MessageHeader package 30404 includes a MessageHeader entity 30410.There is a 1:1 relationship 30412 between the QuoteMessage entity 30408and the MessageHeader entity 30410. The MessageHeader entity 30410includes a SenderParty entity 30414 and a RecipientParty entity 30416.There is a 1:c relationship 30418 between the MessageHeader entity 30410and the SenderParty entity 30414. There is a 1:cn relationship 30420between the MessageHeader entity 30410 and the RecipientParty entity30416.

(b) Quote Package

The Quote package 30406 includes a Party package 30422, a Locationpackage 30424, a DeliveryInformation package 30426, a PaymentInformationpackage 30428, a ProductInformation package 30430, a PriceSpecificationpackage 30435, a BusinessTransactionDocumentReference package 30432, anAttachment package 30434, a Description package 30436, and an Itempackage 30438. The Quote package 30406 also includes a Quote entity30440. There is a 1:1 relationship 30442 between the QuoteMessage entity30408 and the Quote entity 30440.

The Quote is a quotation submitted by a bidder to a buyer in response toan RFQ issued for a product by the buyer. The Quote entity 30440 issubdivided into QuoteItems, which contain the concrete quotationsubmitted by the bidder with reference to the relevant item in thebuyer's RFQ. The structure of the packages in the Quote is the same asthe structure of the packages in the RFQ. The Quote entity 30440 is oftype GDT: Quote. The Quote entity 30440 includes an ID, aPostingDateTime, a LastChangeDateTime, a BindingDateTime, a Note, and aContractTargetAmount. The ID is a unique identifier specified by thebuyer for the quotation. The ID is of type GDT:BusinessTransactionDocumentID. The PostingDateTime is the creationdate/time of the quotation at the bidder. The PostingDateTime is of typeGDT: DateTime. The LastChangeDateTime is the date/time of the lastchange made to the quotation by the bidder. The LastChangeDateTime is oftype GDT: DateTime. The BindingDateTime is the date/time up to whichbidders are bound to the quotations they have submitted. TheBindingDateTime is of type GDT: DateTime. The Note is a shortdescription or the title of the quotation. It is generally used toprovide the user with a simple method for searching for a particularquotation. The Note is of type GDT: Note. The ContractTargetAmount isthe target amount in contractual negotiations. The ContractTargetAmountis of type GDT: Amount. In one implementation, the Quote entity 30440 isused as a quotation from a bidder who has taken the initiative to submita quotation without an RFQ being issued beforehand.

(i) Quote Party Package

The Party package 30422 groups together the business parties that occurin one of the Quote messages. The Party package 30422 includes aBuyerParty entity 30444, a BidderParty entity 30446, aBidderPortalProviderParty entity 30448, a ProductRecipientParty entity30450, a VendorParty entity 30452, a ManufacturerParty entity 30454, anda PayerParty entity 30456. There is a respective 1:c relationship 30458,30460, 30462, 30464, 30466, 30468, and 30470 between the Quote entity30440 and the BuyerParty entity 30444, the BidderParty entity 30446, theBidderPortalProviderParty entity 30448, the ProductRecipientParty entity30450, the VendorParty entity 30452, the ManufacturerParty entity 30454,and the PayerParty entity 30456.

The BuyerParty entity 30444 includes an Address entity 30472 and aContact entity 30474. There is a 1:c relationship 30476 between theBuyerParty entity 30444 and the Address entity 30472, and a 1:crelationship 30478 between the BuyerParty entity 30444 and the Contactentity 30474.

The Address entity 30472 includes a PersonName entity 30480, an Officeentity 30482, a PhysicalAddress entity 30484, a GeoCoordinates entity30486, and a Communication entity 30488. There is a respective 1:crelationship 30490, 30492, 30494, 30496, and 30498 between the Addressentity 30472 and the PersonName entity 30480, the Office entity 30482,the PhysicalAddress entity 30484, the GeoCoordinates entity 30486, andthe Communication entity 30488.

The Contact entity 30474 includes an Address entity 30400A. There is a1:c relationship 30402A between the Contact entity 30474 and the Addressentity 30400A.

The Address entity 30400A includes a PersonName entity 30404A, an Officeentity 30406A, a PhysicalAddress entity 30408A, a GeoCoordinates entity30410A, and a Communication entity 30412A. There is a respective 1:crelationship 30414A, 30416A, 30418A, 30420A, and 30422A between theAddress entity 30400A and the PersonName entity 30404A, the Officeentity 30406A, the PhysicalAddress entity 30408A, the GeoCoordinatesentity 30410A, and the Communication entity 30412A.

Each of the BidderParty entity 30446, the BidderPortalProviderPartyentity 30448, the ProductRecipientParty entity 30450, the VendorPartyentity 30452, the ManufacturerParty entity 30454, and the PayerPartyentity 30456 includes the same elements as that described above for theBuyerParty entity 30444, as denoted by ellipses 30424A, 30426A, 30428A,30430A, 30432A, and 30434A.

(ii) Quote Location Package

A Location package 30424 groups together the locations that can occur inone of the Quote messages. The Location package 30424 includes aShipToLocation entity 30436A. There is a 1:c relationship 30438A betweenthe Quote entity 30440 and the ShipToLocation entity 30436A. TheShipToLocation entity 30436A includes an Address entity 30440A. There isa 1:c relationship 30442A between the ShipToLocation entity 30436A andthe Address entity 30440A.

The Address entity 30440A includes a PersonName entity 30444A, an Officeentity 30446A, a PhysicalAddress entity 30448A, a GeoCoordinates entity30450A, and a Communication entity 30452A. There is a respective 1:crelationship 30454A, 30456A, 30458A, 30460A, and 30462A between theAddress entity 30440A and the PersonName entity 30444A, the Officeentity 30446A, the PhysicalAddress entity 30448A, the GeoCoordinatesentity 30450A, and the Communication entity 30452A.

(iii) Quote Delivery Information Package

A DeliveryInformation package 30426 groups together the informationabout a required delivery in a Quote process. The DeliveryInformationpackage 30426 includes a DeliveryTerms entity 64A. There is a 1:crelationship 30466A between the Quote entity 30440 and the DeliveryTermsentity 30464A.

The DeliveryTerms entity 30464A includes an Incoterms entity 30468A.There is a 1:c relationship 30470A between the DeliveryTerms entity30464A and the Incoterms entity 30468A.

(iv) Quote Payment Information Package

A PaymentInformation package 30428 groups together the paymentinformation in a Quote process. The PaymentInformation package 30428includes a CashDiscountTerms entity 30472A and a PaymentForm entity30474A. There is a 1:c relationship 30476A between the Quote entity30440 and the CashDiscountTerms entity 30472A, and a 1:c relationship30478A between the Quote entity 30440 and the PaymentForm entity 30474A.

(v) Quote Price Information package

The PriceInformation package 30435 groups together all price informationin a quotation item. It contains a PriceSpecification Element 30493A.The PriceInformation package 30435 for an RFQ item contains only prices;it does not contain any information about how the prices are calculated(pricing scales, and so on).

(vi) Quote Product Information Package

The ProductInformation package 30430 groups together the productcategory. The ProductInformation package 30430 includes aProductCategory entity 30480A. There is a 1:c relationship 30482Abetween the Quote entity 30440 and the ProductCategory entity 30480A.

(vii) Quote Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 30432 groups togetherthe business document references that can occur in the Quote message.The BusinessTransactionDocumentReference package 30432 includes anRFQReference entity 30484A. There is a 1:c relationship 30486A betweenthe Quote entity 30440 and RFQReference entity 30484A.

The RFQReference is a reference to a request for quotation or item in arequest for quotation. The RFQReference entity 30484A is of type GDT:BusinessTransactionDocumentReference. In one implementation, anRFQReference entity 30484A can reference one RFQ, that is, one ID ispermissible. As far as the referenced RFQ is concerned, there are noconflicts with an RFQReference at the item level. If a reference is usedat both the header and item levels, it refers to one (the same) RFQ.

In one implementation, the reference to an RFQ is required at both theheader and item levels, since RFQs do not always have item data. Unlessotherwise agreed, the bidder uses the RFQID assigned by the buyer.

(viii) Quote Attachment Package

The Attachment package 30434 groups together the attachment informationregarding the Quote. The Attachment package 30434 includes an Attachmententity 30488A. The Attachment is any document that refers to the Quote.The Attachment entity 30488A is of type GDT: Attachment. There is a 1:cnrelationship 30490A between the Quote entity 30440 and the Attachmententity 30488A.

(ix) Quote Description Package

The Description package 30436 groups together the texts regarding theQuote. The Description package 30436 includes a Description entity30492A. The Description entity 30492A is of type GDT: Description. Thereis a 1:c relationship 30494A between the Quote entity 30440 and theDescription entity 30492A.

(x) Quote Item Package

A QuoteItem package 30438 includes a QuoteItem entity 30496A. There is a1:cn relationship 30498A between the Quote entity 30440 and theQuoteItem entity 30496A.

QuoteItem entities are arranged hierarchically using a HierarchyRelationship 30400B. The Hierarchy Relationship 30400B is therelationship between a sub-item and a higher-level parent item in anitem hierarchy. There is a 1:cn relationship 30402B between the Itementity 30496A and its subordinate entities, and there is a 1:crelationship 30404B between the Item entity 30496A and its superordinateentities.

The QuoteItem includes the bidder's quotation for a product tendered inan item of a request for quotation (RFQItem) or additional informationabout this product. Quantities and delivery dates can also be specifiedhere. The structure is the same as the structure of the RFQItem. TheQuoteItem entity 30496A is of type GDT: QuoteItem. The QuoteItem entity30496A includes an ID and a ContractTargetAmount. The ID is a uniqueidentifier specified by the buyer for a quotation item within an RFQ.The ID is of type GDT: BusinessTransactionDocumentItemID. TheContractTargetAmount is the target amount in contractual negotiations.The ContractTargetAmount is of type GDT: Amount.

The QuoteItem package 30438 also includes a ProductInformation package30406B, a PriceInformation package 30408B, a Party package 30410B, aLocation package 30412B, a DeliveryInformation package 30414B, aBusinessTransactionDocumentReference package 30416B, an Attachmentpackage 30418B, a Description package 30420B, and a ScheduleLine package30422B.

(a) Quote Item Product Information Package

A ProductInformation package 30406B groups together the product and theproduct category. The ProductInformation package 30406B includes aProduct entity 30424B and a ProductCategory entity 30426B. There is a1:c relationship 30428B between the Item entity 30496A and the Productentity 30424B, and a 1:c relationship 30430B between the Item entity30496A and the ProductCategory entity 30426B.

(b) Quote Item Price Information Package

The PriceInformation package 30408B groups together all priceinformation in a quotation item. It contains a PriceSpecificationElement 30432B. The PriceInformation package 30408B for an RFQ itemcontains only prices; it does not contain any information about how theprices are calculated (pricing scales, and so on).

(c) Quote Item Party Package

The Party package 30410B includes a BuyerParty entity 30436B, aBidderParty entity 30438B, a ProductRecipientParty entity 30440B, aVendorParty entity 30442B, and a ManufacturerParty entity 30444B. Thereis a respective 1:c relationship 30446B, 30448B, 30450B, 30452B, and30454B between the Item entity 30496A and the BuyerParty entity 30436B,the BidderParty entity 30438B, the ProductRecipientParty entity 30440B,the VendorParty entity 30442B, and the ManufacturerParty entity 30444B.Each of the BuyerParty entity 30436B, the BidderParty entity 30438B, theProductRecipientParty entity 30440B, the VendorParty entity 30442B, andthe ManufacturerParty entity 30444B includes the same elements as thatdescribed above for the BuyerParty entity 30444 as denoted by ellipses30456B, 30458B, 30460B, 30462B, and 30464B. In one implementation, theQuote is used as a quotation from a bidder who has taken the initiativeto submit a quotation without an RFQ being issued beforehand.

(d) Quote Item Location Package

Similar to the Location package 30224 at the header level, the Locationpackage 30412B at the item level includes a ShipToLocation entity30466B. There is a 1:c relationship 30468B between the Item entity30496A and the ShipToLocation entity 30466B. The ShipToLocation entity30488B includes the same elements as that described above for theShipToLocation entity 36A as denoted by ellipses 30470B.

(e) Quote Item Delivery Information Package

Similar to the DeliveryInformation package 30426 at the header level,the DeliveryTerms package 30414B at the item level includes aDeliveryTerms entity 30472B. There is a 1:c relationship 30474B betweenthe Item entity 30496A and the DeliveryTerms entity 30472B. TheDeliveryTerms entity 30472B includes an Incoterms entity 30476B. Thereis a 1:c relationship 30478B between the DeliveryTerms entity 30472B andthe Incoterms entity 30476B.

(f) Quote Item Business Transaction Document Reference Package

A BusinessTransactionDocumentReference package 30416B groups togetherthe business document references that can occur in the QuoteNotificationmessage. It includes an RFQReference entity 30480B. There is a 1:crelationship 30482B between the Item entity 30496A and the RFQReferenceentity 30480B.

An RFQReference is a reference to the RFQ or the item within the RFQ.The RFQReference entity 30480B is of type GDT:BusinessTransactionDocumentReference.

In one implementation, an RFQReference entity 30480B can reference oneitem, that is, one ItemID is permissible. As far as the referenced RFQis concerned, there are no conflicts with an RFQReference at the headerlevel. If an RFQ reference is maintained at both header and item level,it refers to one (the same) RFQ. Unless otherwise agreed, the bidderuses the RFQID and RFQItemID assigned by the buyer.

(g) Quote Item Attachment Package

The QuoteItemAttachment package 30418B includes an Attachment entity30484B. There is a 1:c relationship 30486B between the Item entity30496A and the Attachment entity 30484B.

(h) Quote Item Description Package

The QuoteItemDescription package 30420B includes a Description entity30488B. There is a 1:c relationship 30490B between the Item entity30496A and the Description entity 30488B.

(i) Quote Item Schedule Line Package

The QuoteItemScheduleLinePackage 30422B includes a ScheduleLine entity30492B. There is a 1:c relationship 30494B between the Item entity30496A and the ScheduleLine entity 30492B. The ScheduleLine entity30492B includes a DeliveryPeriod entity 30496B. There is a 1:1relationship 30498B between the ScheduleLine entity 30492B and theDeliveryPeriod entity 30496B.

(5) Message Data Type RFQ Result Message

The message data type RFQResultMessage groups together the businessinformation relevant for sending a business document in a message andthe RFQResult object in the document. As depicted in FIG. 305, theRFQResultMessage package 30502 includes a MessageHeader package 30504and a RFQResult package 30506. The RFQResultMessage package 30502 alsoincludes an RFQResultMessage entity 30508. The message data typeRFQResultMessage makes the structure available for the message typeRFQResultMessage and the relevant interfaces.

(a) Message Header Package

The MessageHeader package 30504 includes a MessageHeader entity 30510.There is a 1:1 relationship 30512 between the RFQResultMessage entity30508 and the MessageHeader entity 30510. The MessageHeader entity 30510includes a SenderParty entity 30514 and a RecipientParty entity 30516.There is a 1:c relationship 30518 between the MessageHeader entity 30510and the SenderParty entity 30514, and a 1:cn relationship 30520 betweenthe MessageHeader entity 30510 and the RecipientParty entity 30516.

(b) RFQ Result Package

The RFQResult package 30506 includes a Party package 30522, aDescription package 30524, and an Item package 30526. The RFQResultpackage 30506 also includes an RFQResult entity 30528. There is a 1:1relationship 30529 between the RFQResultMessage entity 30508 and theRFQResult entity 30528. The RFQResult is the acceptance or rejection ofa bidder's quotation by the buyer. The RFQResult entity 30528 is of typeGDT: RFQResult. The RFQResult entity 30528 includes an ID, which is aunique identifier specified by the buyer for the RFQ.

(i) RFQ Result Party Package

The Party package 30522 groups together the parties that can occur inone of the RFQResult messages. The Party package 30522 includes aBidderParty entity 30530. There is a 1:c relationship 30532 between theRFQResult entity 30528 and the BidderParty entity 30530.

A BidderParty is a party that bids for goods or services. TheBidderParty entity 30530 is of type GDT:BusinessTransactionDocumentParty. The BidderParty entity 30530 isrequired for the RFQResult message if the result of the RFQ is to bepublished on a tendering platform. The configuration determines whetherthis scenario applies.

(ii) RFQ Result Description Package

The RFQ Result Description package 30524 includes a Description entity30534. There is a 1:c relationship 30536 between the RFQResult entity30528 and the Description entity 30534.

(iii) RFQ Result Item Package

The RFQResultItem package 30526 includes aBusinessTransactionDocumentReference package 30538 and a ScheduleLinepackage 30540. The RFQResultItem package 30526 also includes anRFQResultItem entity 30542. There is a 1:cn relationship 30544 betweenthe RFQResult entity 30528 and the RFQResultItem entity 30542.RFQResultItem entities are arranged hierarchically using a HierarchyRelationship 30546. The Hierarchy Relationship 30546 is the relationshipbetween a sub-item and a higher-level parent item in an item hierarchy.There is a 1:cn relationship 30548 between the Item entity 30542 and itssubordinate entities, and there is a 1:c relationship 30550 between theItem entity 30542 and its superordinate entities.

An RFQResultItem specifies the rejection or the extent of the acceptanceof a bidder's quotation for a product of an RFQ item. The RFQResultItementity 30542 is of type GDT: RFQResultItem. The RFQResultItem entity30542 includes an ID, which is an identifier assigned by the buyer to anRFQ item. The identifier is unique within a particular RFQ. The ID is oftype GDT: BusinessTransactionDocumentItemID.

(a) RFQ Result Item Business Transaction Document Reference Package

A BusinessTransactionDocumentReference package 30538 groups together thebusiness document references that occur in one of the RFQResultmessages. The BusinessTransactionDocumentReference package 30538includes a QuoteReference entity 30552. There is a 1:c relationship30554 between the Item entity 30542 and the QuoteReference entity 30552.

The QuoteReference is a reference to the quotation or the item withinthe quotation. The QuoteReference entity 30552 is of type GDT:BusinessTransactionDocumentReference. In one implementation, aQuoteReference entity 30552 can reference one item, that is, one ItemIDis permissible.

(b) RFQ Result Item Schedule Line Package

The RFQResultItemScheduleLine Package 30540 includes a ScheduleLineentity 30558. There is a 1:c relationship 30560 between the Item entity30542 and the ScheduleLine entity 30558. The ScheduleLine entity 30558includes a DeliveryPeriod entity 30562. There is a 1:1 relationship30564 between the ScheduleLine entity 30558 and the DeliveryPeriodentity 30562.

(6) Message Data Type Element Structure

(a) Data Type RFQ Message

FIGS. 306A-O depict the element structure for RFQRequest andRFQChangeRequest. The element structure is similar to the data model,but provides additional information regarding the details of theinterface. The element structure identifies the different packages 30600in the interface, and represents the entities at various levels withinthe interface. As depicted in FIGS. 306A-O, the interface for RFQRequestand RFQChangeRequest includes six levels 30602, 30604, 30606, 30608,30610, and 30612. The element structure identifies the cardinality oroccurrence 30614 between the entities and/or attributes of theinterface, and provides information (i.e., type 30616 and name 30618)regarding the data type that provides the basis for the entity and/orattribute. The outermost package of this interface is an RFQMessagepackage 30620, which includes an RFQMessage entity 30622 at the firstlevel 30602. The RFQMessage entity 30622 is of type message data type(“MDT”) 30624 “RFQMessage” 30626.

The RFQMessage package 30620 includes a MessageHeader package 30628 andan RFQ package 30630. The MessageHeader package 30628 includes aMessageHeader entity 30632, which is of type generic data type (“AGDT”)30636 “BusinessDocumentMessageHeader” 30638. There is one 30634MessageHeader entity 30632 for each RFQMessage entity 30622.

The MessageHeader entity 30632 includes an ID 30640, a Reference ID30648, and a CreationDateTime 30656. The ID 30640 is of type GDT 30644BusinessDocumentMessageID 30646. The ReferenceID 30648 is of type GDT30652 BusinessDocumentMessageID 30654. The CreationDateTime 30656 is oftype GDT 30660 DateTime 30662. There is one 30642 ID 30640 for eachMessageHeader entity 30632, one or zero 30650 ReferenceID 30648 for eachMessageHeader entity 30632, and one 30658 CreationDateTime 30656 foreach MessageHeader entity 30632.

The MessageHeader entity 30632 also includes a SenderParty entity 30664and a RecipientParty entity 30628A. The SenderParty entity 30664 is oftype AGDT 30668 BusinessDocumentMessageHeaderParty 30670. TheRecipientParty entity 30628A is also of type AGDT 30632ABusinessDocumentMessageHeaderParty 30634A. There is one or zero 30666SenderParty entity 30664 for each MessageHeader entity 30632, and thereis any number 30630A of RecipientParty entities 30628A for eachMessageHeader entity 30632.

The SenderParty entity 30664 includes an InternalID 30672, a StandardID30680, and a ContactPerson 30688. The InternalID 30672 has zero or oneoccurrences 30674 for each SenderParty entity 30664 and a data type CDT30676 of PartyInternalID 30678. The StandardID 30680 has any numberoccurrences 30682 for each SenderParty entity 30664 and has a data typeof CDT 30684 PartyStandardID 30686. The ContactPerson 30688 has zero orone occurrences 30690 for each SenderParty entity 30664 and is of datatype AGDT 30692 ContactPerson 30694. The ContactPerson 30688 alsoincludes an InternalID 30696, BuyerID 30604A, BidderID 30612A, and anAddress 30620A. The InternalID 30696 has any number occurrences 30698for each ContactPerson 30688 and a data type of CDT 30600AContactPersonInternalID 30694. The BuyerID 30604A has zero or oneoccurrences 30606A for each ContactPerson 30688 and a data type of CDT30608A ContactPersonPartyID 30610A. The BidderID 30612A has zero or oneoccurrences 30614A for each ContactPerson 30688 and a data type of CDT30616A ContactPersonPartyID 30618A. The Address 30620A has one or zerooccurrences 30622A for each ContactPerson 30688 and a data type of AGDT30624A Address 30626A.

The RFQ package 30630 includes an RFQ entity 30636A. There is one 30638ARFQ entity 30636A for each RFQMessage entity 30622. The RFQ entity30636A has a data type of AGDT 30640A BusinessTransactionDocumentID30642A. The RFQ entity 30636A includes an ID 30644A, a PostingDateTime30652A, a LastChangeDateTime 30630A, a PublishDateTime 30668A, aDisplayDateTime 30676A, an BiddingStartDateTime 30684A,QuoteSubmissionDateTime 30692A, QuoteOpeningDateTime 30600B,QuoteBindingDateTime 306708B, ContractValidityPeriod 30616B, a Note30624B, an RFQPublicIndicator 30632B, a QuoteUnplannedItemPernissionCode30640B, a QuotePriceBiddingConditionCode 30648B, aQuoteQuantityBiddingConditionCode 30656B, aQuoteItemBiddingConditionCode 30664B, and ContractTargetAmount 30672B.

There is one 30646A ID 30644A for each RFQ entity 30636A. The ID 30644Ais of type GDT 30648A BusinessTransactionDocumentID 30650A. APostingDateTime 30652A has zero or one occurrences 30654A for each RFQentity 30636A and is of type GDT 30656A DateTime 30658A. A VersionID30641A has one occurrence 30643A for each RFQ entity 30636A and is oftype GDT 30645A VersionID 30647A. LastChangeDateTime 30660A has zero orone occurrences 30662A for each RFQ entity 30636A and is of type GDT30664A DateTime 30666A. PublishDateTime 30668A has zero or oneoccurrences 30670A for each RFQ entity 30636A and is of type GDT 30672ADateTime 30674A. DisplayDateTime 30676A has zero or one occurrences30678A for each RFQ entity 30636A and is of type GDT 30680A DateTime30682A. BiddingStartDateTime 30684A has zero or one occurrences 30686Afor each RFQ entity 30636A and is of type GDT 30688A DateTime 30690A.QuoteSubmissionDateTime 30692A has one occurrence 30694A for each RFQentity 30636A and is of type GDT 30696A DateTime 30698A.QuoteOpeningDateTime 30600B has zero or one occurrences 30602B for eachRFQ entity 30636A and is of type GDT 30604B DateTime 30606B.QuoteBindingDateTime 30608B has zero or one occurrences 30610B for eachRFQ entity 30636A and is of type GDT 30612B DateTime 30614B.ContractValidityPeriod 30616B has zero or one occurrences 30618B foreach RFQ entity 30636A and is of type GDT 30620B DateTimePeriod 30622B.Note 30624B has zero or one occurrences 30626B for each RFQ entity30636A and is of type GDT 30628B Note 30630B. RFQPublicIndicator 30632Bhas one occurrence 30634B for each RFQ entity 30636A and is of type GDT30636B BusinessTransactionDocumentPublicIndicator 30638B.QuoteChargeAllowIndicator 30641B has zero to one occurrence 30643B foreach RFQ entity 30636A and is of type GDT 30645B AllowIndicator 30647B.QuoteUnplannedItemPermissionCode 30640B has zero or one occurrences30642B for each RFQ entity 30636A and is of type GDT 30644BUnplannedItemPermissionCode 30646B. QuotePriceBiddingConditionCode30648B has zero or one occurrences 30650B for each RFQ entity 30636A andis of type GDT 30652B BiddingConditionCode 30654B, theQuoteQuantityBiddingConditionCode 30656B has one occurrence 30658B foreach RFQ entity 30636A and is of type GDT 30660B BiddingConditionCode30662B. RequestedQuoteCurrencyCode 30661B has one to n occurrences30663B for each RFQ entity 30636A and a data type GDT 30665BCurrencyCode 30667B. QuoteItemBiddingConditionCode 30664B has oneoccurrence 30666B for each RFQ entity 30636A and a data type GDT 30668BBiddingConditionCode 30670B, and ContractTargetAmount 30672B has zero orone occurrences 30674B for each RFQ entity 30636A and is of type GDT30676B Amount 30678B.

The Party package 30680B includes a BuyerParty entity 30600C, aBidderParty entity 30672C, a BidderPortalPartyProvider entity 30680C, aProductRecipientParty entity 30688C, a VendorParty entity 30696C, aManufacturerParty entity 30604D, and a PayerParty entity 30612D.

The BuyerParty entity 30600C is of type AGDT 30604CBusinessTransactionDocumentParty 30606C. There is one or zero 30602CBuyerParty entity 30600C for each RFQ entity 30636A. The BidderPartyentity 30672C is of type AGDT 30676C BusinessTransactionDocumentParty30678C. There is zero or one 30674C BidderParty entity 30672C for eachRFQ entity 30636A. The BidderPortalPartyProvider entity 30680C is oftype AGDT 30684C BusinessTransactionDocumentParty 30686C. There is zeroor one 30682C BidderPortalPartyProvider entity 30680C for each RFQentity 30636A. The ProductRecipientParty entity 30688C is of type AGDT30692C BusinessTransactionDocumentParty 30694C. There is one or zero30690C ProductRecipientParty entity 30688C for each RFQ entity 30636A.The VendorParty entity 30696C is of type AGDT 30600DBusinessTransactionDocumentParty 30602D. There is one or zero 30698CVendorParty entity 30696C for each RFQ entity 30636A. TheManufacturerParty entity 30604D is of type AGDT 30608DBusinessTransactionDocumentParty 30610D. There is one or zero 30606DManufacturerParty entity 30604D for each RFQ entity 30636A. ThePayerParty entity 30612D is of type AGDT 30616DBusinessTransactionDocumentParty 30618D. There is one or zero 30614DPayerParty entity 30612D for each RFQ entity 30636A.

The BuyerParty entity 30600C includes a StandardID 30608C, a BuyerID30616C, a BidderID 30624C, an Address 30632C, and a ContactPerson30640C. The StandardID 30608C has any number occurrences 30610C for eachBuyerParty entity 30600C and a data type of CDT 30612C PartyStandardID30614C. The BuyerID 30616C has zero or one occurrences 30618C for eachBuyerParty entity 30600C and a data type of CDT 30620C PartyPartyID30622C. The BidderID 30624C has zero or one occurrences 30626C for eachBuyerParty entity 30600C and a data type of CDT 30628C PartyPartyID30630C. The Address 30632C has zero or one occurrences 30634C for eachBuyerParty entity 30600C and a data type of AGDT 30636C Address 30638C.The ContactPerson 30640C has zero or one occurrences 30642C for eachBuyerParty entity 30600C and a data type of AGDT 30644C ContactPerson30646C. The ContactPerson 30640C also includes a BuyerID 30648C,BidderID 30656C and an Address 30664C. The BuyerID 30648C has zero orone occurrences 30650C for each ContactPerson 30640C and a data type ofCDT 30652C ContactPersonPartyID 30654C. The BidderID 30656C has zero orone occurrences 30658C for each ContactPerson 30640C and a data type ofCDT 30660C ContactPersonPartyID 30662C. The Address 30664C has one orzero occurrences 30666C for each ContactPerson 30640C and a data type ofAGDT 30668C Address 30670C.

The Location package 30682B includes a ShipToLocation entity 30620D. TheShipToLocation entity 30620D is of type AGDT 30624DBusinessTransactionDocumentLocation 30626D. There is one or zero 30622DShipToLocation entity 30620D for each RFQ entity 30636A. TheShipToLocation entity 30620D includes a StandardID 30628D, a BuyerID30636D, a BidderID 30644D, and an Address 30652D. The StandardID 30628Dhas any number occurrences 30630D for each ShipToLocation entity 30620Dand a data type of CDT 30632D LocationStandardID 30634D. The BuyerID30636D has zero or one occurrences 30638D for each ShipToLocation entity30620D and a data type of CDT 30640D LocationPartyID 30642D. TheBidderID 30644D has zero or one occurrences 30646D for eachShipToLocation entity 30620D and a data type of CDT 30648DLocationPartyID 30650D. The Address 30652D has zero or one occurrences30654D for each ShipToLocation entity 30620D and a data type of AGDT30656D Address 30658D.

The DeliveryInformation package 30684D includes a DeliveryTerms entity30660D. The DeliveryTerms entity 30660D is of type AGDT 30664DDeliveryTerms 30666D. There is one or zero 30662D Delivery Terms entity30660D for each RFQ entity 30636A. The DeliveryTerms entity 30660Dincludes an Incoterms entity 30668D, which is of type GDT 30672DIncoterms 30674D. There is one or zero 30670D Incoterms entity 30668 foreach DeliveryTerms entity 30660D.

The PaymentInformation package 30684D includes a CashDiscountTermsentity 30676D, which is of type AGDT 30680D CashDiscountTerms 30682D.There is one or zero 30678D CashDiscountTerms entity 30676D for each RFQentity 30636A.

The PaymentInformation package 30684B also includes a PaymentForm entity30604E. There is one or zero 30606E PaymentForm entity 30684B for eachRFQ entity 30636A. The PaymentForm entity 30604E includes a Code 30608Ethat is of type GDT 30612E PaymentFormCode 30614E. There is one 30610ECode 30608E for each PaymentForm entity 30604E.

The CashDiscountTerms entity 30676D includes a MaximumCashDiscountentity 30684D, and a NormalCashDiscount entity 30692D, andFullPaymentDueDaysValue entity 30600E. There is one or zero occurrences30686D of the MaximumCashDiscount entity 30684D for eachCashDiscountTerms entity 30676D. The MaximumCashDiscount entity 30684Dis of type GDT 30688D CashDiscount 30690D. There is one or zerooccurrences 30694D of the NormalCashDiscount entity 30692D for eachCashDiscountTerms entity 30676D. The NormalCashDiscount entity 30692D isof type GDT 30696D CashDiscount 30698D. There is one or zero occurrences30602E of the FullPaymentDueDaysValue entity 30600E for eachCashDiscountTerms entity 30676D.

The PriceInformation package 30681B includes a PriceSpecificationElemententity 30607E. The PriceSpecificationElement entity 30607E is of typeGDT 30611E PriceSpecificationElement 30613E. There is one or n 30609EPriceSpecificationElement entity 30607E for each RFQ entity 30636A.

The ProductInformation package 30688B includes a ProductCategory entity30616E. The ProductCategory entity 30616E is of type GDT 30620E.BusinessTransactionDocumentProductCategory 30622E. There is one or zero30618E ProductCategory entity 30616E for each RFQ entity 30636A. TheProductCategory entity 30616E includes a StandardID 30624E, a BuyerID30632E, and a BidderID 30640E. The StandardID 30624E of has any numberoccurrences 30626E for each ProductCategory entity 30616E and a datatype of CDT 30628E ProductCategoryStandardID 30630E. The BuyerID 30632Ehas zero or one occurrences 30634E for each ProductCategoryStandard30616E and a data type of CDT 30636E ProductCategoryPartyID 30638E. TheBidderID 30640E has zero or one occurrences 30642E and a data type ofCDT 30644E ProductCategoryPartyID 30646E.

The BusinessTransactionDocumentReference package 30690B includes aQuoteReference entity 30648E. The QuoteReference entity 30648E is oftype GDT 30652E BusinessTransactionDocumentReference 30654E. There isone or zero 30650E QuoteReference entities 30648E for each RFQ entity30636A. The QuoteReference entity 30648E include an ID 30656E, and thereis one occurrence 30658E of the ID 30656E for each Quote by 30648E. TheID is of type GDT 30660E BusinessTransactionID 30662E.

The FollowUpBusinessTransactionDocument package 30692B includes aFollowUpPurchaseOrder entity 30664E and a FollowUpPurchaseDocument30676E. There is zero or one occurrence 30666E of theFollowUpPurchaseOrder entity 30664E for each RFQ entity 30636A and oneor zero occurrences 30678E of the FollowUpPurchaseDocument entity 30676Efor each RFQ entity 30636A. The FollowUpPurchaseOrder entity 30664Eincludes a RequirementCode 30668E which has one occurrence 30670E foreach RFQ entity 30636A and is of type GDT 30672EFollowUpBusinessTransactionDocumentRequirementCode 30674E. TheFollowUpPurchaseDocument entity 30676E includes a RequirementCode entity30680E which has one occurrence 30682E for each FollowUpPurchaseDocumententity 30676E and is of type GDT 30684EFollowUpBusinessTransactionDocumentRequirementCode 30686E.

The Attachment package 30694B includes an Attachment entity 30688E,which is of type GDT 30692E Attachment 30694E. There is any number30690E Attachment entities 30688E for each RFQ entity 30636A.

The Description package 30696B includes a Description entity 30696B. TheDescription entity 30696E is of type GDT 30600F Description 30602F.There is one or zero 30698E Description entities 30696E for each RFQentity 30636A.

The Item package 30698B includes an Item entity 30604F which is of typeAGDT 30608F RFQItem 30616F. There is any number 30606F or Item entities30604F for each RFQ entity 30636A. The Item entity 30604F includes an ID30612F, a ContractTargetAmount 30620F, and a HierarchyRelationship30628F. The ID 30612F is of type GDT 30616FBusinessTransactionDocumentItemID 30618F, and there is one 30614F ID30612F for each Item entity 30604F. The ContractTargetAmount 30620F isof type GDT 30624F Amount 30626F, and there is one or zero 30622FContractTargetAmount 30620F for each Item entity 30604F. There is one orzero 30630F HierarchyRelationship 30628F for each Item entity 30604F.The HierarchyRelationship 30628F includes a ParentItemID 30632F, whichis of type GDT 30636F BusinessTransactionDocumentItemID 30638F, and aTypeCode 30640F, which is of type GDT 30644FBusinessTransactionDocumentHierarchyRelationshipTypeCode 30646F. Thereis one 30634F ParentItemID 30632F for each HierarchyRelationship 30628F,and there is one 30642F TypeCode 30640F for each HierarchyRelationship30628F.

The Item package 30698B also includes a ProductInformation package30648F, a Party package 30656F, a Location package 30652F, aDeliveryInformation package 30654F, aBusinessTransactionDocumentReference package 30656F, a PriceInformationpackage 30649F, an Attachment package 30658F, a Description package30660F, and a ScheduleLine package 30662F.

The ProductInformation package 30648F includes a Product entity 30664Fand a ProductCategory entity 30620G. The Product entity 30664F is oftype GDT 30668F BusinessTransactionDocumentProduct 30670F. There is oneor zero 30666F Product entity 30664F for each Item entity 30604F. TheProductCategory entity 30620G is of type GDT 30624GBusinessTransactionDocumentProductCategory 30626G. There is one or zero30622G ProductCategory entity 30620G for each Item entity 30604F.

The Product entity 30664F includes a StandardID 30672F, a BuyerID30680F, a BidderID 30688F, an ManufacturerID 30696F, TypeCode 30604G anda Note 30612G. The StandardID 30672F Product entity 30664F has anynumber occurrences 30674F for each Product entity 30664F and has a datatype of CDT 30684F ProductStandardID 30686F. The BuyerID 30688F has zeroor one occurrences 30682F for each Product entity 30664F a data type ofCDT 30684F ProductPartyID 30686F. The BidderID 30688F has zero or oneoccurrences 30690F for each Product entity 30664F and a data type of CDT30692F ProductPartyID 30694F. The ManufacturerID 30696F has zero or oneoccurrences 30698F for each Product entity 30664F and a data type of CDT30600G ProductPartyID 30602G. The TypeCode 30604G has zero or oneoccurrences 30606G for each Product entity 30664F and a data type of GDT30608G ProductTypeCode 30610G. The Note 30612G has zero or oneoccurrences 30614G and a data type of GDT 30616G Note 30618G.

The ProductCategory entity 30620G includes a StandardID 30628G, aBuyerID 30636G, and a BidderID 30644G. The StandardID 30628G has anynumber of occurrences 30630G and a data type of CDT 30632GProductCategoryStandardID 30642G. The BuyerID 30636G has zero or oneoccurrences 30636G and a data type of CDT 30638G for eachProductCategory entity 30620G ProductCategoryPartyID 30642G. TheBidderID 30644G has zero or one occurrences 30646G for eachProductCategory entity 30620G and a data type of CDT 30648GProductCategoryPartyID 30650G.

The PriceInformation package 30649F includes a PriceSpecificationElemententity 30651F. The PriceSpecificationElement entity 30651F is of typeGDT 30655F PriceSpecificationElement 30657F. There is one or n 30653FPriceSpecificationElement entity 30651F for each RFQ entity 30636A.

The Party package 30650F includes a BuyerParty entity 30652G, aBidderParty entity 30660G, a ProductRecipientParty entity 30668G, aVendorParty entity 30676G, and a ManufacturerParty entity 30684G.

The BuyerParty entity 30652G is of type AGDT 30652GBusinessTransactionDocumentParty 30658G. There is one or zero 30654GBuyerParty entity 30652G for each Item entity 30604F. The BidderPartyentity 30660G is of type AGDT 30664G BusinessTransactionDocumentParty30666G. There is zero or one 30662G BidderParty entity 30660G for eachItem entity 30604F. There is zero or one 30670G ProductRecipientPartyentity 30668G for each Item entity 30604F. The ProductRecipientPartyentity 30668G is of type AGDT 30672G BusinessTransactionDocumentParty30674G. The VendorParty entity 30676G is of type AGDT 30680GBusinessTransactionDocumentParty 30682G. There is one or zero 30678GVendorParty entity 30676G for each Item entity 30604F. TheManufacturerParty entity 30684G is of type AGDT 30688GBusinessTransactionDocumentParty 30690G. There is one or zero 30686GManufacturerParty entity 30684G for each Item entity 30604F.

The Location package 30652F includes a ShipToLocation entity 30692G. TheShipToLocation entity 30692G is of type AGDT 30692GBusinessTransactionDocumentLocation 30698G. There is one or zero 30694GShipToLocation entity 30692G for each Item entity 30604F. TheShipToLocation entity 30692G includes a StandardID 30600H, a BuyerID30608H, a BidderID 30616H, and an Address 30624H. The StandardID 30600Hof the has any number of occurrences 30602 for each ShipToLocationentity 30692G and a data type of CDT 30604H LocationStandardID 30606H.The BuyerID 30608H has zero or one occurrences 30610H for eachShipToLocation entity 30692G and a data type of CDT 30612HLocationPartyID 30614H. The BidderID 30616H has zero or one occurrences30618H for each ShipToLocation entity 30692G and a data type of CDT30620H LocationPartyID 30622H. The Address 30624H has zero or oneoccurrences 30626H for each ShipToLocation entity 30692G and a data typeof AGDT 30628H Address 30630H.

The DeliveryInformation package 30654F includes a DeliveryTerms entity30632H, which is of type AGDT 30636H DeliveryTerms 30638H. There is oneor zero 30634H DeliveryTerms entity 30632H for each Item entity 30604F.The DeliveryTerms entity 30632H includes an MaximumLeadTimeDurationentity 30640H which is of type GDT 30644H Duration 30646H, and there isone or zero occurrences 30642 for each DeliveryInformation package30654F. The DeliveryTerms entity 30632H also includes an Incotermsentity 30648H which is of type GDT 30652H Incoterms 30654H. There is oneor zero 30650H Incoterms entity 30648H for each DeliveryInformationpackage 30654F.

The BusinessTransactionDocumentReference package 30656F includes aQuoteReference entity 30656H. The QuoteReference entity 30656H is oftype GDT 30660H BusinessTransactionDocumentReference 30662H. There isone or zero 30658H QuoteReference entities 30656H for each Item entity30604F. The QuoteReference entity 30686H includes an ID 30664H. There isone 30666H ID 30664H for each QuoteReference entity 30656H the ID 30664His of type GDT 30668H BusinessTransactionDocumentID 30670H. TheQuoteReference entity 30656H also includes an ItemID 30672H. There isany number 30674H of ItemID for each Quote Reference entity 30656H. TheItemID is or type GDT 30676H BusinessTransactionDocumentItemID 30678H.

The BusinessTransactionDocumentReference package 30656F also includes aPurchaseContractReference entity 30680H. The PurchaseContractReferenceentity 30680H is of type GDT 30684H BusinessTransactionDocumentReference30686H. There is one or zero 30682H PurchaseContractReference entities30680N for each Item entity 30604F. The PurchaseContractReference entity30680H includes an ID 30688H. There is one ID 30688H for eachPurchaseContractReference entity 30680H. The ID 30688H is of type GDT30692H BusinessTransactionDocumentID 30694H. ThePurchaseContractReference entity 30680H includes an ItemID entity30696H. There is any number 30698H of ItemID 30696H for eachPurchaseContractReference entity 30680H. The ItemID 30696H is of typeGDT 30600I BusinessTransactionDocumentItemID 30602I.

The BusinessTransactionDocumentReference package 30656F further includesa BuyerProductCatalogueReference entity 30604I. TheBuyerProductCatalogueReference entity 30604I is of type AGDT 30608ICatalogueReference 30610I. There is one or zero 30606IBuyerProductCatalogueReference entities 30604I for each Item entity30604F. The BuyerProductCatalogueReference entity 30604I includes an ID30612I. There is one ID 30612I for each BuyerProductCatalogueReferenceentity 30604I is of type GDT 30616I CatalogueID 30618A. TheBuyerProductCatalogueReference entity 30604I includes an ItemID 30620I.There is any number 30622I of ItemID 30620I for eachBuyerProductCatalogueReference entity 30604I is of type GDT 30624ICatalogueItemID 30626I.

The Attachment package 30658F includes an Attachment entity 30628I,which is of type GDT 30632I Attachment 30634I. There is any number30630I of attachment entities 30628I for each Item entity 30604F.

The Description package 30660F includes a Description entity 30636I. TheDescription entity 30636I is of type GDT 30640I Description 30642I.There is one or zero 30638I Description entity 30636I for each Itementity 30604F.

The ScheduleLine package 30662F includes a ScheduleLine entity 30644Ihaving an ID 30652I, DeliveryPeriod 30660I, and Quantity 30668I. TheScheduleLine entity 30644I has zero or one occurrence 30646I for eachItem entity 30604F. The ScheduleLine entity 30644I is of data type AGDT30648I RFQItemScheduleLine 30650I. The ID 30652I has one or zerooccurrence 30654I for each ScheduleLine entity 30644I with a data typeof GDT 30656I BusinessTransactionDocumentItemScheduleLineID 30658I. TheDeliveryPeriod 30660I has one occurrence 30662I for each ScheduleLineentity 30644I and a data type of AGDT 30664I DateTimePeriod 30666I. TheQuantity 30668I has one or zero occurrences 30670I for each ScheduleLineentity 30644I a data type of GDT 30672I Quantity 30674I.

(b) Data Type RFQ Cancellation Message

FIGS. 307A-C depict the element structure for RFQCancellationRequest.The element structure is similar to the data model, but providesadditional information regarding the details of the interface. Theelement structure identifies the different packages 30700 in theinterface, and represents the entities at various levels within theinterface. As depicted in FIGS. 307A-C, the interface forRFQCancellationRequest includes five levels 30702, 30704, 30706, 30708,and 30710. The element structure identifies the cardinality 30712between the entities and/or attributes of the interface, and providesinformation (i.e., type 30714 and name 30716) regarding the data typethat provides the basis for the entity and/or attribute. The outermostpackage of this interface is an RFQCancellationMessage package 30718,which includes an RFQCancellationMessage entity 30720 at the first level30702. The RFQCancellationMessage entity 30720 is of type message datatype (“MDT”) 30722 “RFQCancellationMessage” 30724.

The RFQCancellationMessage package 30718 includes a MessageHeaderpackage 30726 and an RFQCancellation package 30728. The MessageHeaderpackage 30726 includes a MessageHeader entity 30730, which is of typegeneric data type (“AGDT”) 30734 “BusinessDocumentMessageHeader” 30736.There is one 30732 MessageHeader entity 30730 for eachRFQCancellatiorMessage entity 30720.

The MessageHeader entity 30730 includes an ID 30738, a ReferenceID30746, and a CreationDateTime 30754. The ID 30738 is of type GDT 30742BusinessDocumentMessageID 30744. The ReferenceID 30746 is of type GDT30750 BusinessDocumentMessageID 30752. The CreationDateTime 30754 is oftype GDT 30758 DateTime 30760. There is one 30740 ID 30738 for eachMessageHeader entity 30730, one or zero 30748 ReferenceID 30786 for eachMessageHeader entity 30730, and one 30756 CreationDateTime 30754 foreach MessageHeader entity 30730.

The MessageHeader entity 30730 also includes a SenderParty entity 30762and a RecipientParty entity 30726A. The SenderParty entity 30762 is oftype AGDT 30766 BusinessDocumentMessageHeaderParty 30768. TheRecipientParty entity 30726A is also of type AGDT 30730ABusinessDocumentMessageHeaderParty 30732A. There is one or zero 30764SenderParty entity 30762 for each MessageHeader entity 30730, and thereis any number 30728A of RecipientParty entity 30726A for eachMessageHeader entity 30730.

The SenderParty entity 30762 includes an InternalID 30770, a StandardID30778, and a Contact 30786. The InternalID 30770 has zero or oneoccurrences 30772 for each SenderParty entity 30762 and a data type CDT30774 of PartyInternalID 30776. The StandardID 30778 has any number ofoccurrences 30780 for each SenderParty entity 30762 and a data type ofCDT 30782 PartyStandardID 30784. The Contact 30786 has zero or oneoccurrences 30788 for each SenderParty entity 30762 and is of data typeGDT 30790 ContactPerson 30792. The Contact 30786 also includes anInternalID 30794, BuyerID 30702A, Bidder ID 30710A and an Address30718A. The InternalID 30794 Person has any number of occurrences 30796for each SenderParty entity 30762 and a data type of CDT 30798ContactPersonInternalID 30700A. The BuyerID 30702A has zero or oneoccurrences 30704A for each SenderParty entity 30762 and a data type ofCDT 30706 ContactPersonPartyID 30708A. The BidderID 30710A has zero orone occurrences 30712A for each SenderParty entity 30714A and a datatype of CDT 30714A ContactPersonPartyID 30716A. The Address 30718A haszero or one occurrences 30720A for each SenderParty entity 30762 and adata type of AGDT 30722A Address 30724A.

The RFQCancellation package 30728 includes an RFQCancellation entity30734A. The RFQCancellation entity 30734A is of type GDT 30738ARFQCancellation 30740A. There is one 30736A RFQCancellation entity30734A for each RFQCancellationMessage entity 30720. The RFQCancellationentity 30734A includes an ID 30742A. There is one 30744A ID 30742A foreach RFQCancellation entity 30734A. The ID 30742A is of type GDT 30746ABusinessTransactionDocumentID 30748A.

(c) Data Type Quote Message

FIGS. 308A-M depict the element structure for QuoteNotification. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 30800 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIGS. 308A-M, the interface for QuoteNotification includessix levels 30802, 30804, 30806, 30808, 30810, and 30812. The elementstructure identifies the cardinality 30814 between the entities and/orattributes of the interface, and provides information (i.e., type 30816and name 30818) regarding the data type that provides the basis for theentity and/or attribute. The outermost package of this interface is anQuoteMessage package 30800, which includes an QuoteMessage entity 30822at the first level 30802. The QuoteMessage entity 30822 is of typemessage data type (“MDT”) 30824 “QuoteMessage” 30826.

The QuoteMessage package 30820 includes a MessageHeader package 30828and a Quote package 30830. The MessageHeader package 30828 includes aMessageHeader entity 30832, which is of type generic data type (“AGDT”)30836 “BusinessDocumentMessageHeader” 30838. There is one 30834MessageHeader entity 30832 for each QuoteMessage entity 30822.

The MessageHeader entity 30832 includes an ID 30840, a Reference ID30848, and a CreationDateTime 30856. The ID 30840 is of type GDT 30844BusinessDocumentMessageID 30846. The ReferenceID 30848 is of type GDT30852 BusinessDocumentMessageID 30854. The CreationDateTime 30856 is oftype GDT 30860 DateTime 30862. There is one 30842 ID 30840 for eachMessageHeader entity 30832, one or zero 30850 ReferenceID 30848 for eachMessageHeader entity 30832, and one 30858 CreationDateTime 30856 foreach MessageHeader entity 30832.

The MessageHeader entity 30832 also includes a SenderParty entity 30864and a RecipientParty entity 30828A. The SenderParty entity 30864 is oftype AGDT 30868 BusinessDocumentMessageHeaderParty 30870. TheRecipientParty entity 30828A is also of type AGDT 30832ABusinessDocumentMessageHeaderParty 30834A. There is one or zero 30866SenderParty entity 30864 for each MessageHeader entity 30832, and thereis any number 30830A of RecipientParty entity 30828A for eachMessageHeader entity 30832.

The SenderParty entity 30864 includes an InternalID 30872, a StandardID30880, and a Contact 30888. The InternalID 30872 has zero or oneoccurrences 30874 for each SenderParty entity 30864 and a data type CDT30876 of PartyInternalID 30878. The StandardID 30880 has any number ofoccurrences 30882 for each SenderParty entity 30864 and a data type ofCDT 30884 PartyStandardID 30856. The Contact 30888 has zero or oneoccurrences 30890 SenderParty entity 30864 and is of data type GDT 30892Contact 30894. The Contact 30888 also includes an InternalID 30896,BuyerID 30804A, Bidder ID 30812A and an Address 30820A. The InternalID30896 has any number of occurrences 30898 for each Contact 30888 and adata type of CDT 30800A ContactPersonInternalID 30802A. The BuyerID30804A has zero or one occurrences 30806A for each Contact 30888 and adata type of CDT 30808A ContactPersonPartyID 30810A. The BidderID 30812Ahas zero or one occurrences 30814A and a data type of CDT 30816AContactPersonPartyID 30818A. The Address 30820A has one or zerooccurrences 30822A for each Contact 30888 and a data type of AGDT 30824AAddress 30826A.

The Quote package 30830 includes a Quote entity 30836A. There is one30838A Quote entity 30836A for each QuoteMessage entity 30822. The Quoteentity 30836A has a data type of AGDT 30840A Quote 30842A. The Quoteentity 30836A includes an ID 30844A, a PostingDateTime 30852A, aLastChangeDateTime 30860A, a BindingDateTime 30868A, a Note 30876A, anda ContractTargetAmount 30884A.

There is one 30846A ID 30844A for each Quote entity 30836A. The ID30844A is of type GDT 30848A BusinessTransactionDocumentID 30850A. APostingDateTime 30852A has zero or one occurrences 30854A for each Quoteentity 30836A and is of type GDT 30856A DateTime 30858A.LastChangeDateTime 30860A has zero or one occurrences 30862A for eachQuote entity 30836A and is of type GDT 30864A DateTime 30866A.BindingDateTime 30868A has zero or one occurrences 30870A for each Quoteentity 30836A and is of type GDT 30880A DateTime 30874A. Note 30876A haszero or one occurrences 30878A for each Quote entity 30836A and is oftype GDT 30880A Note 30882A. ContractTargetAmount 30884A has zero or oneoccurrences 30886A and is of type GDT 30888A Amount 30890A.

The Party package 30892A includes a BuyerParty entity 30810B, aBidderParty entity 30882B, a BidderPortalPartyProvider entity 30890B, aProductRecipientParty entity 30898B, a VendorParty entity 30806C, aManufacturerParty entity 30814C, a PayerParty entity 30822C.

The BuyerParty entity 30810B is of type GDT 30814BBusinessTransactionDocumentParty 30816B. There is one or zero 30812BBuyerParty entity 30810B for each Quote entity 30836A. The BidderPartyentity 30882B is of type AGDT 30886B BusinessTransactionDocumentParty30888B. There is zero or one 30884B BidderParty entity 30882B for eachQuote entity 30836A. The BidderPortalPartyProvider entity 30890B is oftype AGDT 30894B BusinessTransactionDocumentParty 30896B. There is zeroor one 30892B BidderPortalPartyProvider entity 30890B for each Quoteentity 30836A. The ProductRecipientParty entity 30898B is of type AGDT30802C BusinessTransactionDocumentParty 30804C. There is one or zero30800C ProductRecipientParty entity 30898B for each Quote entity 30836A.The VendorParty entity 30806C is of type AGDT 30810CBusinessTransactionDocumentParty 30812C. There is one or zero 30808CVendorParty entity 30806C for each Quote entity 30836A. TheManufacturerParty entity 30814C is of type AGDT 30818CBusinessTransactionDocumentParty 30820C. There is one or zero 30816CManufacturerParty entity 30814C for each Quote entity 30836A. ThePayerParty entity 30822C is of type AGDT 30826CBusinessTransactionDocumentParty 30828C. There is one or zero 30824CPayerParty entity 30822C for each Quote entity 30836A.

The BuyerParty entity 30810B includes a StandardID 30818B, a BuyerID30826B, a BidderID 30834B, an Address 30842B, and a Contact 30850B. TheStandardID 30818B has any number of occurrences 30820 B for eachBuyerParty entity 30810B and a data type of CDT 30822B PartyStandardID30824B. The BuyerID 30826B has zero or one occurrences 30828B for eachBuyerParty entity 30810B and a data type of CDT 30830B PartyPartyID30840B. The BidderID 30834B has zero or one occurrences 30836B for eachBuyerParty entity 30810B and a data type of CDT 30838B PartyPartyID30840B. The Address 30842B has occurrences 30844B for each BuyerPartyentity 30810B and a data type of AGDT 30846B Address 30848B. The Contact30850B has zero or one occurrences 30852B for each BuyerParty entity30810B and a data type of AGDT 30854B ContactPerson 30856B. The Contact30850B also includes a BuyerID 30858B, BidderID 30866B and an Address30874B. The BuyerID 30858B has zero or one occurrences 30860B for eachContact 30850B and a data type of CDT 30862B PartyPartyID 30864B. TheBidderID 30866B has zero or one occurrences 30868B for each Contact30850B and a data type of CDT 30870B PartyPartyID 30872B. The Address30874B has one or zero occurrences 30876 for each Contact 30850B and adata type of AGDT 30878B Address 30880B.

The Location package 30894A includes a ShipToLocation entity 30830C. TheShipToLocation entity 30830C is of type AGDT 30834CBusinessTransactionDocumentLocation 30836C. There is one or zero 30832CShipToLocation entity 30830C for each Quote entity 30836A. TheShipToLocation entity 30830C includes a StandardID 30838C, a BuyerID30846C, a BidderID 30854C, and an Address 30862C. The StandardID 30838Chas any number of occurrences 30840C and a data type of CDT 30842CLocationStandardID 30844C. The BuyerID 30846C has zero or oneoccurrences 30848C for each ShipToLocation entity 30830C and a data typeof CDT 30850C LocationPartyID 30852C. The BidderID 30854C has zero orone occurrences 30856C for each ShipToLocation entity 30830C and a datatype of CDT 30858C LocationPartyID 30860C. The Address 30862C has zeroor one occurrences 30864C for each ShipToLocation entity 30830C and adata type of AGDT 30866C Address 30868C.

The DeliveryInformation package 30896A includes a DeliveryTerms entity30870C, which is of type AGDT 30874C DeliveryTerms 30876C. There is oneor zero 30872C DeliveryTerms entity 30870C for each Quote entity 30836A.The DeliveryTerms entity 30870C includes an Incoterms entity 30878Cwhich is of type GDT 30882C Incoterms 30884C. There is one or zero 308CIncoterms entity 30878C for each DeliveryTerms entity 30870C.

The PaymentInformation package 30898A includes a CashDiscountTermsentity 30886C, which is of type AGDT 30890C CashDiscountTerms 30892C.There is one or zero 30888C CashDiscountTerms entity 30886C for eachQuote entity 30836A. The PaymentInformation package 30898A also includesa PaymentForm entity 30814D. There is one or zero 30816D PaymentFormentity 30814D for each Quote entity 30836A. The PaymentForm entity30814D includes a Code 30818D that is of type GDT 30822D PaymentFormCode30824D. There is one 30820D Code 30818D for each PaymentForm entity30814D.

The CashDiscountTerms entity 30886C includes a MaximumCashDiscount30894C, and a NormalCashDiscount 30862D, and FullPaymentDueDaysValue30810D. There is one or zero occurrences 30896C of theMaximumCashDiscount entity 30894C is of type GDT 30898C CashDiscount30800D. There is one or zero occurrences 30896C of theNormalCashDiscount entity 30802D is of type GDT 30806D CashDiscount30808D. There are one or zero occurrences 30812D of theFullPaymentDueDaysValue entity 30810D for each CashDiscount Terms entity30886C.

The PriceInformation package 30801B includes a PriceSpecificationElemententity 30841D. The PriceSpecificationElement entity 30841D is of typeGDT 30845D PriceSpecificationElement 30841D. There is one or n 30843DPriceSpecificationElement entity 30841D for each RFQ entity 30636A.

The ProductInformation package 30800B includes a ProductCategory entity30826D. The ProductCategory entity 30826D is of type GDT 30830DBusinessTransactionDocumentProductCategory 30832D. There is one or zero30828D ProductCategory entity 30826D for each Quote entity 30836A. TheProductCategory entity 30826D includes a StandardID 30834D, a BuyerID30840D, and a BidderID 30846D. The StandardID 30834D of has a data typeof CDT 30836D ProductCategoryStandardID 30838D. The BuyerID 30840D has adata type of CDT 30842D ProductCategoryPartyID 30844D. The BidderID30846D has a data type of CDT 30848D ProductCategoryPartyID 30850D.

The BusinessTransactionDocumentReference package 30802B includes aRFQReference entity 30852D. The RFQReference entity 30852D is of typeGDT 30856D BusinessTransactionDocumentReference 30858D. There is one orzero 30854D RFQReference entities 30852D for each Quote entity 30836A.The RFQReference entity 30852D includes an ID 30860D, and there is one30862D ID 30860D RFQReference entity 30852D is of type GDT 30864DBusinessTransactionDocumentID 30866D.

The Attachment package 30804B includes an Attachment entity 30868D,which is of type GDT 30872D Attachment 30874D. There is any number30870D Attachment entities 30868D for each Quote entity 30836A.

The Description package 30806B includes a Description entity 30876D. TheDescription entity 30876D is of type GDT 30880D Description 30882D.There is one or zero 30878D Description entities 30876D for each Quoteentity 30836A.

The Item package 30808B includes an Item entity 30884D which is of datatype AGDT 30888D QuoteItem 30890D. There is any number 30886D of Itementities 30884D for each Quote entity 30836A. The Item entity 30884Dincludes an ID 30892D, a ContractTargetAmount 30800E, and aHierarchyRelationship 30808E. The ID 30892D is of type GDT 30896DBusinessTransactionDocumentItemID 30898D, and there is one 30894D ID30892D for each Item entity 30884D. The ContractTargetAmount 30800E isof type GDT 30804E Amount 30806E, and there is one or zero 30802EContractTargetAmount 30800E for each Item entity 30884D. There is one orzero 30810E HierarchyRelationship 30808E for each Item entity 30884D.The HierarchyRelationship 30808E includes a ParentItemID 30812E, whichis of type GDT 30816E BusinessTransactionDocumentItemID 30818E, and aTypeCode 30820E, which is of type GDT 30824EBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 30826E.There is one 30814E ParentItemID 30812E for each HierarchyRelationship30808E, and there is one 30822E TypeCode 30820E for eachHierarchyRelationship 30808E.

The Item package 30808B also includes a ProductInformation package30828E, a Party package 30832E, a Location package 30834E, aDeliveryInformation package 30836E, aBusinessTransactionDocumentReference package 30838E, a PriceInformationpackage 30830E, an Attachment package 30840E, a Description package30842E, and a ScheduleLine package 30844E.

The ProductInformation package 30828E includes a Product entity 30846Eand a ProductCategory entity 30800F. The Product entity 30846E is oftype BusinessTransactionDocumentProduct 30850E. There is one or zero30848E Product entity for each Item entity 30884D. The ProductCategoryentity 30800F is of type BusinessTransactionDocumentProductCategory30804F. There is one or zero 30802F ProductCategory entity 30800F foreach Item entity 30884D.

The Product entity 30846E includes a StandardID 30852E, a BuyerID30860E, a BidderID 30868E, an ManufacturerID 30876E, TypeCode 30884E anda Note 30892E. The StandardID 30852E has any number of occurrences30854E Product entity 30846E and has a data type of CDT 30856EProductStandardID 30858E. The BuyerID 30860E has zero or one occurrences30862E for each Product entity 30846E and a data type of CDT 30864EProductPartyID 30866E. The BidderID 30868E has zero or one occurrences30870E for each Product entity 30846E and a data type of CDT 30872EProductPartyID 30874E. The ManufacturerID 30876E has zero or oneoccurrences 30878E for each Product entity 30846E and a data type of CDT30880E ProductPartyID 30882E. The TypeCode 30884E has zero or oneoccurrences 30886E for each Product entity 30846E and a data type of GDT30888E ProductTypeCode 30890E. The Note 30892E has zero or oneoccurrences 30894E for each Product entity 30846E and a data type of GDT30896E Note 30898E.

The ProductCategory entity 30800F includes a StandardID 30806F, aBuyerID 30814F, and a BidderID 30822F. The StandardID 30806F of has anynumber occurrences 30808F for each Product entity 30846E and has a datatype of CDT 30810F ProductCategoryStandardID 30812F. The BuyerID 30814Fhas zero or one occurrences 30816 for each Product entity 30846E and adata type of CDT 30818F ProductCategoryPartyID 30820F. The BidderID30822F has a data type of CDT 30824F ProductCategoryPartyID 30826F.

The PriceInformation package 30830E includes a PriceSpecificationElemententity 30828F. The PriceSpecificationElement entity 30828F is of typeGDT 30831F PriceSpecificationElement 30841D. There is one or n 30830FPriceSpecificationElement entity 30828F for each Item entity 30884D.

The PriceInformation package 30830E includes a Price entity 30828F.There is one or zero 30830F Price entity 30828F for each Item entity30884D. The Price entity 30828F includes a NetUnitPrice 30832F. TheNetUnitPrice 30832F is of type AGDT 30836F Price 30838F. There is one orzero 30834F NetUnitPrice 30832F for each Price entity 30828F.

The Party package 30832E includes a BuyerParty entity 30840F, aBidderParty entity 30848F, a ProductRecipientParty entity 30856F, aVendorParty entity 30864F, and a ManufacturerParty entity 30872F.

The BuyerParty entity 30840F is of type AGDT 30844FBusinessTransactionDocumentParty 30846F. There is one or zero 30842FBuyerParty entity 30840F for each Item entity 30884D. The BidderPartyentity 30848F is of type AGDT 30852F BusinessTransactionDocumentParty30854F. There is zero or one 30850F BidderParty entity 30848F for eachItem entity 30884D. There is zero or one 30858F ProductRecipientPartyentity 30856F for each Item entity 30884D. The ProductRecipientPartyentity 30856F is of type AGDT 30860F BusinessTransactionDocumentParty30862F. The VendorParty entity 30864F is of type AGDT 30868FBusinessTransactionDocumentParty 30870F. There is one or zero 30866FVendorParty entity 30864F for each Item entity 30884D. TheManufacturerParty entity 30872F is of type AGDT 30876FBusinessTransactionDocumentParty 30878F. There is one or zero 30874FManufacturerParty entity 30872F for each Item entity 30884D.

The Location package 30834E includes a ShipToLocation entity 30880F. TheShipToLocation entity 30880F is of type AGDT 30884FBusinessTransactionDocumentLocation 30886F. There is one or zero 30882FShipToLocation entity 30880F for each Item entity 30884D. TheShipToLocation entity 30880F includes a StandardID 30888F, a BuyerID30896F, a BidderID 30896F, and an Address 30812G. The StandardID 30888Fhas any number of occurrences 30890F for each ShipToLocation 30880F anda data type of CDT 30892F LocationStandardID 30894F. The BuyerID 30896Fhas zero or one occurrences 30898F for each ShipToLocation entity 30880Fand a data type of CDT 30800G LocationPartyID 30802G. The BidderID30804G has zero or one occurrences 30806G for each ShipToLocation 30880Fand a data type of CDT 30808G LocationPartyID 30810G. The Address 30812Ghas zero or one occurrences 30814G for each ShipToLocation 30880F and adata type of AGDT 30816G Address 30818G.

The DeliveryInformation package 30836E includes a DeliveryTerms entity30820G, which is of type AGDT 30824G DeliveryTerms 30826G. There is oneor zero 30822G DeliveryTerms entity 30820G for each Item entity 30884D.The DeliveryTerms entity 30820G includes a MaximumLeadTimeDurationentity 30828G which is of type GDT 30832G Duration 30834G, and there isone or zero occurrences 30830G for each DeliveryTerms entity 30820G. TheDeliveryTerms entity 30820G includes an Incoterms entity 30836G which isof type GDT 30840G Incoterms 30842G. There is one or zero 30838GIncoterms entity 30836 for each DeliveryTerms entity 30820G.

The BusinessTransactionDocumentReference package 30838E includes aRFQReference entity 30844G. The RFQReference entity 30844G is of typeGDT 30848G BusinessTransactionDocumentReference 30850G. There is one orzero 30846G RFQReference entities 30844G for each Item entity 30884D.The RFQReference entity 30844G includes an ID 30852G. There is one30854G ID entity 30852 for each RFQReference entity 30844G is of typeGDT 30856G BusinessTransactionDocumentID 30858G. The RFQReference entity30844G includes an ItemID 30860G. There is any number 30862G of ItemID30860G the ItemID is of type GDT 30864GBusinessTransactionDocumentItemID 30866G.

The Attachment package 30840E includes an Attachment entity 30868G,which is of type GDT 30872G Attachment 30874G. There is any number30870G of Attachment entities 30868G for each Item entity 30884D.

The Description package 30842E includes a Description entity 30876G. TheDescription entity 30876G is of type GDT 30880G Description 30882G.There is one or zero 30878G Description entity 30876G for each Itementity 30884D.

The ScheduleLine package 30844E includes a ScheduleLine entity 30884Ghaving an ID 30892G, DeliveryPeriod 30800H, and Quantity 30808H. TheScheduleLine entity 30884G has zero or one occurrence 30886G for eachItem entity 30884D, and a data type AGDT 30888G ItemScheduleLine 30890G.The ID 30892G has one or zero occurrence 30894G for each ScheduleLineentity 30884G and a data type of GDT 30896GBusinessTransactionDocumentItemScheduleLineID 30898G. The DeliveryPeriod30800H has one occurrence 30802H a data type of AGDT 30804HDateTimePeriod 30806H. The Quantity 30808H has one or zero occurrences30810H for each ScheduleLine entity 30884G a data type of GDT 30812HQuantity 30814H.

(d) Data Type RFQ Result Message

FIGS. 309A-D depict the element structure for RFQResultNotification. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 30900 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIGS. 309A-D, the interface for RFQResultNotificationincludes six levels 30902, 30904, 30906, 30908, 30910, and 30912. Theelement structure identifies the cardinality 30914 between the entitiesand/or attributes of the interface, and provides information (i.e., type30916 and name 30918) regarding the data type that provides the basisfor the entity and/or attributes. The outermost package of thisinterface is an RFQResultMessage package 30920, which includes anRFQResultMessage entity 30922 at the first level 30902. TheRFQResultMessage entity 30922 is of type message data type (“MDT”) 30924“RFQResultMessage” 30926.

The RFQResultMessage package 30920 includes a MessageHeader package30928 and an RFQResult package 30930. The MessageHeader package 30928includes a MessageHeader entity 30932, which is of type generic datatype (“AGDT”) 30936 “BusinessDocumentMessageHeader” 30938. There is one30934 MessageHeader entity 30932 for each RFQMessageResult entity 30922.

The MessageHeader entity 30932 includes an ID 30940, a Reference ID30948, and a CreationDateTime 30956. The ID 30940 is of type GDT 30944BusinessDocumentMessageID 30946. The ReferenceID 30948 is of type GDT30952 BusinessDocumentMessageID 30954. The CreationDateTime 30956 is oftype GDT 30960 DateTime 30962. There is one 30942 ID 30940 for eachMessageHeader entity 30932, one or zero 30950 ReferenceID 30948 for eachMessageHeader entity 30932, and one 30958 CreationDateTime 30956 foreach MessageHeader entity 30932.

The MessageHeader entity 30932 also includes a SenderParty entity 30964and a RecipientParty entity 30928A. The SenderParty entity 30964 is oftype AGDT 30968 BusinessDocumentMessageHeaderParty 30970. TheRecipientParty entity 30928A is also of type AGDT 30932ABusinessDocumentMessageHeaderParty 30934A. There is one or zero 30966SenderParty entity 30964 for each MessageHeader entity 30932, and thereany number 30930A of RecipientParty entity 30928A for each MessageHeaderentity 30932.

The SenderParty entity 30964 includes an InternalID 30972, a StandardID30980 and a Contact 30988. The InternalID 30972 has zero or oneoccurrences 30974 for each SenderParty entity 30964 and a data type CDT30976 of PartyInternalID 30978. The StandardID 30980 has any number ofoccurrences 30982 for each SenderParty 30964 and has a data type of CDT30984 PartyStandardID 30986. The Contact 30988 has zero or oneoccurrences 30990 for each SenderParty entity 30964 and is of data typeGDT 30992 ContactPerson 30994. The Contact 30988 also includes anInternalID 30996, BuyerID 30904A, BidderID 30912A and an Address 30920A.The InternalID 30996 has any number of occurrences 30998 for eachContact 30988 and a data type of CDT 30900A ContactPersonInternalID30902A. The BuyerID 30904A has any zero or one occurrences 30906A foreach Contact 30988 and a data type of CDT 30908A ContactPersonPartyID30910A. The BidderID 30912A has zero or one occurrences 30914A for eachContact 30988 and a data type of CDT 30916A ContactPersonPartyID 30918A.The Address 30920A has one or zero occurrences 30922A for each Contact30988 and a data type of AGDT 30924A Address 30926A.

The RFQResult package 30930 includes a party package 30952A, adescription package 30954A, and an Item package 30956A. The RFQResultpackage 30930 also includes an RFQResult entity 30936A. The RFQResultentity 30936A is of type AGDT 30940A RFQ Result 30942A. There is one30938A RFQResult entity 30936A for each RFQResultMessage entity 30922.The RFQResult entity 30936A includes an ID 30944A. There is one 30946AID 30944A for each RFQResult entity 30936A. The ID 30944A is of type GDT30948A BusinessTransactionDocumentID 30950A.

The Party package 30952A includes a BidderParty entity 30958A. TheBidderParty entity 30958A is of type AGDT 30962ABusinessTransactionDocumentParty 30964A. There is zero or one 30960ABidderParty entity 30958A for each RFQResult entity 30936A.

The Description package 30954A includes a Description entity 30966A. TheDescription entity 30966A is of type GDT 30970A Description 30972A.There is one or zero occurrences 30968A of Description entities 30966Afor each RFQResult entity 30936A.

The Item package 30956A includes a BusinessTranslationDocumentReferencepackage 30910B 30910B and a ScheduleLine package 30912B. The Itempackage 30956A also includes an Item entity 30974A. There is any number30976A of Item entities 30974A for each RFQResult entity 30936A. TheItem entity 30974A includes an ID 30982A and a HierarchyRelationship30990A. The ID 30982A is of type GDT 30986ABusinessTransactionDocumentItemID 30988A, and there is one 30984A ID30982A for each Item entity 30974A. There is one or zero 30992AHierarchyRelationship 30990A for each Item entity 30974A. TheHierarchyRelationship 30990A includes a ParentitemID 30994A, which is oftype GDT 30998A BusinessTransactionDocumentItemID 30900B, and a TypeCode30902B which is of type GDT 30906BBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 30908B.There is one 30996A ParentItemID 30994A for each HierarchyRelationship30990A, and there is one 30904B TypeCode 30902B for eachHierarchyRelationship 30990A.

The BusinessTransactionDocumentReference package 30910B includes aQuoteReference entity 30914B. The QuoteReference entity 30914B is oftype GDT 30918B BusinessTransactionDocumentReference 30920B. There isone or zero 30916B QuoteReference entities 30914B for each Item entity30974A. The QuoteReference entity 30914B includes an ID 30922B, is one24B ID 30922B for each QuoteReference entity 30914B is of type GDT30926B BusinessTransactionDocumentID 30928B. The QuoteReference entity30914B also includes an ItemID 30930B. There is any number of ItemIDentity 30930B for each QuoteReference entity 30914B. The ItemID is oftype GDT 30934B BusinessTransactionDocumentItemID 30936B.

The ScheduleLine package 30912B includes a ScheduleLine entity 30938Bhaving an ID 30946B, a DeliveryPeriod 30954B, and a Quantity 30962B. TheScheduleLine entity 30938B has zero or one occurrence 30940B for eachItem entity 30974A, and a data type AGDT 30942BRFQResultItemScheduleLine 30944B. The ID 30946B has one or zerooccurrence 30948B for each QuoteReference entity 30914B and a data typeof GDT 30950B BusinessTransactionDocumentItemScheduleLineID 30952B. TheDeliveryPeriod 30954B has one occurrence 30956B for each QuoteReferenceentity 30914B a data type of AGDT 30958B DateTimePeriod 30960B. TheQuantity 30962B has one or zero occurrences 30964B for eachQuoteReference entity 30914B a data type of GDT 30966B Quantity 30968B.

f) Catalogue Interfaces

The Catalogue interfaces, such as the CatalogueUpdateNotificationinterface and the CataloguePublicationRequest interface, allow for thecreation of a catalogue from other catalogues and the management ofelectronic publication or viewing of the catalogue for a company orenterprise. In particular, the CatalogueUpdateNotification interfaceallows a catalogue to be received from an external source (e.g., asupplier or other external catalogue provider) and loaded into aCatalogue Authoring Tool (CAT). The CatalogueUpdateNotificationinterface is compatible to other international standardized interfacessuch as eCX and BMEcat and may be considered a B2B interface. TheCataloguePublicationRequest interface allows the Catalogue AuthoringTool or company-internal authoring environment to publish the catalogueto a Catalogue Search Engine for employees, customers, or other users toaccess the catalogue in accordance with the CataloguePublicationRequest.In addition, another set of Catalogue interfaces described herein allowsfor the confirmation of the catalogue transmission to the CatalogueSearch Engine and for the catalogue publication by the Catalogue SearchEngine. Yet another set of Catalogue interfaces allows for thecancellation of the catalogue transmission to the Catalogue SearchEngine and for locking or revoking publication of identified items ofthe catalogue by the Catalogue Search Engine.

Catalogues may be of interest for various business scenarios, eachscenario usually leading to somewhat different types of catalogues anddifferent types of objects described within the catalogues. Inaccordance with methods and systems consistent with the presentinvention, Catalogue interfaces are provided for managing the content ofcatalogues, such as product catalogues used for purchasing or suppliercatalogues for selecting and managing suppliers. For example, a companymay use catalogues for the procurement of various products for companyemployees. Employees may enter the procurement portal associated withthe Catalogue Search Engine, browse through a catalogue supported by theCatalogue Search Engine, and add selected products to their respectiveshopping basket. As discussed below, an internal company catalogueproduced by the Catalogue Authoring Tool may include items of severalsupplier catalogues. To produce the internal catalogue, the CatalogueManager may upload the supplier catalogues into the Catalogue AuthoringTool and build the internal company catalogue using the CatalogueAuthoring Tool. The Catalogue Manager, via the Catalogue Authoring Tool,may structure the catalogue into sections and identify which items toinclude from the supplier catalogues. In addition, the CatalogueManager, via the Catalogue Authoring Tool, may enrich the internalcatalogue data by, for example, adding suitable descriptions, graphicsand characteristics in association with a catalogue item before sendinga CataloguePublicationRequest to the Catalogue Search Engine to publishthe catalogue.

(1) Message Types

There are eight message types in total that are used in order totransmit and maintain catalogues in accordance with the presentinvention. Methods and systems consistent with the present invention usethe package template for Master Data depicted in FIG. 270C to derive theCatalogue interfaces.

(a) Catalogue Update Notification

A CatalogueUpdateNotification message is a notification about a new,changed or deleted catalogue by a Catalogue Provider to an interestedparty, such as the Catalogue Authoring Tool and the Catalogue Manager.The structure of message type CatalogueUpdateNotification message isgenerated based on the structure of message data typeCatalogueUpdateMessage. A CatalogueUpdateNotification message may besplit into several transmission packages.

(b) Catalogue Publication Request

A CataloguePublicationRequest message is the request from the CatalogueAuthoring Tool to the Catalogue Search Engine (or publishing system) topublish a new or changed catalogue or to delete an already publishedcatalogue. The structure of message type CataloguePublicationRequestmessage is generated based on the structure of message data typeCataloguePublicationMessage. The CataloguePublicationRequest message maybe split into several transmission packages.

(c) Catalogue Publication Transmission Package Notification

A CataloguePublicationTransmissionPackageNotification message is thenotification of the Catalogue Search Engine to Catalogue Authoring Toolabout a package of a Catalogue publication transmission and informationabout the reception of the package and the validity of the package'scontent. The structure of message typeCataloguePublicationTransmissionPackageNotification message is generatedbased on the structure of message data typeCataloguePublicationTransmissionPackageMessage.

(d) Catalogue Publication Confirmation

A CataloguePublicationConfirmation message is the confirmation by theCatalogue Search Engine to the Catalogue Authoring Tool whether thepublication or deletion of a catalogue identified by aCataloguePublicationRequest message was successful or not. The structureof message type CataloguePublicationConfirmation message is generatedbased on the structure of message data typeCataloguePublicationConfirmationMessage in FIG. 367.

(e) Catalogue Publication Transmission Cancellation Request

A CataloguePublicationTransmissionCancellationRequest message is therequest of the Catalogue Authoring Tool to the Catalogue Search Engineto cancel the transmission of a catalogue and to restore an earlierpublished state (if such exists) of the catalogue. The structure of theCataloguePublicationTransmissionCancellationRequest message is generatedbased on the structure of message data typeCataloguePublicationTransmissionCancellationRequestMessage. In oneimplementation, the CataloguePublicationTransmissionCancellationRequestmessage is used to cancel an ongoing publication and not to de-publishan already successfully published catalogue.

(f) Catalogue Publication Transmission Cancellation Confirmation

A CataloguePublicationTransmissionCancellationConfirmation message isthe confirmation of Catalogue Search Engine whether the transmission ofa catalogue has been cancelled successfully and an earlier publishedstate of this Catalogue (if such exists) has been restored or not. Thestructure of message typeCataloguePublicationTransmissionCancellationConfirmation is generatedbased on the structure of message data typeCataloguePublicationTransmissionCancellationConfirnationMessage.

(g) Catalogue Publication Transmission Item Lock Request

A CataloguePublicationTransmissionItemLockRequest message is the requestof Catalogue Authoring Tool to lock identified items of the catalogueincluded in the catalogue publication transmission. To lock means thatif the catalogue is not yet published, the identified items are notpublished, and if the catalogue is already published, the publication ofthe identified items is revoked. The structure of message typeCataloguePublicationTransmissionItemLockRequest message is generatedbased on the structure of message data typeCataloguePublicationTransmissionItemLockRequestMessage.

(h) Catalogue Publication Transmission Item Lock Confirmation

A CataloguePublicationTransmissionItemLockConfirmation message is theconfirmation of the Catalog Search Engine to the Catalog Authoring Toolwhether identified items of the catalogue included in the catalogpublication transmission are locked or not. The structure of messagetype CataloguePublicationTransmissionItemLockConfirmation message isgenerated based on the structure of message data typeCataloguePublicationTransmissionItemLockConfirmationMessage.

(i) Catalogue Publication Transmission Content Change Request

A CataloguePublicationTransmissionContentChangeRequest is the request ofCatalog Authoring to Catalog Search Engine to change, create or todelete a limited number of catalog items contained in the cata-logpublication transmission. A message typeCataloguePublicationTransmissionContentChangeRequest has the structureof message data typeCataloguePublicationTransmissionContentChangeRequestMessage.

Several CataloguePublicationTransmissionContentChangeRequests may run inparallel if they are disjoint. The sending application may have toensure that this is the case. ACataloguePublicationTransmissionContentChangeRequest should not run inparallel with a CataloguePublicationRequest for the same catalog.

This request should not be split into several messages—in contrast tothe transmission of an entire catalog using a CatalogPublicationRequest.The sender must ensure that the number of items is small enough to allowcommunicating and processing the request as a single message. Thisrequest does not result in a new catalog version—in contrast to theCatalogPublication Re-quest. Locks on items resulting from one or morepredecessor messages CataloguePublicationTrans-missionItemLockRequestcan be removed—if there exist any.

(j) Catalogue Publication Transmission Content Change Confirmation

A CataloguePublicationTransmissionContentChangeConfirmation is theconfirmation of Catalog Search Engine (the publishing system) to CatalogAuthoring whether a limited number of catalog items contained in thecatalog publication transmission could be changed, created or deleted asrequested by a CataloguePublicationTransmissionContentChangeRequest ornot. Structure The structure of message typeCataloguePublicationTransmissionContentChangeConfirmation is given bythe structure of message data typeCataloguePublicationTransmissionContentChangeConfirmationMessage. Eitherall Items could be updated, created, deleted, or none.

(2) Message Choreography

FIG. 359 depicts the message choreography for Catalog Interfaces. Thechoreography involves three business entities a Catalogue Provider35902, a Catalogue Authoring Tool (CAT) 35904, and a Catalogue SearchEngine (CSE) 35906. The following message choreography describes thepossible sequence of the messages that can be used to realize thescenario between the Catalog Provider server 35900, a Catalog AuthoringTool server 35902, and the Catalog Search Engine server 35904. ACatalogueUpdateNotification message 35906 is sent from the CatalogProvider server 35900 to the Catalog Authoring Tool server 35902. TheCatalogueUpdateNotification message 35906 is a notice from a catalogueprovider to an interested party about a new catalogue transmitted in themessage or about changes to an existing catalogue transmitted in themessage.

A CataloguePublicationRequest message 35908 is sent from the CatalogAuthoring Tool server 35902 to the Catalog Search Engine server 35904.The CataloguePublicationRequest message 35908 is a request fromcatalogue authoring to the Catalogue Search Engine (the publishingsystem) to publish a new or changed catalogue or to delete an alreadypublished catalogue (the catalogue is possibly split into severaltransmission packages).

A message 35910 is sent from the Catalog Search Engine server 35904 tothe Catalog Authoring Tool server 35902. TheCataloguePublicationTransmissionPackageNotification is the notificationof the Catalogue Search Engine (the publishing system) to CatalogueAuthoring about a package of a catalogue publication transmission andinformation about the reception of this package and the validity of itscontent.

A CataloguePublicationConfirmation message 35912 is sent from theCatalog Search Engine server 35904 to the Catalog Authoring Tool server35902. The CataloguePublicationConfirmation message 35912 is theconfirmation of the Catalogue Search Engine (the publishing system) toCatalogue Authoring whether the publication or deletion of a cataloguerequested by a CataloguePublicationRequest was successful or not.

A CataloguePublicationTransmissionCancellationRequest message 35914 issent from the Catalog Authoring Tool server 35902 to the Catalog SearchEngine server 35904. TheCataloguePublicationTransmissionCancellationRequest message 35914 is therequest of Catalogue Authoring to Catalogue Search Engine (thepublishing system) to cancel the transmission of a catalogue and torestore an earlier published state (if such exists) of the catalogue.Moreover, no more packages are sent for this transmission.

A CataloguePublicationTransmissionCancellationConfirmation message 35916is sent from the Catalog Search Engine server 35904 to the CatalogAuthoring Tool server 35902. TheCataloguePublicationTransmissionCancellationConfirmation message 35916is the confirmation of Catalogue Search Engine (the publishing system)whether the transmission of a catalogue has been cancelled successfullyand an earlier published state of this catalogue (if such exists) hasbeen restored or not.

A CataloguePublicationTransmissionItemLockRequest message 35918 is sentfrom the Catalog Authoring Tool server 35902 to the Catalog SearchEngine server 35904. The CataloguePublicationTransmissionItemLockRequestmessage 35918 is the request of Catalogue Authoring to lock single itemsof the catalogue contained in the catalogue publication transmission.

A CataloguePublicationTransmissionItemLockConfirmation message 35920 issent from the Catalog Search Engine server 35904 to the CatalogAuthoring Tool server 35902. TheCataloguePublicationTransmissionItemLockConfirmation message 35920 isthe confirmation of Catalogue Search Engine (the publishing system) toCatalogue Authoring whether single items of the catalogue contained inthe catalogue publication transmission could be locked or not. To lockmeans that if the catalogue is not yet published the items must not bepublished and if the catalogue is already published, the publication ofthese items must be revoked.

A CataloguePublicationTransmissionContentChangeRequest message 35922 issent from the Catalog Authoring Tool server 35902 to the Catalog SearchEngine server 35904. TheCataloguePublicationTransmissionContentChangeRequest message 35922 isthe request of Catalogue Authoring to change items of the cataloguecontained in the catalogue publication transmission.

A CataloguePublicationTransmissionContentChangeConfirmation message issent from the Catalog Search Engine server 35904 to the CatalogAuthoring Tool server 35902. TheCataloguePublicationTransmissionContentChangeConfirmation message is theconfirmation of Catalogue Search Engine (the publishing system) toCatalogue Authoring whether single items of the catalogue contained inthe catalogue publication transmission could be changed or not.

(3) Message Serialization

All messages may be asynchronous in nature. Request messages may be sentto an Exchange Infrastructure (not shown in FIG. 359) with quality ofservice EQIO (exactly once, in order) so that the messages of the sametype (e.g., CataloguePublicationRequest message 35910) are received inthe Catalogue Search Engine 35906 in the order they were sent out of theCatalogue Authoring Tool 35904.

(4) Error Handling

Each response message (e.g.,CataloguePublicationTransmissionPackageNotification message) from theCatalogue Search Engine 35906 may include a‘BusinessTransactionCompletedIndicator’ which specifies whether thecorresponding request message was processed successfully. If the requestmessage was not processed successfully, a ‘TransmissionLog’ includesinformation identifying why the message was not processed, i.e.processing errors that occurred. The request messages (e.g.,CataloguePublicationRequest message 35912) may specify in‘MinimumRequestedLogItemSeverityCode’ what level of information shall bereturned by the response messages, i.e. detailed information onsuccessful processing, warnings, application errors, or aborts.

(5) Message Data Type Catalogue Update Message

The data model for the message data type CatalogueUpdateMessage used toimplement a CatalogueUpdateNotification 35908 is depicted in FIG. 360.The message data type CatalogueUpdateMessage includes aCatalogueUpdateMessage package 36002. The CatalogueUpdateMessage package36002 includes a MessageHeader package 36004, a TransmissionInformationpackage 36006, a Catalogue package 36008, and a CatalogueupdateMessageentity 36010.

(a) Message Header Package

The MessageHeader package 36004 groups the business-related informationrelevant for sending a Business Document in a message. The MessageHeaderpackage 36004 includes a MessageHeader entity 36012. There is a 1:1relationship 36014 between the CatalogueUpdateMessage entity 36010 andthe MessageHeader entity 36012. The MessageHeader entity 36012 includesa SenderParty entity 36016. There is a 1:c relationship 36018 betweenthe MessageHeader entity 36012 and the SenderParty entity 36016.

The MessageHeader groups the business-related information from thesending application's point of view for identifying the BusinessDocument in a message, information about the sender, and potentiallyinformation about the receiver. The MessageHeader entity 36012 is oftype GDT BusinessDocumentMessageHeader.

The SenderParty is the party responsible for sending of a businessdocument on a business-related application level. The SenderParty entity36016 is of type GDT BusinessDocumentMessageHeaderParty.

(b) Transmission Information Package

The TransmissionInformation package 36006 groups the informationpertaining to the transmission of the object or entity (e.g., theCatalogueUpdateMessage entity 36010) included in the message. TheTransmissionInformation package 36006 includes a TransmissionHeaderentity 36020. There is a 1:c relationship 36022 between theCatalogueUpdateMessage entity 36010 and the TransmissionHeader entity36020. A TransmissionHeader entity 36020 provides information about theidentification of a transmission (and one or more of theTransmissionHeader entity's packages). Additionally the minimumrequested severity of events occurring during the processing of thetransmission which have to be logged and returned may be specified. TheTransmissionHeader entity 36020 includes an ID, aPackageOrdinalNumberValue, a PackageTotalNumberValue, and aMinimumRequestedLogItemSeverityCode.

The ID is a unique identification number grouping several data packagesinto one Catalogue transmission, and is of type GDT Transmission ID. ThePackageOrdinalNumberValue specifies the sequence number identifying adata package in a multiple data package transmission, and is of type GDTOrdinalNumberValue. The PackageTotalNumberValue specifies the totalnumber of data packages making up a Catalogue transmission, and is oftype GDT TotalNumberValue. The MinimumRequestedLogItemSeverityCodespecifies the severity of log items to be returned by messagesCataloguePublicationTransmissionPackageNotification andCataloguePublicationConfirmation, and is of type GDTLogItemSeverityCode.

Catalogues often contain such a large amount of data that they may notbe exchanged in one single message. Large catalogues are therefore splitinto smaller part messages (e.g., CatalogueUpdateNotification messages)each of which is transmitted separately.

(c) Catalogue Package

The Catalogue package 36008 groups the information necessary to describethe structure and content of a Catalogue. The Catalogue package 36008includes a GlobalInformation package 36024, a CatalogueModel (“Model”)package 36026, a CatalogueContent (“Content”) package 36028, and aCatalogue entity 36030. There is a 1:1 relationship 36032 between theCatalogueUpdateMessage entity 36010 and the Catalogue entity 36030.

(i) Catalogue Entity

The Catalogue entity 36030 may correspond to a new, changed or deletedCatalogue. A Catalogue entity 36030 is a structured directory ofCatalogue items. Each item represents an object, and providesinformation about the object. The Catalogue entity 36030 referencesglobal information (e.g., as implemented in the GlobalInformationpackage), model information (e.g., as implemented in the CatalogueModelpackage) and content information (e.g., as implemented in theGlobalInformation package). The global information provides informationrelevant to the entire Catalogue. The model information defines thestructure of the Catalogue content and the properties used to describethis content. Content information includes the items of the Catalogueand each of the items structural assignment within the Cataloguestructure.

The Catalogue entity 36030 may include the following elements orattributes:

1) @LanguageCode, which specifies the language for a description or nameassociated with the Calalogue. The @LanguageCode is of type GDT:LanguageCode.

2) @currencyCode, which specifies the currency in an element Amount. The@currencyCode is of type GDT: CurrencyCode.

3) @unitCode, which specifies the unit code in an element Quantity. The@unitCode is of type GDT: MeasureUnitCode

4) @actionCode, which specifies the operation to be performed on thecomplete catalogue. The @actionCode is of type GDT: ActionCode.

5) ID, which identifies the Catalogue being transmitted. The ID is oftype GDT: CatalogueID.

6) VersionID, which identifies the version of the Catalogue beingtransmitted. The VersionID is of type GDT: VersionID.

7) Name, which identifies a name for the entire Catalogue in a languageidentified by @LanguageCode. The Name is of type GDT: Name.

8) TypeCode, which specifies the type of Catalogue being transmitted.For example, TypeCode may indicate the type as a supplier catalogue orpurchasing catalogue. The TypeCode is of type GDT: CatalogueTypeCode.

9) ValidityPeriod, which specifies the period during which the Catalogueis valid. The ValidityPeriod is of type GDT: DateTimePeriod.

For example, the Catalogue may be a products or parts Catalogue thatcorresponds to a directory of objects of type “product” providinginformation about products. In this example, the Catalogue facilitatesfinding products matching certain criteria specified by an actor (e.g.,a catalogue user) and that may then be used in an associated businessprocess. The business process may be for example “procurement,” in whichcase the Catalogue is a “purchasing catalogue” or a “spare partscatalogue,” or “sales catalogue.” In case of a “sales catalogue,”information from the Catalogue may be provided such that the productsseem especially appealing to the target group the Catalogue addresses.Alternatively, the Catalogue may correspond to a supplier directory ofobjects of type “supplier” used in a procurement process.

(ii) Catalogue Global Information Package

The GlobalInformation package 36024 groups the information relevant tothe entire catalogue. The GlobalInformation package 36024 includes aProviderPropertyValuation entity 36034. There is a 1:cn relationship36036 between the Catalogue entity 36030 and theProviderPropertyValuation entity 36034.

The ProviderPropertyValuation valuates properties provided by theCatalogue provider to provide additional information about the Catalogue(e.g., any information about the vendor/s, Catalogue creation date, orNotes). The ProviderPropertyValuation entity 36034 is of type GDT:PropertyValuation, and uses PropertyReference and PropertyValueelements. The PropertyReference specifies the property that is beingvaluated. The PropertyReference is of type GDT: PropertyReference. ThePropertyValue specifies the value of the property. The PropertyValue isof type GDT PropertyValue. As further discussed below, the PropertyValueincludes the following elements: AmountSpecification,QuantitySpecification, DecimalSpecification, FloatSpecification,IntegerSpecification, DateTimeSpecification, NameSpecification, andIndicatorSpecification.

(iii) Catalogue Model Package

The CatalogueModel package 36026 includes a PropertyDefinitionClasspackage 36037, a PropertyDataType package 36038, a Property package36040, a CatalogueItemProperty 36041, a CatalogueSectionType package36042, a CatalogueSchema package 36044, and CatalogueModel entity 36046.There is a 1:c relationship 36048 between the Catalogue entity 36030 andthe CatalogueModel entity 36046.

(a) Catalogue Model

The CatalogueModel describes and structures the Catalogue content usingsystems of categories to group Catalogue items and properties that maybe attributed to the Catalogue items or the categories themselves orboth. The CatalogueModel entity 36046 identifies information regardinghow the Catalogue content is structured and defined. The Catalogue Modelentity 36046 defines properties, the data types of the properties, andallowed values, which are used to describe catalogue sections and/or theitems included in the Catalogue as identified in associatedPropertyDataType package 36038 and Property package 36040. Additionally,the Catalogue Model entity 36046 specifies one or more schemas asidentified in associated CatalogueSchema package 36044, which definesthe structural composition of the Catalogue content by means of sectionsand relationships between these sections. The sections of a schemacorrespond to divided up Catalogue items and include properties used todescribe the Catalogue items assigned to the respective schema section.The CatalogueModel entity 36046 may have multiple schemas. TheCatalogueModel entity 36046 includes aPropertyDataTypeListCompleteTransmissionIndicator, aPropertyListCompleteTransmissionIndicator, aCatalogueSectionTypeListCompleteTransmissionIndicator, and aCatalogueSchemaListCompleteTransmissionIndicator. ThePropertyDataTypeListCompleteTransmissionIndicator specifies whether thelist of PropertyDataTypes has been transmitted completely. ThePropertyDataTypeListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator. ThePropertyListCompleteTransmissionIndicator specifies whether the list ofProperties has been transmitted completely. ThePropertyListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator. TheCatalogueSectionTypeListCompleteTransmissionIndicator specifies whetherthe list of SectionTypes has been transmitted completely. TheCatalogueSectionTypeListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator. TheCatalogueSchemaListCompleteTransmissionIndicator specifies whether thelist of Schemas has been transmitted completely. TheCatalogueSchemaListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator.

(b) Catalogue Model Property Definition Class Package

The PropertyDefinitionClass package groups all information pertaining toproperty definition classes. It contains the PropertyDefinitionClassentity.

(i) Property Definition Class

A PropertyDefinitionClass defines the scope of properties used in theCatalog. The PropertyDefinitionClass is of type GDTPropertyDefinitionClass, where the elements/attributes ID,PrefferedName, and DefinedProperty (Reference and OrdinalNumberValue areused) are used. The element PropertyDefinitionClass may be restried touse only for properties that are components of a structured PropertyData Type and acts only as a construct to bundle these properties. Invariations, the sender of the message can not assume that the messagereceiver persists the transmitted ID's (e.g., assume they aretransient).

(c) Catalogue Model Property Data Type Package

The PropertyDataType package 36038 groups the information pertaining toproperty data types. The PropertyDataType package 36038 includes aPropertyDataType entity 36050. The PropertyDataType defines the datatype of properties used in the Catalogue to describe Catalogue sectionsand Catalogue items. The PropertyDataType entity 36050 is of type GDTPropertyDataType. There is a 1:cn relationship 36052 between theCatalogueModel entity 36046 and the PropertyDataType entity 36050.

The PropertyDataType entity 36050 includes an @actionCode, whichspecifies the operation to be performed on the Property, an ID, aPreferredName, a FormatCode, a MaximumTotalDigitNumberValue, and aFractionalDigitNumberValue. The PropertyDataType entity 36050 may alsoinclude an AllowedPropertyValueElement that has a PropertyValue.

(d) Catalogue Model Property Package

The Property package 36040 groups the information pertaining toproperties used in the catalogue. The Property package 36040 includes aProperty entity 36054. There is a 1:cn relationship 36056 between theCatalogueModel entity 36046 and the PropertyDataType entity 36054.

The Property specifies a property and additional information for it thatmay be used to describe and differentiate between items included orsections used within the catalogue. The Property entity 36054 is of typeGDT Property, and includes the following elements: an @actionCode; anID; a PreferredName; a PropertyDataTypeReference; an AspectID, whichidentifies an aspect in which the Property is used; aTargetInterfaceElementID, which identifies an element of an interfacethe Property may be mapped to; a MultipleValueIndicator, which indicateswhether the Property may contain multiple values; aTextSearchableIndicator, which indicates whether the Property isqualified for “Text Search”; a ParametricSearchableIndicator, whichindicates whether the Property is qualified for “Parametric Search”; anda ValuationRequiredIndicator, which indicates whether a valuation ismandatory on the object which includes this Property. The @actionCodespecifies the operation to be performed on the Property.

(e) Catalogue Model Catalog Item Property Package

The CatalogueItemProperty package 36041 groups all informationpertaining to catalog item properties used in the catalog. It containsthe CatalogueItemProperty entity 36055.

(i) Catalogue Item Property

A CatalogueItemProperty entity 36055 specifies a property pertaining toeach catalogue item together with its position in the full list ofproperties attributed to a catalogue item. It includes the elementsPropertyReference and OrdinalNumberValue. PropertyReference, of type GDTPropertyReference, specifies a property, and only the element ID isused. OrdinalNumberValue, of type GDT OrdinalNumberValue, specifies theposition of the property in the full list. In variations, onlyproperties which are not component properties (see, e.g., GDT Property)may be assigned. It has a cardinality of 1:cn, as denoted by therelationship 36057.

(f) Catalogue Model Section Type Package

The CatalogueModelSectionType or CatalogueSectionType package 36042groups the information necessary to define a section type. TheCatalogueSectionType package 36042 includes a CatalogueSectionTypeentity 36058. The CatalogueSectionType entity 36058 describes the natureof Catalogue sections by defining properties for the description ofsections of this type. There is a 1:cn relationship 36060 between theCatalogueModel entity 36046 and the CatalogueSectionType entity 36058. ACatalogueSectionType entity 36058 may include one or moreSectionProperty entities 36062 each of which describes a respectiveCatalogue section of the CatalogueSectionType entity 36058. Thus, thereis a 1:cn relationship 36064 between the CatalogueSectionType entity36058 and each Property entity 36062.

The CatalogueSectionType entity 36058 includes the following elements:an @actionCode, an ID, and a Name. The @actionCode is of type GDT:Action Code and specifies the operation to be performed on theCatalogueSectionType. The ID is of type GDT: SectionTypeID andidentifies the CatalogueSectionType. The Name is of type GDT: Name andprovides a name for the CatalogueSection type in a language identifiedby @LanguageCode of the Catalogue.

The SectionProperty specifies a property pertaining to a Section typetogether with its position in the list of properties. This propertyshould be attributed to the sections of this Section type. TheSectionProperty entity 36062 includes a PropertyReference and aOrdinalNumberValue. The PropertyReference is of type GDT:PropertyReference and includes an ID that identifies the property. TheOrdinalNumberValue is of type GDT: OrdinalNumberValue and provides theinformation about the place in the list of SectionProperty entities36062.

(g) Catalogue Model Schema Package

The CatalogueModelSchema or CatalogueSchema package 36044 groups theinformation pertaining to a Catalogue schema. It includes aCatalogueSchema entity 36066. The CatalogueSchema entity 36066 defines astructural composition of the Catalogue content in accordance with apre-determined purpose. There is a 1:cn relationship 36068 between theCatalogueModel entity 36046 and the CatalogueSchema entity 36066. TheCatalogueSchema entity 36066 may include one or moreCatalogueItemProperty entities 36070, each of which describes arespective Catalogue item of the CatalogueSchema entity 36066. Inaddition, the CatalogueSchema entity 36066 also may include one or moreCatalogueSection entities 36072 and one or moreCatalogueSectionRelationship entities 36074. There is a 1:cnrelationship 36076 between the CatalogueSchema entity 36066 and theCatalogueItemProperty entity 36070. There is a 1:cn relationship 36078between the CatalogueSchema entity 36066 and the CatalogueSection entity36072. There is a 1:cn relationship 36080 between the CatalogueSchemaentity 36066 and the CatalogueSectionRelationship entity 36074.

The CatalogueSchema entity 36066 includes an @actionCode, an ID, aTypeCode, a Name, a SectionListCompleteTransmissionIndicator, and aSectionRelationshipListCompleteTransmissionIndicator. The @actionCode isof type GDT: ActionCode and specifies the operation to be performed onthe CatalogueSchema entity 36066. The ID is of type GDT:CatalogueSchemaID and identifies the CatalogueSchema entity 36066. TheTypeCode is of type GDT: CatalogueSchemaTypeCode and specifies thenature of the catalogue schema. The Name is of type GDT: Name andprovides a name for a schema in a language identified by @LanguageCodeof the Catalogue. The SectionListCompleteTransmissionIndicator is oftype GDT: CompleteTransmissionIndicator and specifies whether the listof sections has been transmitted completely. TheSectionRelationshipListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list ofSectionRelationships has been transmitted completely. TheCatalogueSchema supports a specific business process or addresses aspecific target group. Thus, the CatalogueSchema may include multipleschemas.

(i) Catalogue Item Property

The CatalogueItemProperty entity 36070 specifies a property pertainingto a catalogue item and the CatalogueItemProperty's 36070 position inthe list of properties attributed to the catalogue item. TheCatalogueItemProperty entity 36070 includes a PropertyReference of typeGDT: PropertyReference and an OrdinalNumberValue of type GDT:OrdinalNumberValue. The PropertyReference has an ID that identifies theproperty associated with the catalogue item. The OrdinalNumberValuespecifies the CatalogueItemProperty's position in the list of propertiesattributed to the catalogue item.

(ii) Catalogue Section

Each CatalogueSection entity 36072 corresponds to a respective set ofcatalogue items in accordance with the CatalogueSchema 36066. EachCatalogueSection entity 36072 specifies properties which may be used todescribe the set of catalogue items. Each CatalogueSection entity 36072may include one more PropertyValuation entities 36082 and one or moreCatalogueItemProperty entities 36084. Thus, there is a 1:cn relationship36086 between the CatalogueSection entity 36072 and thePropertyValuation entity 36082. There is also a 1:cn relationship 36088between the CatalogueSection entity 36072 and the CatalogueItemPropertyentity 36084.

Each CatalogueSection entity 36072 may also include an @actionCode, a@propertyValuationListCompleteTransmissionIndicator, an ID, a TypeID,and a Name. The @actionCode is of type GDT: ActionCode and specifies theoperation to be performed on the respective CatalogueSection entity36072. The ID is of type GDT: CatalogueSectionID and identifiesrespective CatalogueSection entity 36072. The@propertyValuationListCompleteTransmissionIndicator specifies whetherthe list of PropertyValuations is transmitted completely and is of typeGDT: CompleteTransmissionIndicator. The TypeID is of type GDT:CatalogueSectionTypeID and identifies a Section type to which therespective CatalogueSection entity 36072 belongs. The Name is of typeGDT: Name and provides a name for the respective CatalogueSection entity36072 in a language identified by @LanguageCode of the Catalogue entity36030.

(iii) Catalogue Section Property Valuation

Each Property Valuation or CatalogueSectionPropertyValuation entity36082 includes the value of a property that may be attributed to or isused to describe the CatalogueSection entity 36072 in accordance with aCatalogueSection type. The CatalogueSectionPropertyValuation entity36082 is of type GDT PropertyValuation and has a PropertyReference oftype GDT: PropertyReference and a PropertyValue of type GDT:PropertyValue. The PropertyReference references a valuated propertydefined in the CatalogueSectionType corresponding to theCatalogueSection.

(iv) Catalogue Section Catalogue Item Property

Each CatalogueItemProperty or CatalogueSectionCatalogueItemPropertyentity 36084 specifies a property pertaining to the catalogue items orobjects associated with the respective CatalogueSection. TheCatalogueSectionCatalogueItemProperty entity 36084 also specifies theproperty's position in the full list of properties attributed to acatalogue item. The CatalogueSectionCatalogueItemProperty entity 36084includes a PropertyReference of type GDT: PropertyReference and anOrdinalNumberValue of type GDT: OrdinalNumberValue. EachCatalogueSectionCatalogueItemProperty entity 36084 refers to a propertydefined as part of the CatalogueModel and may not be attributed to thecatalogue items within the Catalogue.

(v) Catalogue Section Relationship

Each CatalogueSectionRelationship entity 36074 specifies a connectionbetween two CatalogueSection entities 36072 within a CatalogueSchemaentity 36066. In one implementation, each CatalogueSectionRelationshipentity 36074 corresponds to a parent-child connection between twoCatalogueSection entities 36072, providing a hierarchical structure tothe Catalogue entity 36030. The CatalogueSectionRelationship entity36074 includes an @actionCode, a SourceCatalogueSectionID, and aTargetCatalogueSectionID. The @actionCode is of type GDT: ActionCode andspecifies the operation to be performed on the correspondingCatalogueSectionRelationship entity 36074. The SourceCatalogueSectionIDis of type GDT: CatalogueSectionID and identifies a sourceCatalogueSection entity 36072. The TargetCatalogueSectionID is of typeGDT: CatalogueSectionID and identifies a target CatalogueSection entity36072.

(iv) Catalogue Content Package

The Content or CatalogueContent package 36028 includes a CatalogueItempackage 36090, a CatalogueView package 36092, and a CatalogueContententity 36094. There is a 1:c relationship 36096 between the Catalogueentity 36030 and the CatalogueContent entity 36094. The CatalogueContententity 36094 specifies the list of business objects included in thecatalogue reflected by the Catalogue entity 36030, together with theirrelationships and descriptions according to the catalogue's schemasreflected by the CatalogueSchema entity 36066, and the views (e.g.,CatalogueView) that are used to restrict the catalogue's informationcontent for certain purposes. The CatalogueContent entity 36094 alsospecifies the items (e.g., CatalogueItem) included in the Catalogueentity 36030 and each item's classification or assignment to Cataloguesections reflected by the one or more CatalogueSection entities 36072.The CatalogueContent entity 36094 includes aCatalogueItemListCompleteTransmissionIndicator, aCatalogueItemRelationshipListCompleteTransmissionIndicator, aCatalogueViewListCompleteTransmissionIndicator, and a CatalogueSchemaID.The CatalogueItemListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list of items(e.g., CatalogueItem entities 36098) has been transmitted completely.The CatalogueItemRelationshipListCompleteTransmissionIndicator is oftype GDT: CompleteTransmissionIndicator and specifies whether the listof ItemRelationships (e.g., CatalogueItemRelationship entities 36000A)has been transmitted completely. TheCatalogueViewListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list of Views(e.g., CatalogueView entities 36018A) has been transmitted completely.The CatalogueSchemaID identifies a catalogue schema (e.g., aCatalogueSchema entity 36072) to which the respective CatalogueContententity 36094 is assigned. In one implementation, The CatalogueSchemaIDof a first of the CatalogueContent entities 36094 functions as a defaultvalue for remaining CatalogueContent entities 36094 without a specifiedCatalogueSchemaID.

(a) Catalogue Content Catalogue Item Package

The CatalogueItem package 36090 groups the information pertaining tocatalogue items. The CatalogueItem package 36090 includes aCatalogueItem entity 36098 and a CatalogueItemRelationship entity36000A. There is a 1:cn relationship 36002A between the CatalogueContententity 36094 and the CatalogueItem entity 36098. There is a 1:cnrelationship 36004A between the CatalogueContent entity 36094 and theCatalogueItemRelationship entity 36000A.

(i) Catalogue Item

The CatalogueItem entity 36098 specifies information about an objectincluded and to be classified within the Catalogue entity 36030 inaccordance with the Catalogue entity's 36030 schema as reflected by theCatalogueSchema entity 36066. The CatalogueItem entity 36098 includes aCatalogueItemDescription entity 36006A that describes the item reflectedby the CatalogueItem entity 36098. The CatalogueItem entity 36098 mayalso include a CatalogueItemPropertyValuation entity 36008A and aCatalogueItemClassification entity 36010A. The CatalogueItem entity36098 may further include an @actionCode and an ID. The @actionCode isof type GDT: ActionCode and specifies the operation to be performed onthe item. The ID is of type GDT: CatalogueItemID and identifies therespective CatalogueItem entity 36098.

(ii) Catalogue Item Description

The CatalogueItemDescription entity 36006A is of type GDT: Descriptionand provides a description for an item in a specified language. There isa 1:cn relationship 36012A between the CatalogueItem entity 36098 andthe CatalogueItemDescription entity 36006A.

(iii) Catalogue Item Classification

The CatalogueItemClassification entity 36010A assigns the CatalogueItementity 36098 to a respective CatalogueSection entity 36072 within one ofthe CatalogueSchema entities 36066 associated with the Catalogue entity36030. The CatalogueItemClassification entity 36010A includes a SchemaIDand a SectionID. The SchemaID is of type GDT: CatalogueSchemaID andidentifies the schema (e.g., one of the CatalogueSchema entities 36066)that the CatalogueItem entity 36098 references. The SectionID is of typeGDT: CatalogueSectionID and identifies the section (e.g., one of theCatalogueSection entities 36072) that the CatalogueItem entity 36098references. There is a 1:cn relationship 36016A between theCatalogueItem entity 36098 and the CatalogueItemClassification entity36006A.

(iv) Catalogue Item Property Valuation

The CatalogueItemPropertyValuation entity 36008A is of type GDT:PropertyValuation and specifies the value of a property that may beattributed to the object the CatalogueItem entity 36098 represents inaccordance with one of the CatalogueSchema entities 36066. TheCatalogueItemPropertyValuation entity 36008A includes aPropertyReference and a PropertyValue. The PropertyReference is of typeGDT: PropertyReference and is the reference to the property to bevaluated for the CatalogueItem entity 36098. The PropertyValue is oftype GDT: PropertyValue and is the value of the property reflected bythe PropertyReference. There is a 1:cn relationship 36014A between theCatalogueItem entity 36098 and the CatalogueItemPropertyValuation entity36008A.

(v) Catalogue Item Relationship

The CatalogueItemRelationship entity 36000A specifies a relationshipwith certain semantics between any two CatalogueItem entities 36098. TheCatalogueItemRelationship entity 36000A includes an @actionCode, aSourceCatalogueItemID, a TargetCatalogueItemID, and a TypeCode. The@actionCode is of type GDT: ActionCode and specifies the operation to beperformed on the relationship between the two CatalogueItem entities36098. The SourceCatalogueItemID is of type GDT: CatalogueItemID andidentifies the source CatalogueItem entity 36098. TheTargetCatalogueItemID is of type GDT: CatalogueItemID and identifies thetarget CatalogueItem entity 36098. The TypeCode is of type GDT:ObjectStructureRelationshipTypeCode and specifies the semantics of therelationship existing between the source CatalogueItem entity 36098 andthe target CatalogueItem entity 36098.

(b) Catalogue Content Catalogue View Package

The CatalogueView package 36092 groups the information pertaining toCatalogue views. The CatalogueView package 36092 includes aCatalogueView entity 36018A. There is a 1:cn relationship 36020A betweenthe CatalogueContent entity 36094 and the CatalogueView entity 36018A.

(i) Catalogue View

The CatalogueView entity 36018A defines a subset of a Catalogue byspecifying schemas, sections, Catalogue items and item relationshiptypes to be included and properties to be excluded from a catalogueview. The CatalogueView entity 36018A may include a CatalogueViewSchemaentity 36022A, a CatalogueViewItem entity 36024A and aCatalogueViewItemRelationshipType entity 36026A. In addition, theCatalogueView entity 36018A may include a CatalogueViewExcludedPropertyentity 36028A, which specifies properties not to be included in theview. The CatalogueView entity 36018A includes an @actionCode, an ID, aName, an ItemListCompleteTransmissionIndicator, anItemRelationshipTypeListCompleteTransmissionIndicator, and anExcludedPropertyListCompleteTransmissionIndicator. The @actionCode is oftype GDT: ActionCode and specifies the operation to be performed on theCatalogueView entity 36018A. The ID is of type GDT: CatalogueViewID andidentifies a view ID. The Name is of type GDT: Name and provides a namefor the view in various languages. TheItemListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the item list hasbeen transmitted completely. TheItemRelationshipTypeListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list of itemrelationships has been transmitted completely. TheExcludedPropertyListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list of excludedproperties has been transmitted completely. There is a 1:cn relationship36030A between the CatalogueView entity 36018A and theCatalogueViewSchema entity 36022A. There is a 1:cn relationship 36032Abetween the CatalogueView entity 36018A and the CatalogueViewItem entity36024A. There is a 1:cn relationship 36034A between the CatalogueViewentity 36018A and the CatalogueViewItemRelationshipType entity 36026A.There is a 1:cn relationship 36036A between the CatalogueView entity36018A and the CatalogueViewExcludedProperty entity 36026A.

(ii) Catalogue View Schema

The CatalogueViewSchema entity 36022A specifies a schema and a list ofsections belonging to the schema that are to be included in aCatalogueView entity 36018A. The CatalogueViewSchema entity 36022A issubdivided into one or more CatalogueViewSchemaSection entities 36038Athat specify Sections included in the CatalogueView entity 36018A. Thereis a 1:cn relationship 36040A between the CatalogueViewSchema entity36022A and the CatalogueViewSchemaSection entity 36038A. TheCatalogueViewSchema entity 36022A includes an ID and aSectionListCompleteTransmissionIndicator. The ID is of type GDT:CatalogueSchemaID and identifies the respective CatalogueViewSchemaentity 36022A. The SectionListCompleteTransmissionIndicator is of typeGDT: CompleteTransmissionIndicator and specifies whether the list ofsections (e.g., one or more CatalogueViewSchemaSections) has beentransmitted completely.

(iii) Catalogue View Schema Section

The CatalogueViewSchemaSection entity 36022 specifies a section of thereferenced catalogue schema (e.g., CatalogueViewSchema entity 36022A) tobe included in the catalogue view. The CatalogueViewSchemaSection entity36022 includes an @actionCode is of type GDT: ActionCode and an ID is oftype GDT: CatalogueSectionID. The @actionCode specifies the operation tobe performed on the CatalogueViewSchemaSection entity 36022 identifiedby the ID.

(iv) Catalogue View Item

The CatalogueViewItem entity 36024A specifies a CatalogueItem entity36098 to be included in the catalogue view. The CatalogueViewItem entity36024A includes an @actionCode of type GDT: ActionCode and an ID of typeGDT: CatalogueItemID. The @actionCode specifies the operation to beperformed on the CatalogueViewItem entity 36024A identified by the ID.

(v) Catalogue View Item Relationship Type

The CatalogueViewItemRelationshipType entity 36026A specifies acatalogue item relationship type. In one implementation, the catalogueitem relationships of the CatalogueViewItemRelationshipType entity36026A are included in the catalogue view.CatalogueViewItemRelationshipType entity 36026A includes an @actionCodeof type GDT: ActionCode and a Code of type GDT:ObjectStructureRelationshipType Code. The @actionCode specifies theoperation to be performed on the item relationship type identified bythe Code.

(vi) Catalogue View Excluded Property

The CatalogueViewExcludedProperty 36028A specifies a property that isnot included in the catalogue view. For example, aCatalogueViewExcludedProperty “Price” is defined in the CatalogueContententity 36094 means that users that have access to the content of therespective catalogue reflected by the Catalogue entity 36030 may not seethe price of catalogue items (e.g., CatalogueItem entities 36098) of thecatalogue. The CatalogueViewExcludedProperty 36028A includes an@actionCode of type GDT: ActionCode and a PropertyReference of type GDT:PropertyReference. The @actionCode specifies the operation to beperformed on an excluded property identified by the PropertyReference.

(d) Message Data Type—Element Structure

FIGS. 361A-AA depict the element structure for aCatalogueUpdateNotification message 3598. The element structure issimilar to the data model, but provides additional information regardingthe details of the interface. The element structure identifies thedifferent packages 36100 in the interface, and represents the entitiesat various levels within the interface. As depicted in FIG. 361, theinterface for CatalogueUpdateMessage includes six levels 36102, 36104,36106, 36108, 36110, 36112, and 36114. The outermost package 36100 ofthis interface is a CatalogueUpdateMessage package 36120, which includesa CatalogueUpdateMessage entity 36122 at the first level 36102, aMessageHeader package 36128, a TransmissionInformation package 36162,and a Catalogue package 36104A. The CatalogueUpdateMessage entity 36122is of a type MDT 36124 “CatalogueUpdateMessage” 36126.

The MessageHeader package 36128 includes a MessageHeader entity 36130 atthe second level 36104. The MessageHeader entity 36130 is of a type GDT36134 BusinessDocumentMessageHeader 36136, and there is one 36132MessageHeader entity 36130 for each MessageHeader 36128.

The MessageHeader entity 36130 includes an ID 36138, CreationDateTime36146, and SenderParty 36154 at the third level 36106. The ID 36138 isof a type GDT 36142 “BusinessDocumentMessageID” 36144 and there is one36140 ID 36138 in a MessageHeader entity 36130. The CreationDateTime36146 is of a type GDT 36150 “DateTime” 36152 and there is one 36148CreationDateTime 36146 in a MessageHeader entity 36130. The SenderParty36154 is of a type GDT 36158 “BusinessDocumentMessageHeaderParty” 36160and there is zero or one 36156 SenderParty 36154 in a MessageHeaderentity 36130.

The TransmissionInformation package 36162 includes TransmissionHeaderentity 36164 at the second level 36104. The TransmissionHeader entity36164 is of a type “BusinessDocumentTransmissionHeader” 36170 and thereis zero or one 36166 TransmissionHeader entity 36164 in aTransmissionInformation package 36162.

The TransmissionInformationHeader 36164 includes an ID 36172, aPackageOrdinalNumberValue 36180, a PackageTotalNumberValue 36188, and aMinumumRequestedLogItemServerityCode 36196 at the third level 36106. TheID 36172 is of a type GDT 36176 “TransmissionID” 36178 and there is one36174 ID 36172 in a TransmissionHeader 36164. ThePackageOrdinalNumberValue 36180 is of a type GDT 36184“OrdinalNumberValue” and there is one 36182 PackageOrdinalNumberValue36180 in a TransmissionHeader 36164. The PackageTotalNumberValue 36186is of a type GDT 36192 “TotalNumberValue” 36194 and there is zero or one36190 PackageTotalNumberValue 36188 in a TransmissionHeader 36164. TheMinimumRequestedLogItemServerityCode 36196 is of a type GDT 36100A“LogItemSeverityCode” 36102A and there is zero or one 36198MinimumRequestedLogItemServerityCode in a TransmissionHeader 36164.

The Catalogue package 36104A includes a Catalogue entity 36106A at thesecond level 36104 and a GlobalInformation package 36118B, Model package36190D, and Content package 36102K. The Catalogue entity 36106A is of atype “TransmissionCatalogue” 36112A and there is one 36108A in aCatalogue package 36104A.

The Catalogue entity 36106A includes an @actionCode 36114A, an@completeTransmissionIndicator 36122A, an@providerPropertyValuationListCompleteTransmissionIndicator 36130A, an@languageCode 36138A, an @currencycode 36146A, an @unitCode 36154A, anID 36162A, a version ID 36170A, a Name 36178A, a TypeCode 36186A, and aValidityPeriod 36194A at the third level 36106. The @actionCode 36114Ais of a type GDT 36118A “ActionCode” 36120A, and there is zero or one36116A @actionCode 36114A in a Catalogue entity 36106A. The@completeTransmissionIndicator 36122A is of a type GDT 36126A“CompleteTransmissionIndicator” 36128A, and there is zero or one 36124A@completeTransmissionIndicator 36122A in a Catalogue entity 36106A. The@providerPropertyValuationListCompleteTransmissionIndicator 36130A is ofa type GDT 36134A “CompleteTransmissionIndicator” 36136A, and there iszero or one 36132A@providerPropertyValuationListCompleteTransmissionIndicator 36130A in aCatalogue entity 36106A. The @languageCode 36138A is of a type GDT36142A “LanguageCode” 36144A, and there is zero or one 36140A@languageCode 36138A in a Catalogue entity 36106A. The @currencyCode36146A is of a type GDT 36150A “CurrencyCode” 36152A, and there is zeroor one 36148A @currencyCode 36146A in a Catalogue entity 36106A. The@unitCode 36154A is of a type GDT 36158A “MeasureUnitCode” 36160A, andthere is zero or one 36156A @unitCode 36154A in a Catalogue entity36106A. The ID 36162A is of a type GDT 36166A “CatalogueID” 36168A, andthere is one 36164A ID 36162A in a Catalogue entity 36106A. TheVersionID 36170A is of a type GDT 36174A “VersionID” 36176A, and thereis zero or one 36172A VersionID 36170A in a Catalogue entity 36106A. TheName 36178A is of a type GDT 36182A “Name” 36184A, and there is anynumber of 36180A Name 36178A in a Catalogue entity 36106A. The TypeCode36186A is of a type GDT 36190A “CatalogueTypeCode” 36192A, and there isone 36188A TypeCode 36186A in a Catalogue entity 36106A. TheValidityPeriod 36194A is of a type GDT 36198A “DateTimePeriod” 36100B,and there is zero or one 36196A ValidityPeriod 36194A in a Catalogueentity 36106A.

The ValidityPeriod 36194A includes a StartDateTime 36102B and anEndDateTime 36110B at the fourth level 36108. The StartDateTime 36102Bis of a type GDT 36106B “DateTime” 36108B, and there is zero or one36104B StartDateTime 36102B in a ValidityPeriod 36194A. The EndDateTime36110B is of a type GDT 36114B “DateTime” 36116B, and there is zero orone 36112B EndDateTime 36110B in a ValidityPeriod 36194A.

The GlobalInformation package 36118B includes aProviderPropertyValuation 36120B at the third level 36106. TheProviderPropertyValuation 36120B is of a type GDT 36124B“PropertyValuation” 36126B, and there is any number of 36122BProviderPropertyValuation 36120B in a GlobalInformation 36118B.

The ProviderPropertyValuation 36120B includes an @actionCode 36128B, aPropertyReference 36136B, and a ValueGroup 36152B at the fourth level36108. The @actionCode 36128B is of a type GDT 36132B “ActionCode”36134B, and there is zero or one 36130B @actionCode 36128B in aProviderPropertyValuation 36120B. The PropertyReference 36136B is of atype GDT 36140B “PropertyReference” 36142B, and there is one 36138BPropertyReference 36136B in a ProviderPropertyValuation 36120B.

The PropertyReference 36136B includes an ID 36144 B at the fifth level36110. The ID 36144B is of a type GDT 36148B “PropertyID” 36150B, andthere is one 36146B ID 36144B in a PropertyReference 36136B.

The ValueGroup 36152B is of a type GDT 36156B “PropertyValuelterator”36158B, and there is any number 36154B of ValueGroup 36152B in aProviderPropertyValuation 36120B.

The ValueGroup 36152B includes an ID 36160B, a ParentID 36168B, anOrdinalNumberValue 36176B, and a PropertyValue 36184B of the fifth level36110. The ID 36160B is of a type CCT 36164B “Identifier” 36166B, andthere is zero or one 36162B ID 36160B in a ValueGroup 36152B. TheParentID 36168B is of a type CCT 36172B “Identifier” 36174B, and thereis zero or one 36170B ParentID 36168B in a ValueGroup 36152B. TheOrdinalNumberValue 36176B is of a type GDT 36180B “OrdinalNumberValue”36182B, and there is zero or one 36178B OrdinalNumberValue 36176B in aValueGroup 36152B. The PropertyValue 36184B is of a type GDT 36188B“PropertyValue” 36190B, and there is any number of 36186B PropertyValue36184B in a ValueGroup 36152B.

The PropertyValue 36184B includes an AmountSpecification 36192B, aQuantity Specification 36120C, a DecimalSpecification 36148C, aFloatSpecification 36176C, an IntegerSpecification 36104D, aDateTimeSpecification 36132D, a NameSpecification 36160D, and anIndicatorSpecification 36178D at the sixth level 36112. There is zero orone 36194B AmountSpecification 36192B in a PropertyValue 36184B.

The AmountSpecification 36192B includes an amount 36196B, a LowerAmount36104C, and an UpperAmount 36112C of the seventh level 36114. The Amount36196B is of a type GDT 36100C “Amount” 36102C, and there is zero or one36198B Amount 36196B in a AmountSpecification 36192B. The LowerAmount36104C is of a type GDT 36108C “Amount” 3611C, and there is zero or one36106C LowerAmount 36104C in a AmountSpecification 36192B. TheUpperAmount 36112C is of a type GDT 36116C “Amount” 36118C, and there iszero or one 36114C UpperAmount 36112C in a AmountSpecification 36192B.

There is zero or one 36122C QuantitySpecification 36120C in aPropertyValue 36184B. The QuantitySpecification 36120C includes aQuantity 36124C, a LowerQuantity 36132C, and an UpperQuantity 36140C atthe seventh level 36114. The Quantity 36124C is of a type GDT 36128C“Quantity” 36130C, and there is zero or one 36126C Quantity 36124C in aQuantitySpecification 36120C. The LowerQuantity 36132C is of a type GDT36136C “Quantity” 36138C, and there is zero or one 36134C LowerQuantity36132C in a QuantitySpecification 36120C. The UpperQuantity 36140C is ofa type GDT 36144C “Quantity” 36146C, and there is zero or one 36142CUpperQuantity 36140C in a QuantitySpecification 36120C.

There is zero or one 36150C DecimalSpecification 36148C in aPropertyValue 36184B. The DecimalSpecification 36148C includes aDecimalValue 36152C, a LowerDecimalValue 36160C, and anUpperDecimalValue 36168C at the seventh level 36114. The DecimalValue36152C is of a type GDT 36156C “DecimalValue” 36158C, and there is zeroor one 36154C DecimalValue 36152C in a DecimalSpecification 36148C. TheLowerDecimalValue 36160C is of a type GDT 36164C “DecimalValue” 36166C,and there is zero or one 36162C LowerDecimalValue 36160C in aDecimalSpecification 36148C. The UpperDecimalValue 36168C is of a typeGDT 36172C “DecimalValue” 36174C, and there is zero or one 36170CUpperDecimalValue 36168C in a DecimalSpecification 36148C.

There is zero or one 36178C FloatSpecification 36176C in a PropertyValue36184B. the FloatSpecification 36176 includes a FloatValue 36180C, aLowerFloatValue 36188C, and an UpperFloatValue 36196C at the seventhlevel 36114. The FloatValue 36180C is of a type GDT 36184C “FloatValue”36186C, and there is zero or one 36182 CFloatValue 36180C in aFloatSpecification 36176C. The LowerFloatValue 36188C is of a type GDT36192C “FloatValue” 36194C, and there is zero or one 36190CLowerFloatValue 36188C in a FloatSpecification 36176C. TheUpperFloatValue 36196C is of a type GDT 36100D “FloatValue” 36102D, andthere is zero or one 36198C UpperFloatValue 36196C in aFloatSpecification 36176C.

There is zero or one 36106D IntegerSpecification 36104D in aPropertyValue 36184B. The IntegerSpecificaton 36104D includes anIntegerValue 36108D, a LowerIntegerValue 36116D, and anUpperIntegerValue 36124D at the seventh level 36114. The IntegerValue36108D is of a type GDT 36112D “IntegerValue” 36114D, and there is zeroor one 36110 DIntegerValue 36108D in a IntegerSpecification 36104D. TheLowerIntegerValue 36116D is of a type GDT 36120D “IntegerValue” 36122D,and there is zero or one 36118D LowerIntegerValue 36116D in aIntegerSpecification 36104D. The UpperlntegerValue 36124D is of a typeGDT 36128D “IntegerValue” 36130D, and there is zero or one 36126DUpperIntegerValue 36124D in a IntegerSpecification 36104D.

There is zero or one 36134D DateTimeSpecification 36132D in aPropertyValue 36184B. The DateTimeSpecification 36132D includes aDateTime 36136D, a StartDateTime 36144D, and an EndDateTime 36152D atthe seventh level 36114. The DateTime 36136D is of a type GDT 36140D“DateTime” 36142D, and there is zero or one 36138D DateTime 36136D in aDateTimeSpecification 36132D. The StartDateTime 36144D is of a type GDT36148D “DateTime” 36150D, and there is zero or one 36146D StartDateTime36144D in a DateTimeSpecification 36132D. The EndDateTime 36152D is of atype GDT 36156D “DateTime” 36158D, and there is zero or one 36154DEndDateTime 36152D in a DateTimeSpecification 36132D.

There is zero or one 36162D NameSpecification 36160D in a PropertyValue36184B. The NameSpecification 36160D includes a Name 36164D at theseventh level 36114. The Name 36164D is of a type GDT 36168D “Name”36170D, and there is zero or one 36166D Name 36164D in aNameSpecification 36160D.

There is zero or one 36180D IndicatorSpecification 36178D in aPropertyValue 36184B. The The IndicatorSpecification 36178D includes anIndicator 36182D. The Indicator 36182D is of a type GDT 36186D“Indicator” 36188D, and there is zero or one 36184D Indicator 36182D ina IndicatorSpecification 36178D.

The Model package 36190D includes a Model entity 36192D at the thirdlevel 36106 and a PropertyDefinitionClass 36132E, a PropertyDataTypepackage 36186E, a Propery package 36180F, a CatalogueItemPropertypackage 36194G, a CatalogueSectionType package 36128H, and aCatalogueSchema package 36194H. The Model entity 36192D is of a type“Catalogue Model” 36198D, and there is zero or one 36194D Model entity36192D in a Model package 36190D.

The Model entity 36192D includes an@propertyDataTypeListCompleteTransmissionIndicator 36100E, an@propertyListCompleteTransmissionIndicator 36108E, an@catalogueSectionTypeListCompleteTransmissionIndicator 36116E, and an@catalogueSchemaListCompleteTransmissionIndicator 36124E at the fourthlevel 36108. The @propertyDataTypeListCompleteTransmissionIndicator36100E is of a type GDT 36104E “CompleteTransmissionIndicator” 36106E,and there is zero or one 36102E@propertyDataTypeListCompleteTransmissionIndicator 36100E in a Modelentity 36192D. The @propertyListCompleteTransmissionIndicator 36108E isof a type GDT 36112E “CompleteTransmissionIndicator” 36114E, and thereis zero or one 36110E@propertyListCompleteTransmissionIndicator 36108Ein a Model entity 36192D. The@catalogueSectionTypeListCompleteTransmissionIndicator 36116E is of atype GDT 36120E “CompleteTransmissionIndicator” 36122E, and there iszero or one 36118E@catalogueSectionTypeListCompleteTransmissionIndicator 36116E in a Modelentity 36192D. The @catalogueSchemaListCompleteTransmissionIndicator36124E is of a type GDT 36128E “CompleteTransmissionIndicator” 36130E,and there is zero or one 36126E@catalogueSchemaListCompleteTransmissionIndicator 36124E in a Modelentity 36192D.

The PropertyDefinitionClass package 36132E includes aPropertyDefinitionClass entity 36134E at the fourth level 36108. ThePropertyDefinitionClass entity 36134E is of a type GDT 36138E“PropertyDefinitionClass” 36140E, and there is any number of 36136EPropertyDefinitionClass entity 36134E in a PropertyDefinitionClasspackage 36132E.

The PropertyDefinitionClass 36134E includes an ID 36142E, aPreferredName 36150E, and a DefinedProperty 36158E at the fifth level36110. The ID 36142E is of a type GDT 36146E “PropertyDefinitionClassID”36148E, and there is one 36144E ID 36142E in a PropertyDefinitionClass36134E. The PreferredName 36150E is of a type GDT 36154E “Name” 36156E,and there is one 36152E PreferredName 36150E in aPropertyDefinitionClass 36134E. There is any number of 36160EDefinedProperty 36158E in a PropertyDefinitionClass 36134E.

The DefinedProperty 36158E includes a Reference 36162E and anOrdinalNumberValue 36178E of the sixth level 36112. The Reference 36162Eis of a type GDT 36166E “PropertyReference” 36168E, and there is one36164E Reference 36162E in a DefinedProperty 36158E.

The Reference 36162E includes an ID 36170E at the seventh level. The ID36170E is of a type GDT 36174E “PropertyID” 36176E, and there is one36172E ID 36170E in a Reference 36162E.

The OrdinalNumberValue 36178E is of a type GDT 36182E“OrdinalNumberValue” 36184E, and there is zero or one 36180EOrdinalNumberValue 36178E in a DefinedProperty 36158E.

The PropertyDataType entity 36188E is of a type GDT 36192E“PropertyDataType” 36194E, and there is any number of 36190EPropertyDataType entity 36188E in a PropertyDataType package 36186E.

The PropertyDataType package 36186E includes a PropertyDataType entity36188E at the fifth level 36110. The PropertyDataType entity 36188E isof a type GDT 36192E “PropertyReference” 36194E, and there is any number36190E of PropertyDataType entity 36188E in a PropertyDataType package36186E.

The PropertyDataType 36188E includes an @actionCode 36196E, an ID36104F, a PreferredName 36112F, a FormatCode 36128F, aMaximumTotalDigitNumberValue 36136F, a FractionalDigitNumberValue36144F, a PropertyDefinitionClassReference 36152F, and anAlloedPropertyValueElement 36168F at the fifth level 36110. The@actionCode 36196E is of a type GDT 36100F “ActionCode” 36102F, andthere is zero or one 36198E @actionCode 36196E in a PropertyDataType36188E. The ID 36104F is of a type GDT 36108F “PropertyDataTypeID”36100F, and there is zero or one 36106F ID 36104F in a PropertyDataType36188E. The PreferredName 36112F is of a type GDT 36116F “Name” 36118F,and there is one or more 36114F PreferredName 36112F in aPropertyDataType 36188E.

The PreferredName 36112F includes an @languageCode 36120F at the sixthlevel 36112. The @languageCode 36120F is of a type GDT 36124F“LanguageCode” 36126F, and there is zero or one 36122F@languageCode36120F in a PreferredName 36112F.

The FormatCode 36128F is of a type GDT 36132F“PropertyDataTypeFormatCode” 36134F, and there is one 36130F FormatCode36128F in a PropertyDataType 36188E. The MaximumTotalDigitNumberValue36136F is of a type GDT 36140F “DigitNumberValue” 36142F, and there iszero or one 36138F MaximumTotalDigitNumberValue 36136F in aPropertyDataType 36188E. The FractionalDigitNumberValue 36144F is of atype GDT 36148F “DigitNumberValue” 36150F, and there is zero or one36146F FractionalDigitNumberValue 36144F in a PropertyDataType 36188E.The PropertyDefinitionClassReference 36152F is of a type GDT 36156F“PropertyDefinitionClassReference” 36158F, and there is zero or one36154F PropertyDefinitionClassReference 36152F in a PropertyDataType36188E.

The PropertyDefinitionClassReference 36152F includes an ID 36160F at thesixth level 36112. The ID 36160F is of a type GDT 36164F“PropertyDefinitionClassID” 36166F, and there is one 36162F ID 36160F ina PropertyDefinitionClassReference 36152F.

There is any number of 36170F AllowedPropertyValueElement 36168F in aPropertyDataType 36188E. The AllowedPropertyValueElement 36168F includesa PropertyValue 36172F at the sixth level 36112. The PropertyValue36172F is of a type GDT 36176F “PropertyValue” 36178F, and there is one36174F PropertyValue 36172F in a AllowedPropertyValueElement 36168F.

The Property package 36180F includes a Property entity 36182F at thefourth level 36108. The Property entity 36182F is of a type GDT 36186F“Property” 36188F, and there is any number of 36184F Property entity36182F in a Property package 36180F.

The Property entity 36182F includes an @actionCode 36190F, an ID 36198F,a DefinitionClassReference 36106G, a PreferredName 36122G, aPropertyDataTypeReference 36130G, an AspectID 36146 G, aTargetInterfaceElementID 36154G, a MultipleValueIndicator 36162G, aTextSearchableIndicator 36170G, a ParametricSearchAbleIndicator 36178G,and a ValuationRequiredIndicator 36186G. The @actionCode 36190F is of atype GDT 36194F “ActionCode” 36196F, and there is zero or one 36192F@actionCode 36190F in a Property entity 36182F. The ID 36198F is of atype GDT 36102G “PropertyID” 36104G, and there is one 36100G ID 36198Fin a Property entity 36182F. The DefinitionClassReference 36106G is of atype GDT 36110G “PropertyDefinitionClassReference” 36112G, and there iszero or one 36108G DefinitionClassReference 36106G in a Property entity36182F.

The DefinitionClassReference 36106G includes an ID 36114G at the sixthlevel 36112. The ID 36114G is of a type GDT 36118G“PropertyDefinitionClassID” 36120G, and there is one 36116G ID 36114G ina DefinitionClassReference 36106G.

The PreferredName 36122G is of a type GDT 36126G “Name” 36128G, andthere is at least one 36124G PreferredName 36122G in a Property entity36182F. The PropertyDataTypeReference 36130G is of a type GDT 36134G“PropertyDataTypeReference” 36136G, and there is one 36132GPropertyDataTypeReference 36130G in a Property entity 36182F.

The PropertyDataTypeReference 36130G includes an ID 36138G at the sixthlevel 36112. The ID 36138G is of a type GDT 36142G “PropertyDataTypeID”36144G, and there is one 36140G ID 36138G in a PropertyDataTypeReference36130G. The AspectID 36146G is of a type GDT 36150G “AspectID” 36152G,and there is any number of 36148G AspectID 36146 G in a Property entity36182F. The TargetInterfaceElementID 36154G is of a type GDT 36158G“InterfaceElementID” 36160G, and there is any number of 36156GTargetInterfaceElementID 36154G in a Property entity 36182F. TheMultipleValueIndicator 36162G is of a type GDT 36166G“PropertyMultipleValueIndicator” 36168G, and there is zero or one 36164GMultipleValueIndicator 36162G in a Property entity 36182F. TheTextSearchableIndicator 36170G is of a type GDT 36174G“TextSearchableIndicator” 36176G, and there is zero or one 36172GTextSearchableIndicator 36170G in a Property entity 36182F. TheParametricSearchableIndicator 36178G is of a type GDT 36182G“PropertyParametricSearchableIndicator” 36184G, and there is zero or one36180G ParametricSearchableIndicator 36178G in a Property entity 36182F.The ValuationRequiredIndicator 36186G is of a type GDT 36190G“PropertyValuationRequiredIndicator” 36192G, and there is zero or one36188G ValuationRequiredIndicator 36186G in a Property entity 36182F.

The CatalogueItemProperty package 36194G includes aCatalogueItemProperty entity 96G. The CatalogueItemProperty entity36196G is of a type “CatalogueItemProperty” 36102H, and there is anynumber of 36198G CatalogueItemProperty entity 36196G in aCatalogueItemProperty package 36194G.

The CatalogueItemProperty entity 36196G includes a ProptertyReference36104H and an OrdinalNumberValue 36120H at the fifth level 36110. ThePropertyReference 36104H is of a type GDT 36108H “PropertyReference”36110H, and there is one 36106H PropertyReference 36104H in aCatalogueItemProperty entity 36196G.

The PropertyReference 36104H includes an ID 36112H at the sixth level36112. The ID 36112H is of a type GDT 36116H “PropertyID” 36118H, andthere is one 36114H ID 36112H in a PropertyReference 36104H.

The OrdinalNumberValue 36120H is of a type GDT 36124H“OrdinalNumberValue” 36126H, and there is one 36122H OrdinalNumberValue36120H in a CatalogueItemProperty entity 36196G.

The CatalogueSectionType package 36128H includes a CatalogueSectionTypeentity 36130H at the forth level 36108. The CatalogueSectionType entity36130H is of a type “Catalogue Section Type” 36136H, and there is anynumber of 36132H CatalogueSectionType entities 36130H in aCatalogueSectionType package 36128H.

The CatalogueSectionType entity 36130H includes an @actionCode 36138H,an ID 36146H, aName 36154H, and a SectionProperty 36162H at the fifthlevel 36110. The @actionCode 36138H is of a type GDT 36142H “ActionCode”36144H, and there is zero or one 36140H@actionCode 36138H in aCatalogueSectionType 36130H. The ID 36146H is of a type GDT 36150H“CatalogueSectionTypeID” 36152H, and there is one 36148H ID 36146H in aCatalogueSectionType 36130H. The Name 36154H is of a type GDT 36158H“Name” 36160H, and there is any number of 36156H Name 36154H in aCatalogueSectionType 36130H. The SectionProperty 36162H is of a type“CatalogueSectionTypeSectionProperty” 36168H, and there is any number of36164H SectionProperty 36162H in a CatalogueSectionType 36130H.

The SectionProperty 36162H includes a PropertyReference 36170H and anOrdinalNumberValue 36186H at the sixth level 36112. ThePropertyReference 36170H is of a type GDT 36174H “PropertyReference”36176H, and there is one 36172H PropertyReference 36170H in aSectionProperty 36162H.

The PropertyReference 36170H includes an ID 36178H at the seventh level36114. The ID 36178H is of a type GDT 36182H “PropertyID” 36184H, andthere is one 36180H ID 36178H in a PropertyReference 36170H.

The OrdinalNumberValue 36186H is of a type GDT 36190H“OrdinalNumberValue” 36192H, and there is one 36188H OrdinalNumberValue36186H in a SectionProperty 36162H.

The CatalogueSchemea package 36194H includes a CatalogueSchema entity36196H at the fourth level 36108. The CatalogueSchema entity 36196H isof a type “Catalogue Schema” 361021, and there is any number of 36198HCatalogueSchema entity 36196H in a CatalogueSchema package 36194H.

The CatalogueSchema entity 36196H includes an @actionCode 36104I, an@catalogueSectionListCompleteTransmissionIndicator 36112I, an@catalogueSectionRelationshipListCompleteTransmissionIndicator 36120I,an ID 36128I, a TypeCode 36136I, a Name 36144I, a CatalogueItemProperty36152I, a CatalogueSection 36184I, and a CatalogueSectionRelationship36170J at the fifth level 36110. The @actionCode 36104I is of a type GDT36108I “ActionCode” 36110I, and there is zero or one 36106I@actionCode36104I in a CatalogueSchema 36196H. The@catalogueSectionListCompleteTransmissionIndicator 36112I is of a typeGDT 36116I “CompleteTransmissionIndicator” 36118I, and there is zero orone 36114I@catalogueSectionListCompleteTransmissionIndicator 36112I in aCatalogueSchema 36196H. The@catalogueSectionRelationshipListCompleteTransmissionIndicator 36120I isof a type GDT 36124I “CompleteTransmissionIndicator” 36126I, and thereis zero or one36122I@catalogueSectionRelationshipListCompleteTransmissionIndicator36120I in a CatalogueSchema 36196H. The ID 36128I is of a type GDT36132I “CatalogueSchemaID” 36134I, and there is one 36130I ID 36128I ina CatalogueSchema 36196H. The TypeCode 36136I is of a type GDT 36140I“CatalogueSchemaTypeCode” 36142I, and there is zero or one 36138ITypeCode 36136I in a CatalogueSchema 36196H. The Name 36144I is of atype GDT 36148I “Name” 36150I, and there is any number of 36146I Name36144I in a CatalogueSchema 36196H. The CatalogueItemProperty 36152I isof a type “CatalogueSchemaCatalogueItemProperty” 36158I, and there isany number of 36154I CatalogueItemProperty 36152I in a CatalogueSchema36196H.

The CatalogueItemProperty 36152I includes a PropertyReference 36160I andan OrdinalNumberValue 36176I at the sixth level 36112. ThePropertyReference 36160I is of a type GDT 36164I “PropertyReference”36166I, and there is one 36162I PropertyReference 36160I in aCatalogueItemProperty 36152I.

The PropertyRefernce 36160I includes an ID 36168I at the seventh level36114. The ID 36168I is of a type GDT 36172I “PropertyID” 36174I, andthere is one 36170I ID 36168I in a PropertyReference 36160I.

The OrdinalNumberValue 36176I is of a type GDT 36180I“OrdinalNumberValue” 36182I, and there is one 36178I OrdinalNumberValue36176I in a CatalogueItemProperty 36152I.

The CatalogueSection 36184I is of a type “CatalogueSection” 36190I, andthere is any number of 36186I CatalogueSection 36184I in aCatalogueSchema 36196H.

The CatalogueSection 36184I includes an @actionCode 36192I, an@propertyValuationListCompleteTransmissionIndicator 36100J, an ID36108J, a TypeID 36116J, a Name 36124J, a PropertyValuation 36132J, anda CatalogueItemProperty 36140J The @actionCode 36192I is of a type GDT36196I “ActionCode” 36198I, and there is zero or one 36194I@actionCode36192I in a CatalogueSection 36184I. The@propertyValuationListCompleteTransmissionIndicator 36100J is of a typeGDT 36104J “CompleteTransmissionIndicator” 36106J, and there is zero orone 36102J @propertyValuationListCompleteTransmissionIndicator 36100J ina CatalogueSection 36184I. The ID 36108J is of a type GDT 36112J“CatalogueSectionID” 36114J, and there is one 36110J ID 36108J in aCatalogueSection 36184I. The TypeID 36116J is of a type GDT 36120J“CatalogueSectionTypeID” 36122J, and there is zero or one 36118J TypeID36116J in a CatalogueSection 36184I. The Name 36124J is of a type GDT36128J “Name” 36130J, and there is any number of 36126J Name 36124J in aCatalogueSection 36184I. The PropertyValuation 36132J is of a type GDT36136J “PropertyValuation” 36138J, and there is any number of 36134JPropertyValuation 36132J in a CatalogueSection 36184I. TheCatalogueItemProperty 36140J is of a type“CatalogueSectionCatalogueItemProperty” 36146J, and there is any numberof 36142J CatalogueItemProperty 36140J in a CatalogueSection 36184I.

The CatalogueItemProperty 36140 J includes a PropertyReference 36148J,and an OrdinalNumberValue 36162J at the seventh level 36114. ThePropertyReference 36148J is of a type GDT 36152J “PropertyReference”36154J, and there is one 36150J PropertyReference 36148J in aCatalogueItemProperty 36140J. The OrdinalNumberValue 36162J is of a typeGDT 36166J “OrdinalNumberValue” 36168J, and there is one 36164JOrdinalNumberValue 36162J in a CatalogueItemProperty 36140J.

The CatalogueSectionRelationship 36170J is of a type“CatalogueSectionRelationship” 36176J, and there is any number of 36172JCatalogueSectionRelationship 36170J in a CatalogueSchema 36196H.

The CatalogueSectionRelationship 36170J includes an @actionCode 36178J,a SourceCatalogueSectionID 36186J, and a TargetCatalogueSectionID 36194Jat the sixth level 36112. The @actionCode 36178J is of a type GDT 36182J“ActionCode” 36184J, and there is zero or one 36180J @actionCode 36178Jin a CatalogueSectionRelationship 36170J. The SourceCatalogueSectionID36186J is of a type GDT 36190J “CatalogueSectionID” 36192J, and there isone 36188J SourceCatalogueSectionID 36186J in aCatalogueSectionRelationship 36170J. The TargetCatalogueSectionID 36194Jis of a type GDT 36198J “CatalogueSectionID” 36100K, and there is one36196J TargetCatalogueSectionID 36194J in a CatalogueSectionRelationship36170J.

The Content package 36102K includes a Content entity 36104K at the thirdlevel, a CatalogueItem package 36144K, and a CatalogueView package36158L. The Content entity 36104K is of a type “CatalogueContent”36110K, and there is zero or one 36106K Content entity 36104K in aContent package 36102K.

The Content entity 36104K includes an@catalogueItemListCompleteTransmissionIndicator 36112K, an@catalogueItemRelationshipListCompleteTransmissionIndicator 36120K, an@catalogueViewListCompleteTransmissionIndicator 36128K, and aCatalogueSchemaID 36136K at the fourth level 36108. The@catalogueItemListCompleteTransmissionIndicator 36112K is of a type GDT36116K “CompleteTransmissionIndicator” 36118K, and there is zero or one36114K @catalogueItemListCompleteTransmissionIndicator 36112K in aContent 36104K. The@catalogueItemRelationshipListCompleteTransmissionIndicator 36120K is ofa type GDT 36124K “CompleteTransmissionIndicator” 36126K, and there iszero or one36122K@catalogueItemRelationshipListCompleteTransmissionIndicator 36120Kin a Content 36104K. “The@catalogueViewListCompleteTransmissionIndicator 36128K is of a type GDT36132K “CompleteTransmissionIndicator” 36134K, and there is zero or one36130K @catalogueViewListCompleteTransmissionIndicator 36128K in aContent 36104K. The CatalogueSchemaID 36136K is of a type GDT 36140K“CatalogueSchemaID” 36142K, and there is zero or one 36138KCatalogueSchemaID 36136K in a Content 36104K.

The CatalogueItem package 36144K includes a CatalogueItem entity 36146Kand a CatalogueItemRelationship 36118L at the fourth level 36108. TheCatalogueItem entity 36146K is of a type “Catalogue Item” 36152K, andthere is any number of 36148K CatalogueItem entity 36146K in aCatalogueItem package 36144K.

The CatalogueItem entity 36146K includes an @actionCode 36154K, an@propertyValuationListCompleteTransmissionIndicator 36162K, an ID36170K, a Description 36178K, a Classification 36186K, and aPropertyValuation 36110L at the fifth level 36110. The @actionCode36154K is of a type GDT 36158K “ActionCode” 36160K, and there is zero orone 36156K @actionCode 36154K in a CatalogueItem 36146K. The@propertyValuationListCompleteTransmissionIndicator 36162K is of a typeGDT 36166K “CompleteTransmissionIndicator” 36168K, and there is zero orone 36164K @propertyValuationListCompleteTransmissionIndicator 36162K ina CatalogueItem 36146K. The ID 36170K is of a type GDT 36174K“CatalogueItemID” 36176K, and there is one 36172K ID 36170K in aCatalogueItem 36146K. The Description 36178K is of a type GDT 36182K“Description” 36184K, and there is any number of 36180K Description36178K in a CatalogueItem 36146K. The Classification 36186K is of a type“CatalogueItemClassification” 36192K, and there is any number of 36188KClassification 36186K in a CatalogueItem 36146K.

The Classification 36186K includes a CatalogueSchemaID 36194K and aCatalogueSectionID 36102L at the sixth level 36112. TheCatalogueSchemaID 36194K is of a type GDT 36198K “CatalogueSchemaID”36100L, and there is zero or one 36196K CatalogueSchemaID 36194K in aClassification 36186K. The CatalogueSectionID 36102L is of a type GDT36106L “CatalogueSectionID” 36108L, and there is one 36104LCatalogueSectionID 36102L in a Classification 36186K.

The PropertyValuation 36110L is of a type GDT 36114L “PropertyValuation”36116L, and there is any number of 36112L PropertyValuation 36110L in aCatalogueItem 36146K.

The CatalogueItemRelationship 36118L is of a type“CatalogueItemRelationship” 36124L, and there is any number of 36120LCatalogueItemRelationship 36118L in a Content 36104K.

The CatalogueItemRelationship 36118L includes an @actionCode 36126L, aSourceCatalogueItemID 36134L, a TargetCatalogueItemID 36142L, and aTypeCode 36150L at the fifth level 36110. The @actionCode 36126L is of atype GDT 36130L “ActionCode” 36132L, and there is zero or one 36128L@actionCode 36126L in a CatalogueItemRelationship 36118L. TheSourceCatalogueItemID 36134L is of a type GDT 36138L “CatalogueItemID”36140L, and there is one 36136L SourceCatalogueItemID 36134L in aCatalogueItemRelationship 36118L. The TargetCatalogueItemID 36142L is ofa type GDT 36146L “CatalogueItemID” 36148L, and there is one 36144LTargetCatalogueItemID 36142L in a CatalogueItemRelationship 36118L. TheTypeCode 36150L is of a type GDT 36154L“ObjectStructureRelationshipTypeCode” 36156L, and there is one 36152LTypeCode 36150L in a CatalogueItemRelationship 36118L.

The CatalogueView Package includes a CatalogueView entity 36160L at thefourth level 36108. The CatalogueView entity 36160L is of a type“CatalogueView” 36166L, and there is any number of 36162L CatalogueViewentity 36160L in a CatalogueView package 36158L.

The CataloguView entity includes an @actionCode 36168L, an@itemListCompleteTransmissionIndicator 36176L, an@itemRelationshipTypeListCompleteTransmissionIndicator 36184L, an@excludedPropertyListCompleteTransmissionIndicator 36192L, an ID 36100M,a Name 36108M, a Schema 36116M, an Item 36164M, an ItemRelationshipType36188M, and an ExcludedProperty 36112N at the fifth level 36110. The@actionCode 36168L is of a type GDT 36172L “ActionCode” 36174L, andthere is zero or one 36170L @actionCode 36168L in a CatalogueView36160L. The @itemListCompleteTransmissionIndicator 36176L is of a typeGDT 36180L “CompleteTransmissionIndicator” 36182L, and there is zero orone 36178L @itemListCompleteTransmissionIndicator 36176L in aCatalogueView 36160L. The@itemRelationshipTypeListCompleteTransmissionIndicator 36184L is of atype GDT 36188L “CompleteTransmissionIndicator” 36190L, and there iszero or one 36186L@itemRelationshipTypeListCompleteTransmissionIndicator 36184L in aCatalogueView 36160L. The@excludedPropertyListCompleteTransmissionIndicator 36192L is of a typeGDT 36196L “CompleteTransmissionIndicator” 36198L, and there is zero orone 36194L @excludedPropertyListCompleteTransmissionIndicator 36192L ina CatalogueView 36160L. The ID 36100M is of a type GDT 36104M“CatalogueViewID” 36106M, and there is one 36102M ID 36100M in aCatalogueView 36160L. The Name 36108M is of a type GDT 36112M “Name”36114M, and there is any number of 36100M Name 36108M in a CatalogueView36160L. The Schema 36116M is of a type “CatalogueViewSchema” 36122M, andthere is any number of 36118M Schema 36116M in a CatalogueView 36160L.

The Schema 36116M includes an @sectionListCompleteTransmissionIndicator36124M, a CatalogueSchemaID 36132M, and a Section 36140M at the sixthlevel 36112. The @sectionListCompleteTransmissionIndicator 36124M is ofa type GDT 36128M “CompleteTransmissionIndicator” 36130M, and there iszero or one 36126M @sectionListCompleteTransmissionIndicator 36124M in aSchema 36116M. The CatalogueSchemaID 36132M is of a type GDT 36136M“CatalogueSchemaID” 36138M, and there is one 36134M CatalogueSchemaID36132M in a Schema 36116M. The Section 36140M is of a type“CatalogueViewSchemaSection” 36146M, and there is any number of 36142MSection 36140M in a Schema 36116M.

The Section 36140M includes an @actionCode 36148 and aCatalogueSectionld 36156M at the seventh level 36114. The @actionCode36148M is of a type GDT 36152M “ActionCode” 36154M, and there is zero orone 36150M @actionCode 36148M in a Section 36140M. TheCatalogueSectionID 36156M is of a type GDT 36160M “CatalogueSectionID”36162M, and there is one 36158M CatalogueSectionID 36156M in a Section36140M.

The Item 36164M is of a type “CatalogueViewItem” 36170M, and there isany number of 36166M Item 36164M in a CatalogueView 36160L.

The Item 36164M includes an @actionCode 36172M and a CatalogueItemID36180M at the sixth level 36112. The @actionCode 36172M is of a type GDT36176M “ActionCode” 36178M, and there is zero or one 36174M @actionCode36172M in a Item 36164M. The CatalogueItemID 36180M is of a type GDT36184M “CatalogueItemID” 36186M, and there is one 36182M CatalogueItemID36180M in a Item 36164M.

The ItemRelationshipType 36188M is of a type“CatalogueViewItemRelationshipType” 36194M, and there is any number of36190M ItemRelationshipType 36188M in a CatalogueView 36160L.

The ItemRelationshipType 36188M includes an @actionCode 36196M and aCatalogueItemRelationshipTypeCode 36104N at the sixth level 36112. The@actionCode 36196M is of a type GDT 36100N “ActionCode” 36102N, andthere is zero or one 36198M @actionCode 36196M in a ItemRelationshipType36188M. The CatalogueItemRelationshipTypeCode 36104N is of a type GDT36108N “ObjectStructureRelationshipTypeCode” 36110N, and there is one36106N CatalogueItemRelationshipTypeCode 36104N in aItemRelafionshipType 36188M.

The ExcludedProperty 36112N is of a type “CatalogueViewExcludedProperty”36118N, and there is any number of 36114N ExcludedProperty 36112N in aCatalogueView 36160L.

The ExcludedProperty 36112N includes an @actionCode 36120N and aPropertyReference 36128N at the sixth level 36112. The @actionCode36120N is of a type GDT 36124N “ActionCode” 36126N, and there is zero orone 36122N@actionCode 36120N in a ExcludedProperty 36112N. ThePropertyReference 36128N is of a type GDT 36132N “PropertyReference”36134N, and there is one 36130N PropertyReference 36128N in aExcludedProperty 36112N.

The PropertyReference 36128N includes an ID 36135N at the seventh level.The ID 36136N is of a type GDT 36140N “PropertyID” 36142N, and there isone 36138N ID 36136N in a PropertyReference 36128N.

(6) Message Data Type Catalogue Publication Message

The data model for the message data type CataloguePublicationMessageused to implement a CataloguePublicationRequest 35910 is depicted inFIG. 362. The data model for the message data typeCataloguePublicationMessage is similar to the data model for the messagedata type CatalogueUpdateMessage as discussed above. The message datatype CataloguePublicationMessage includes a CataloguePublicationMessagepackage 36202. The CataloguePublicationMessage package 36202 includes aMessageHeader package 36204, a TransmissionInformation package 36206, aCatalogue package 36208, and a CataloguePublicationMessage entity 36210.

(a) Message Header Package

A MessageHeader package 36204 groups the business-related informationrelevant for sending a Business Document in a message. The MessageHeaderpackage 36204 includes a MessageHeader entity 36212 and a SenderPartyentity 36216. There is a 1:1 relationship 36214 between theMessageHeader entity 36212 and the CataloguePublicationMessage entity36210. There is a 1:c relationship 36218 between the MessageHeaderentity 36212 and the SenderParty entity 36216.

The MessageHeader entity 36212 groups the business-related informationfrom the sending application's point of view for identifying theBusiness Document in a message, information about the sender, andpotentially information about the receiver. The MessageHeader entity36212 is of type GDT BusinessDocumentMessageHeader.

The SenderParty entity 36216 is the party responsible for sending of abusiness document on a business-related application level. TheSenderParty entity 36216 is of type GDTBusinessDocumentMessageHeaderParty.

(b) Transmission Information Package

The TransmissionInformation package 36206 groups the informationpertaining to the transmission of the object or entity (e.g., theCataloguePublicationMessage entity 36210) included in the message. TheTransmissionInformation package 36206 includes a TransmissionHeaderentity 36220. There is a 1:c relationship 36222 between theCataloguePublicationMessage entity 36210 and the TransmissionHeaderentity 36220. A TransmissionHeader entity 36220 provides informationabout the identification of a transmission (and one or more of theTransmissionHeader entity's 36218 packages). Additionally the minimumrequested severity of events occurring during the processing of thetransmission which have to be logged and returned may be specified. TheTransmissionHeader entity 36220 includes an ID, aPackageOrdinalNumberValue, a PackageTotalNumberValue, and aMinimumRequestedLogItemSeverityCode.

The ID is a unique identification number grouping several data packagesinto one Catalogue transmission, and is of type GDT Transmission ID. ThePackageOrdinalNumberValue specifies the sequence number identifying adata package in a multiple data package transmission, and is of type GDTOrdinalNumberValue. The PackageTotalNumberValue specifies the totalnumber of data packages making up a Catalogue transmission, and is oftype GDT TotalNumberValue. The MinimumRequestedLogItemSeverityCodespecifies the severity of log items to be returned by messagesCataloguePublicationTransmissionPackageNotification andCataloguePublicationConfirmation, and is of type GDTLogItemSeverityCode.

Catalogues often contain such a large amount of data that they may notbe exchanged in one single message. Large catalogues are therefore splitinto smaller part messages (e.g., CataloguePublication Notificationmessages 35910) each of which is transmitted separately.

(c) Catalogue Package

The Catalogue package 36208 groups the information necessary to describethe structure and content of a Catalogue. The Catalogue package 36208includes a GlobalInformation package 36224, a CatalogueModel (“Model”)package 36226, a CatalogueContent (“Content”) package 36228, and aCatalogue entity 36230. There is a 1:1 relationship 36232 between theCataloguePublicationMessage entity 36210 and the Catalogue entity 36230.

(i) Catalogue Entity

A Catalogue entity 36230 included in a CataloguePublication Message36202 may correspond to a new, changed or deleted Catalogue. A Catalogueentity 36230 is a structured directory of Catalogue items. Each itemrepresents an object, and provides information about the object. TheCatalogue entity 36230 references global information (e.g., asimplemented in the GlobalInformation package 36224), model information(e.g., as implemented in the CatalogueModel package 36226) and contentinformation (e.g., as implemented in the GlobalInformation package36228). The global information provides information relevant to theentire Catalogue entity 36230. The model information defines thestructure of the Catalogue entity 36230 content and the properties usedto describe this content. Content information includes the items of theCatalogue entity 36230 and each of the items structural assignmentwithin the Catalogue entity 36230 structure.

The Catalogue entity 36230 may include the following elements orattributes:

1) @LanguageCode, which specifies the language for a description or nameassociated with the Calalogue entity 36222. The @LanguageCode is of typeGDT: LanguageCode.

2) @currencyCode, which specifies the currency in an element Amount. The@currencyCode is of type GDT: CurrencyCode.

3) @unitCode, which specifies the unit code in an element Quantity. The@unitCode is of type GDT: MeasureUnitCode

4) @actionCode, which specifies the operation to be performed on thecomplete catalogue. The @actionCode is of type GDT: ActionCode.

5) @completeTransmissionIndicator, which indicates whether all data ofthe catalog is included or not. The @completeTransmissionIndicator is oftype GDT: CompleteTransmissionIndicator.

6) @providerPropertyValuationListCompleteTransmissionIndicator, whichindicates whether the list of ProviderPropertyValuation is transmittedcompletely or not. The@providerPropertyValuationListCompleteTransmissionIndicator is of typeGDT: CompleteTransmissionIndicator.

7) ID, which identifies the Catalogue entity 36230 being transmitted.The IDis of type GDT: CatalogueID.

8) VersionID, which identifies the version of the Catalogue entity 36230being transmitted. The VersionID is of type GDT: VersionID.

9) Name, which identifies a name for the entire Catalogue in a languageidentified by @LanguageCode. The Name is of type GDT: Name.

10) TypeCode, which specifies the type of Catalogue entity 36230 beingtransmitted. For example, TypeCode may indicate the type as a suppliercatalogue or purchasing catalogue. The TypeCode is of type GDT:CatalogueTypeCode.

11) ValidityPeriod, which specifies the period during which theCatalogue entity 36230 is valid. The ValidityPeriod is of type GDT:DateTimePeriod.

For example, the Catalogue entity 36230 may be a products or partsCatalogue that corresponds to a directory of objects of type “product”providing information about products. In this example, the Catalogueentity 36230 facilitates finding products matching certain criteriaspecified by an actor (e.g., a catalogue user) and that may then be usedin an associated business process. The business process may be forexample “procurement,” in which case the Catalogue entity 36230 is a“purchasing catalogue” or a “spare parts catalogue,” or “salescatalogue.” In case of a “sales catalogue,” information from theCatalgoue entity 36222 may be provided such that the products seemespecially appealing to the target group the Catalogue addresses.Alternatively, the Catalogue entity 36230 may correspond to a supplierdirectory of objects of type “supplier” used in a procurement process.

(ii) Catalogue Global Information Package

The GlobalInformation package 36224 groups the information relevant tothe entire catalogue. The GlobalInformation package 36224 includes aProviderPropertyValuation entity 36234. There is a 1:cn relationship36236 between the CataloguePublicationMessage entity 36210 and theCatalogue entity 36230.

A ProviderPropertyValuation entity 36234 valuates properties provided bythe Catalogue provider 35902 to provide additional information about theCatalogue entity 36230 (e.g., any information about the vendor/s,Catalogue creation date, or Notes). ProviderPropertyValuation entity36234 is of type GDT: PropertyValuation, and uses PropertyReference andPropertyValue elements. The PropertyReference specifies the propertythat is being valuated. The PropertyReference is of type GDT:PropertyReference. The PropertyValue specifies the value of theproperty. The PropertyValue is of type GDT PropertyValue. As furtherdiscussed below, the PropertyValue includes the following elements:AmountSpecification, QuantitySpecification, DecimalSpecification,FloatSpecification, IntegerSpecification, DateTimeSpecification,NameSpecification, and IndicatorSpecification.

(iii) Catalogue Model Package

The CatalogueModel package 36226 includes a PropertyDataType package36238, a Property package 36240, a CatalogueItemProperty package 36241,a CatalogueSectionType package 36242, and a CatalogueSchema package36244, and CatalogueModel entity 36246. There is a 1:c relationship36248 between the Catalogue entity 36230 and the CatalogueModel entity36246.

(a) Catalogue Model

A CatalogueModel entity 36246 describes and structures the Cataloguecontent using systems of categories to group Catalogue items andproperties that may be attributed to the Catalogue items or thecategories themselves or both. The CatalogueModel entity 36246 is theinformation how the Catalogue content is structured and defined. TheCatalogue Model entity 36246 defines properties, the data types of theproprerties, and allowed values, which are used to describe cataloguesections and/or the items included in the Catalogue as identified inassociated PropertyDataType package 36238 and Property package 36240.Additionally, the Catalogue Model entity 36246 specifies one or moreschemas as identified in associated CatalogueSchema package 36244, whichdefines the structural composition of the Catalogue content by means ofsections and relationships between these sections. The sections of aschema correspond to divided up Catalogue items and include propertiesused to describe the Catalogue items assigned to the respective schemasection. The CatalogueModel entity 36246 may have multiple schemas. TheCatalogueModel entity 36246 includes a@PropertyDataTypeListCompleteTransmissionIndicator, a@PropertyListCompleteTransmissionIndicator, a@CatalogueSectionTypeListCompleteTransmissionIndicator, and a@CatalogueSchemaListCompleteTransmissionIndicator. The@PropertyDataTypeListCompleteTransmissionIndicator specifies whether thelist of PropertyDataTypes has been transmitted completely. The@PropertyDataTypeListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator. The@PropertyListCompleteTransmissionIndicator specifies whether the list ofProperties has been transmitted completely. The@PropertyListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator. The@CatalogueSectionTypeListCompleteTransmissionIndicator specifies whetherthe list of SectionTypes has been transmitted completely. The@CatalogueSectionTypeListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator. The@CatalogueSchemaListCompleteTransmissionIndicator specifies whether thelist of Schemas has been transmitted completely. The@CatalogueSchemaListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator.

(b) Catalogue Model Property Data Type Package

The PropertyDataType package 36238 groups the information pertaining toproperty data types. The PropertyDataType package 36238 includes aPropertyDataType entity 36250. A PropertyDataType entity 36250 definesthe data type of properties used in the Catalogue entity 36230 todescribe Catalogue sections and Catalogue items. The PropertyDataTypeentity 36250 is of type GDT PropertyDataType. There is a 1:cnrelationship 36252 between the CatalogueModel entity 36246 and thePropertyDataType entity 36250.

The PropertyDataType entity 36250 includes an @actionCode, whichspecifies the operation to be performed on the Property, an ID, aPreferredName, a FormatCode, a MaximumTotalDigitNumberValue, and aFractionalDigitNumberValue. The PropertyDataType entity 36250 may alsoinclude an AllowedPropertyValueElement that has a PropertyValue.

(c) Catalogue Model Property Package

The Property package 36240 groups the information pertaining toproperties used in the catalogue. The Property package 36240 includes aProperty entity 36254. There is a 1:cn relationship 36252 between theCatalogueModel entity 36246 and the PropertyDataType entity 36250. Thereis a 1:cn relationship 36256 between the CatalogueModel entity 36246 andthe Property entity 36254.

The Property entity 36254 specifies a property and additionalinformation for it that may be used to describe and differentiatebetween items included or sections used within the catalogue. TheProperty entity 36254 is of type GDT Property, and includes thefollowing elements: an @actioncode; an ID; a PreferredName; aPropertyDataTypeReference; an AspectID, which identifies an aspect inwhich the Property entity 36254 is used; a TargetInterfaceElementID,which identifies an element of an interface the Property entity 36254may be mapped to; a MultipleValueIndicator, which indicates whether theProperty entity 36254 may contain multiple values; aTextSearchableIndicator, which indicates whether the Property entity36254 is qualified for “Text Search”; a ParametricSearchableIndicator,which indicates whether the Property entity 36254 is qualified for“Parametric Search”; and a ValuationRequiredIndicator, which indicateswhether a valuation is mandatory on the object which includes thisProperty entity 36254. The @actionCode specifies the operation to beperformed on the Property entity 36254.

(d) Catalogue Model Catalog Item Property Package

The CatalogueItemProperty package 36041 groups all informationpertaining to catalog item properties used in the catalog. It containsthe CatalogueItemProperty entity 36055.

(i) Catalogue Item Property

A CatalogueItemProperty entity 36055 specifies a property pertaining toeach catalogue item together with its position in the full list ofproperties attributed to a catalogue item. It includes the elementsPropertyReference and OrdinalNumberValue. PropertyReference, of type GDTPropertyReference, specifies a property, and only the element ID isused. OrdinalNumberValue, of type GDT OrdinalNumberValue, specifies theposition of the property in the full list. In variations, onlyproperties which are not component properties (see, e.g., GDT Property)may be assigned. It has a cardinality of 1:cn, as denoted by therelationship 36057.

(e) Catalogue Model Section Type Package

The CatalogueModelSectionType or CatalogueSectionType package 36242groups the information necessary to define a section type. TheCatalogueSectionType package 36242 includes a CatalogueSectionTypeentity 36258. The CatalogueSectionType entity 36258 describes the natureof Catalogue sections by defining properties for the description ofsections of this type. There is a 1:cn relationship 36260 between theCatalogueModel entity 36246 and the CatalogueSectionType entity 36258. ACatalogueSectionType entity 36258 may include one or moreSectionProperty entities 36262 each of which describes a respectiveCatalogue section of the CatalogueSectionType entity 36258. Thus, thereis a 1:cn relationship 36264 between the CatalogueModel entity 36246 andeach Property entity 36262.

The CatalogueSectionType entity 36258 includes the following elements:an @actionCode, an ID, and a Name. The @actionCode is of type GDT:Action Code and specifies the operation to be performed on theCatalogueSectionType entity 36258. The ID is of type GDT: SectionTypeIDand identifies the CatalogueSectionType entity 36258. The Name is oftype GDT: Name and provides a name for the CatalogueSection type in alanguage identified by @LanguageCode of the Catalogue entity 36230.

A SectionProperty 36262 specifies a property pertaining to theCatalogueSectionType entity 36258 and the SectionProperty's 36262position in the list of SectionProperty entities 36262 associated withthe CatalogueSectionType entity 36258. The SectionProperty 36262includes a PropertyReference and a OrdinalNumberValue. ThePropertyReference is of type GDT: PropertyReference and includes an IDthat identifies the SectionProperty 36262. The OrdinalNumberValue is oftype GDT: OrdinalNumberValue and provides the SectionProperty's 36262position in the list of SectionProperty entities 36262.

(f) Catalogue Model Schema Package

The CatalogueModelSchema or CatalogueSchema package 36244 groups theinformation pertaining to a Catalogue schema. It includes aCatalogueSchema entity 36266. The CatalogueSchema entity 36266 defines astructural composition of the Catalogue content in accordance with apre-determined purpose. There is a 1:cn relationship 36268 between theCatalogueModel entity 36246 and the CatalogueSchema entity 36266. TheCatalogueSchema entity 36266 may include one or moreCatalogueItemProperty entities 36270 each of which describes arespective Catalogue item of the CatalogueSchema entity 36266. Inaddition, the CatalogueSchema entity 36266 also may include one or moreCatalogueSection entities 36272 and one or moreCatalogueSectionRelationship entities 36274. There is a 1:cnrelationship 36276 between the CatalogueSchema entity 36266 and eachCatalogueItemProperty entity 36270. There is a 1:cn relationship 36278between the CatalogueSchema entity 36266 and each CatalogueSectionentity 36272. There is a 1:cn relationship 36280 between theCatalogueSchema entity 36266 and each CatalogueSectionRelationshipentity 36274.

The CatalogueSchema entity 36266 includes an @actionCode, an ID, aTypeCode, a Name, a SectionListCompleteTransmissionIndicator, and aSectionRelationshipListCompleteTransmissionIndicator. The @actionCode isof type GDT: ActionCode and specifies the operation to be performed onthe CatalogueSchema entity 36266. The ID is of type GDT:CatalogueSchemaID and identifies the CatalogueSchema entity 36266. TheTypeCode is of type GDT: CatalogueSchemaTypeCode and specifies thenature of the catalogue schema. The Name is of type GDT: Name andprovides a name for a schema in a language identified by @LanguageCodeof the Catalogue entity 36230. TheSectionListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list of sectionshas been transmitted completely. TheSectionRelationshipListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list ofSectionRelationships has been transmitted completely. TheCatalogueSchema entity 36266 supports a specific business process oraddresses a specific target group. Thus, the CatalogueSchema entity36266 may include multiple schemas.

(i) Catalogue Item Property

The CatalogueItemProperty entity 36270 specifies a property pertainingto a catalogue item and the CatalogueItemProperty's 36270 position inthe list of properties attributed to the catalogue item. TheCatalogueItemProperty entity 36270 includes a PropertyReference of typeGDT: PropertyReference and an OrdinalNumberValue of type GDT:OrdinalNumberValue. The PropertyReference has an ID that identifies theproperty associated with the catalogue item. The OrdinalNumberValuespecifies the CatalogueItemProperty's 36270 position in the list ofproperties attributed to the catalogue item.

(ii) Catalogue Section

Each CatalogueSection entity 36272 corresponds to a respective set ofcatalogue items in accordance with the CatalogueSchema 36266. EachCatalogueSection entity 36272 specifies properties which may be used todescribe the set of catalogue items. Each CatalogueSection entity 36272may include one more more PropertyValuation entities 36282 and one ormore CatalogueItemProperty entities 36284. Thus, there is a 1:cnrelationship 36286 between the CatalogueSection entity 36272 and eachPropertyValuation entity 36282. There is also a 1:cn relationship 36288between the CatalogueSection entity 36272 and each CatalogueItemPropertyentity 36284.

Each CatalogueSection entity 36272 may also include an @actionCode, anID, a TypeID, and a Name. The @actionCode is of type GDT: ActionCode andspecifies the operation to be performed on the respectiveCatalogueSection entity 36272. The ID is of type GDT: CatalogueSectionIDand identifies respective CatalogueSection entity 36272. The TypeID isof type GDT: CatalogueSectionTypeID and identifies a Section type towhich the respective CatalogueSection entity 36272 belongs. The Name isof type GDT: Name and provides a name for the respectiveCatalogueSection entity 36272 in a language identified by @LanguageCodeof the Catalogue entity 36230.

(iii) Catalogue Section Property Valuation

Each Property Valuation or CatalogueSectionPropertyValuation 36282includes the value of a property that may be attributed to or is used todescribe the CatalogueSection entity 36272 in accordance with aCatalogueSection type 36258. The CatalogueSectionPropertyValuationentity 36282 is of type GDT PropertyValuation and has aPropertyReference of type GDT: PropertyReference and a PropertyValue oftype GDT: PropertyValue. The PropertyReference references a valuatedproperty defined in the CatalogueSectionType entity 36258 correspondingto the CatalogueSection 36272.

(iv) Catalogue Section Catalogue Item Property

Each CatalogueItemProperty or CatalogueSectionCatalogueItemPropertyentity 36284 specifies a property pertaining to the catalogue items orobjects associated with the respective CatalogueSection entity 36272.The CatalogueSectionCatalogueItemProperty entity 36284 also specifiesthe property's position in the full list of properties attributed to acatalogue item. The CatalogueSectionCatalogueItemProperty entity 36284includes a PropertyReference of type GDT: PropertyReference and anOrdinalNumberValue of type GDT: OrdinalNumberValue. EachCatalogueSectionCatalogueItemProperty entity 36284 refers to a propertydefined as part of the CatalogueModel entity 36246 and may not beattributed to the catalogue items within the Catalogue entity 36230.

(v) Catalogue Section Relationship

Each CatalogueSectionRelationship entity 36274 specifies a connectionbetween two CatalogueSection entities 36272 within a CatalogueSchemaentity 36266. In one implementation, each CatalogueSectionRelationshipentity 36274 corresponds to a parent-child connection between twoCatalogueSection entities 36272, providing a hierarchical structure tothe Catalogue entity 36230. The CatalogueSectionRelationship entity36274 includes an @actionCode, a SourceCatalogueSectionID, and aTargetCatalogueSectionID. The @actionCode is of type GDT: ActionCode andspecifies the operation to be performed on the correspondingCatalogueSectionRelationship entity 36274. The SourceCatalogueSectionIDis of type GDT: CatalogueSectionID and identifies a sourceCatalogueSection entity 36272. The TargetCatalogueSectionID is of typeGDT: CatalogueSectionID and identifies a target CatalogueSection entity36272.

(iv) Catalogue Content Package

The Content or CatalogueContent package 36228 includes a CatalogueItempackage 36290 and a CatalogueView package 36292, and a CatalogueContententity 36294. There is a 1:c relationship 36296 between the Catalogueentity 36230 and the CatalogueContent entity 36294. The CatalogueContententity 36294 specifies the list of business objects included in thecatalogue reflected by the Catalogue entity 36230, together with theirrelationships and descriptions according to the catalogue's schemasreflected by the CatalogueSchema entity 36266, and the views (e.g.,CatalogueView entities 36298) that are used to restrict the catalogue'sinformation content for certain purposes. The CatalogueContent entity36294 also specifies the items (e.g., CatalogueItem entities 36298)included in the Catalogue entity 36230 and each item's classification orassignment to Catalogue sections reflected by the one or moreCatalogueSection entities 36272. The CatalogueContent entity 36294includes a CatalogueItemListCompleteTransmissionIndicator, aCatalogueItemRelationshipListCompleteTransmissionIndicator, aCatalogueViewListCompleteTransmissionIndicator, and a CatalogueSchemaID.The CatalogueItemListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list of items(e.g., CatalogueItem entities 36298) has been transmitted completely.The CatalogueItemRelationshipListCompleteTransmissionIndicator is oftype GDT: CompleteTransmissionIndicator and specifies whether the listof ItemRelationships (e.g., CatalogueItemRelationship entities 36200A)has been transmitted completely. TheCatalogueViewListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list of Views(e.g., CatalogueView entities 36218A) has been transmitted completely.The CatalogueSchemaID identifies a catalogue schema (e.g., aCatalogueSchema entity 36272) to which the respective CatalogueContententity 36294 is assigned. In one implementation, The CatalogueSchemaIDof a first of the CatalogueContent entities 36294 functions as a defaultvalue for remaining CatalogueContent entities 36294 without a specifiedCatalogueSchemaID.

(a) Catalogue Content Catalogue Item Package

The CatalogueItem package 36290 groups the information pertaining tocatalogue items. The CatalogueItem package 36290 includes aCatalogueItem entity 36298 and a CatalogueItemRelationship entity36200A. There is a 1:cn relationship 36202A between the CatalogueContententity 36294 and the CatalogueItem entity 36298. There is a 1:cnrelationship 36204A between the CatalogueContent entity 36294 and theCatalogueItemRelationship entity 36200A.

(i) Catalogue Item

The CatalogueItem entity 36298 specifies information about an objectincluded and to be classified within the Catalogue entity 36230 inaccordance with the Catalogue entity's 36230 schema as reflected by theCatalogueSchema entity 36266. The CatalogueItem entity 36298 includes aCatalogueItemDescription entity 36206A that describes the item reflectedby the CatalogueItem entity 36298. The CatalogueItem entity 36298 mayalso include a CatalogueItemPropertyValuation entity 36208A and aCatalogueItemClassification entity 36210A. The CatalogueItem entity36298 may further include an @actionCode and an ID. The @actionCode isof type GDT: ActionCode and specifies the operation to be performed onthe item. The ID is of type GDT: CatalogueItemID and identifies therespective CatalogueItem entity 36298.

(ii) Catalogue Item Description

The CatalogueItemDescription entity 36206A is of type GDT: Descriptionand provides a description for an item in a specified language. There isa 1:cn relationship 36212A between the CatalogueItem entity 36298 andthe CatalogueItemDescription entity 36206A.

(iii) Catalogue Item Classification

The CatalogueItemClassification entity 36210A assigns the CatalogueItementity 36298 to a respective CatalogueSection entity 36272 within one ofthe CatalogueSchema entities 36266 associated with the Catalogue entity36230. The CatalogueItemClassification entity 36210A includes a SchemaIDand a SectionID. The SchemaID is of type GDT: CatalogueSchemaID andidentifies the schema (e.g., one of the CatalogueSchema entities 36266)that the CatalogueItem entity 36298 references. The SectionID is of typeGDT: CatalogueSectionID and identifies the section (e.g., one of theCatalogueSection entities 36272) that the CatalogueItem entity 36298references. There is a 1:cn relationship 36214A between theCatalogueItem entity 36298 and the CatalogueItemClassification entity36206A.

(iv) Catalogue Item Property Valuation

The CatalogueItemPropertyValuation entity 36208A is of type GDT:PropertyValuation and specifies the value of a property that may beattributed to the object the CatalogueItem entity 36298 represents inaccordance with one of the CatalogueSchema entities 36266. TheCatalogueItemPropertyValuation entity 36208A includes aPropertyReference and a PropertyValue. The PropertyReference is of typeGDT: PropertyReference and is the reference to the property to bevaluated for the CatalogueItem entity 36298. The PropertyValue is oftype GDT: PropertyValue and is the value of the property reflected bythe PropertyReference. There is a 1:cn relationship 36216A between theCatalogueItem entity 36298 and the CatalogueItemPropertyValuation entity36208A.

(v) Catalogue Item Relationship

The CatalogueItemRelationship entity 36200A specifies a relationshipwith certain semantics between any two CatalogueItem entities 36298. TheCatalogueItemRelationship entity 36200A includes an @actionCode, aSourceCatalogueItemID, a TargetCatalogueItemID, and a TypeCode. The@actionCode is of type GDT: ActionCode and specifies the operation to beperformed on the relationship between the two CatalogueItem entities36298. The SourceCatalogueItemID is of type GDT: CatalogueItemID andidentifies the source CatalogueItem entity 36298. TheTargetCatalogueItemID is of type GDT: CatalogueItemID and identifies thetarget CatalogueItem entity 36298. The TypeCode is of type GDT:ObjectStructureRelationshipTypeCode and specifies the semantics of therelationship existing between the source CatalogueItem entity 36298 andthe target CatalogueItem entity 36298.

(b) Catalogue Content Catalogue View Package

The CatalogueView package 36292 groups the information pertaining toCatalogue views. The CatalogueView package 36292 includes aCatalogueView entity 36218A. There is a 1:cn relationship 36220A betweenthe CatalogueContent entity 36294 and the CatalogueView entity 36218A.

(i) Catalogue View

The CatalogueView entity 36218A defines a subset of a Catalogue byspecifying schemas, sections, Catalogue items and item relationshiptypes to be included and properties to be excluded from a catalogueview. The CatalogueView entity 36218A may include a CatalogueViewSchemaentity 36222A, a CatalogueViewItem entity 36224A and aCatalogueViewItemRelationshipType entity 36226A. In addition, theCatalogueView entity 36218A may include a CatalogueViewExcludedPropertyentity 36228A, which specify properties not to be included in the view.The CatalogueView entity 36218A includes an @actionCode, an ID, a Name,an ItemListCompleteTransmissionIndicator, anItemRelationshipTypeListCompleteTransmissionIndicator, and anExcludedPropertyListCompleteTransmissionIndicator. The @actionCode is oftype GDT: ActionCode and specifies the operation to be performed on theCatalogueView entity 36218A. The ID is of type GDT: CatalogueViewID andidentifies a view ID. The Name is of type GDT: GDT Name and provides aname for the view in various languages. TheItemListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the item list hasbeen transmitted completely. TheItemRelationshipTypeListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list of itemrelationships has been transmitted completely. TheExcludedPropertyListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator and specifies whether the list of excludedproperties has been transmitted completely. There is a 1:cn relationship36230A between the CatalogueView entity 36218A and theCatalogueViewSchema entity 36222A. There is a 1:cn relationship 36232Abetween the CatalogueView entity 36218A and the CatalogueViewItem entity36224A. There is a 1:cn relationship 36234A between the CatalogueViewentity 36218A and the CatalogueViewItemRelationshipType entity 36226A.There is a 1:cn relationship 36236A between the CatalogueView entity36218A and the CatalogueViewItemRelationshipType entity 36226A.

(ii) Catalogue View Schema

The CatalogueViewSchema entity 36222A specifies a schema and a list ofsections belonging to the schema that are to be included in aCatalogueView entity 36218A. The CatalogueViewSchema entity 36222A issubdivided into one or more CatalogueViewSchemaSection entities 36238Athat specify Sections included in the CatalogueView entity 36218A. TheCatalogueViewSchema entity 36222A includes an ID and aSectionListCompleteTransmissionIndicator. The ID is of type GDT:CatalogueSchemaID and identifies the respective CatalogueViewSchemaentity 36222A. The SectionListCompleteTransmissionIndicator is of typeGDT: CompleteTransmissionIndicator and specifies whether the list ofsections (e.g., one or more CatalogueViewSchemaSections 36222A) has beentransmitted completely.

(iii) Catalogue View Schema Section

The CatalogueViewSchemaSection entity 36222 specifies a section of thereferenced catalogue schema (e.g., CatalogueViewSchema entity 36222A) tobe included in the catalogue view. The CatalogueViewSchemaSection entity36222 includes an @actionCode is of type GDT: ActionCode and an ID is oftype GDT: CatalogueSectionID. The @actionCode specifies the operation tobe performed on the CatalogueViewSchemaSection entity 36222 identifiedby the ID.

(iv) Catalogue View Item

The CatalogueViewItem entity 36224A specifies a CatalogueItem entity36298 to be included in the catalogue view. The CatalogueViewItem entity36224A includes an @acfionCode of type GDT: ActionCode and an ID of typeGDT: CatalogueItemID. The @actionCode specifies the operation to beperformed on the CatalogueViewItem entity 36224A identified by the ID.

(v) Catalogue View Item Relationship Type

The CatalogueViewItemRelationshipType entity 36226A specifies acatalogue item relationship type. In one implementation, the catalogueitem relationships of the CatalogueViewItemRelationshipType entity36226A are included in the catalogue view.CatalogueViewItemRelationshipType entity 36226A includes an @actionCodeof type GDT: ActionCode and a Code of type GDT:ObjectStructureRelationshipType Code. The @actionCode specifies theoperation to be performed on the item relationship type identified bythe Code.

(vi) Catalogue View Excluded Property

The CatalogueViewExcludedProperty 36228A specifies a property that isnot included in the catalogue view. For example, aCatalogueViewExcludedProperty “Price” is defined in the CatalogueContententity 36294 means that users that have access to the content of therespective catalogue reflected by the Catalog entity 36230 may not seethe price of catalogue items (e.g., CatalogueItem entities 36298) of thecatalogue. The CatalogueViewExcludedProperty 36228A includes an@actionCode of type GDT: ActionCode and a PropertyReference of type GDT:PropertyReference. The @actionCode specifies the operation to beperformed on an excluded property identified by the PropertyReference.

(d) Message Data Type—Element Structure

FIGS. 363A-AA depict the element structure for aCataloguePublicationRequest message 35910. The element structure issimilar to the data model, but provides additional information regardingthe details of the interface. The element structure identifies thedifferent packages 36300 in the interface, and represents the entitiesat various levels within the interface. As depicted in FIG. 363, theinterface for CataloguePublicationMessage includes six levels 36302,36304, 36306, 36308, 36310, 36312, and 36314. The outermost package36300 of this interface is a CataloguePublicationMessage package 36320,which includes a CataloguePublicationMessage entity 36322 at the firstlevel 36302, a MessageHeader package 36328, a TransmissionInformationpackage 36362, and a Catalogue package 36304A. TheCataloguePublicationMessage entity 36322 is of a type MDT 36324“CataloguePublicationMessage” 36326.

The MessageHeader package 36328 includes a MessageHeader entity 36330 atthe second level 36304. The MessageHeader entity 36330 is of a type GDT36334 BusinessDocumentMessageHeader 36336, and there is one 36332MessageHeader entity 36330 for each MessageHeader 36328.

The MessageHeader entity 36330 includes an ID 36338, CreationDateTime36346, and SenderParty 36354 at the third level 36306. The ID 36338 isof a type GDT 36342 “BusinessDocumentMessageID” 36344 and there is one36340 ID 36338 in a MessageHeader entity 36330. The CreationDateTime36346 is of a type GDT 36350 “DateTime” 36352 and there is one 36348CreationDateTime 36346 in a MessageHeader entity 36330. The SenderParty36354 is of a type GDT 36358 “BusinessDocumentMessageHeaderParty” 36360and there is zero or one 36356 SenderParty 36354 in a MessageHeaderentity 36330.

The TransmissionInformation package 36362 includes TransmissionHeaderentity 36364 at the second level 36304. The TransmissionHeader entity36364 is of a type “BusinessDocumentTransmissionHeader” 36370 and thereis zero or one 36366 TransmissionHeader entity 36364 in aTransmissionInformation package 36362.

The TransmissionInformationHeader 36364 includes an ID 36372, aPackageOrdinalNumberValue 36380, a PackageTotalNumberValue 36388, and aMinumumRequestedLogItemServerityCode 36396 at the third level 36306. TheID 36372 is of a type GDT 36376 “TransmissionID” 36378 and there is one36374 ID 36372 in a TransmissionHeader 36364. ThePackageOrdinalNumberValue 36380 is of a type GDT 36384“OrdinalNumberValue” and there is one 36382 PackageOrdinalNumberValue36380 in a TransmissionHeader 36364. The PackageTotalNumberValue 36386is of a type GDT 36392 “TotalNumberValue” 36394 and there is zero or one36390 PackageTotalNumberValue 36388 in a TransmissionHeader 36364. TheMinimumRequestedLogItemServerityCode 36396 is of a type GDT 36300A“LogItemSeverityCode” 36302A and there is zero or one 36398MinimumRequestedLogItemServerityCode in a TransmissionHeader 36364.

The Catalogue package 36304A includes a Catalogue entity 36306A at thesecond level 36304 and a GlobalInformation package 36318B, Model package36390D, and Content package 36302K. The Catalogue entity 36306A is of atype “TransmissionCatalogue” 36312A and there is one 36308A in aCatalogue package 36304A.

The Catalogue entity 36306A includes an @actionCode 36314A, an@completeTransmissionIndicator 36322A, an@providerPropertyValuationListCompleteTransmissionIndicator 36330A, an@languageCode 36338A, an @currencycode 36346A, an @unitCode 36354A, anID 36362A, a version ID 36370A, a Name 36378A, a TypeCode 36386A, and aValidityPeriod 36394A at the third level 36306. The @actionCode 36314Ais of a type GDT 36318A “ActionCode” 36320A, and there is zero or one36316A@actionCode 36314A in a Catalogue entity 36306A. The@completeTransmissionIndicator 36322A is of a type GDT 36326A“CompleteTransmissionIndicator” 36328A, and there is zero or one 36324A@completeTransmissionIndicator 36322A in a Catalogue entity 36306A. The@providerPropertyValuationListCompleteTransmissionIndicator 36330A is ofa type GDT 36334A “CompleteTransmissionIndicator” 36336A, and there iszero or one 36332A@providerPropertyValuationListCompleteTransmissionIndicator 36330A in aCatalogue entity 36306A. The @languageCode 36338A is of a type GDT36342A “LanguageCode” 36344A, and there is zero or one 36340A@languageCode 36338A in a Catalogue entity 36306A. The @currencyCode36346A is of a type GDT 36350A “CurrencyCode” 36352A, and there is zeroor one 36348A @currencyCode 36346A in a Catalogue entity 36306A. The@unitCode 36354A is of a type GDT 36358A “MeasureUnitCode” 36360A, andthere is zero or one 36356A@unitCode 36354A in a Catalogue entity36306A. The ID 36362A is of a type GDT 36366A “CatalogueID” 36368A, andthere is one 36364A ID 36362A in a Catalogue entity 36306A. TheVersionID 36370A is of a type GDT 36374A “VersionID” 36376A, and thereis zero or one 36372A VersionID 36370A in a Catalogue entity 36306A. TheName 36378A is of a type GDT 36382A “Name” 36384A, and there is anynumber of 36380A Name 36378A in a Catalogue entity 36306A. The TypeCode36386A is of a type GDT 36390A “CatalogueTypeCode” 36392A, and there isone 36388A TypeCode 36386A in a Catalogue entity 36306A. TheValidityPeriod 36394A is of a type GDT 36398A “DateTimePeriod” 36300B,and there is zero or one 36396A ValidityPeriod 36394A in a Catalogueentity 36306A.

The ValidityPeriod 36394A includes a StartDateTime 36302B and anEndDateTime 36310B at the fourth level 36308. The StartDateTime 36302Bis of a type GDT 36306B “DateTime” 36308B, and there is zero or one36304B StartDateTime 36302B in a ValidityPeriod 36394A. The EndDateTime36310B is of a type GDT 36314B “DateTime” 36316B, and there is zero orone 36312B EndDateTime 36310B in a ValidityPeriod 36394A.

The GlobalInformation package 36318B includes aProviderPropertyValuation 36320B at the third level 36306. TheProviderPropertyValuation 36320B is of a type GDT 36324B“PropertyValuation” 36326B, and there is any number of 36322BProviderPropertyValuation 36320B in a GlobalInformation 36318B.

The ProviderPropertyValuation 36320B includes an @actionCode 36328B, aPropertyReference 36336B, and a ValueGroup 36352B at the fourth level36308. The @actionCode 36328B is of a type GDT 36332B “ActionCode”36334B, and there is zero or one 36330B @actionCode 36328B in aProviderPropertyValuation 36320B. The PropertyReference 36336B is of atype GDT 36340B “PropertyReference” 36342B, and there is one 36338BPropertyReference 36336B in a ProviderPropertyValuation 36320B.

The PropertyReference 36336B includes an ID 36344 B at the fifth level36310. The ID 36344B is of a type GDT 36348B “PropertyID” 36350B, andthere is one 36346B ID 36344B in a PropertyReference 36336B.

The ValueGroup 36352B is of a type GDT 36356B “PropertyValuelterator”36358B, and there is any number 36354B of ValueGroup 36352B in aProviderPropertyValuation 36320B.

The ValueGroup 36352B includes an ID 36360B, a ParentID 36368B, anOrdinalNumberValue 36376B, and a PropertyValue 36384B of the fifth level36310. The ID 36360B is of a type CCT 36364B “Identifier” 36366B, andthere is zero or one 36362B ID 36360B in a ValueGroup 36352B. TheParentID 36368B is of a type CCT 36372B “Identifier” 36374B, and thereis zero or one 36370B ParentID 36368B in a ValueGroup 36352B. TheOrdinalNumberValue 36376B is of a type GDT 36380B “OrdinalNumberValue”36382B, and there is zero or one 36378B OrdinalNumberValue 36376B in aValueGroup 36352B. The PropertyValue 36384B is of a type GDT 36388B“PropertyValue” 36390B, and there is any number of 36386B PropertyValue36384B in a ValueGroup 36352B.

The PropertyValue 36384B includes an AmountSpecification 36392B, aQuantity Specification 36320C, a DecimalSpecification 36348C, aFloatSpecification 36376C, an IntegerSpecification 36304D, aDateTimeSpecification 36332D, a NameSpecification 36360D, and anIndicatorSpecification 36378D at the sixth level 36312. There is zero orone 36394B AmountSpecification 36392B in a PropertyValue 36384B.

The AmountSpecification 36392B includes an amount 36396B, a LowerAmount36304C, and an UpperAmount 36312C of the seventh level 36314. The Amount36396B is of a type GDT 36300C “Amount” 36302C, and there is zero or one36398B Amount 36396B in a AmountSpecification 36392B. The LowerAmount36304C is of a type GDT 36308C “Amount” 36310C, and there is zero or one36306C LowerAmount 36304C in a AmountSpecification 36392B. TheUpperAmount 36312C is of a type GDT 36316C “Amount” 36318C, and there iszero or one 36314C UpperAmount 36312C in a AmountSpecification 36392B.

There is zero or one 36322C QuantitySpecificafion 36320C in aPropertyValue 36384B. The QuantitySpecification 36320C includes aQuantity 36324C, a LowerQuantity 36332C, and an UpperQuantity 36340C atthe seventh level 36314. The Quantity 36324C is of a type GDT 36328C“Quantity” 36330C, and there is zero or one 36326C Quantity 36324C in aQuantitySpecification 36320C. The LowerQuantity 36332C is of a type GDT36336C “Quantity” 36338C, and there is zero or one 36334C LowerQuantity36332C in a QuantitySpecification 36320C. The UpperQuantity 36340C is ofa type GDT 36344C “Quantity” 36346C, and there is zero or one 36342CUpperQuantity 36340C in a QuantitySpecification 36320C.

There is zero or one 36350C DecimalSpecification 36348C in aPropertyValue 36384B. The DecimalSpecification 36348C includes aDecimalValue 36352C, a LowerDecimalValue 36360C, and anUpperDecimalValue 36368C at the seventh level 36314. The DecimalValue36352C is of a type GDT 36356C “DecimalValue” 36358C, and there is zeroor one 36354C DecimalValue 36352C in a DecimalSpecification 36348C. TheLowerDecimalValue 36360C is of a type GDT 36364C “DecimalValue” 36366C,and there is zero or one 36362C LowerDecimalValue 36360C in aDecimalSpecification 36348C. The UpperDecimalValue 36368C is of a typeGDT 36372C “DecimalValue” 36374C, and there is zero or one 36370CUpperDecimalValue 36368C in a DecimalSpecification 36348C.

There is zero or one 36378C FloatSpecification 36376C in a PropertyValue36384B. the FloatSpecification 36376 includes a FloatValue 36380C, aLowerFloatValue 36388C, and an UpperFloatValue 36396C at the seventhlevel 36314. The FloatValue 36380C is of a type GDT 36384C “FloatValue”36386C, and there is zero or one 36382 CFloatValue 36380C in aFloatSpecification 36376C. The LowerFloatValue 36388C is of a type GDT36392C “FloatValue” 36394C, and there is zero or one 36390CLowerFloatValue 36388C in a FloatSpecification 36376C. TheUpperFloatValue 36396C is of a type GDT 36300D “FloatValue” 36302D, andthere is zero or one 36398C UpperFloatValue 36396C in aFloatSpecification 36376C.

There is zero or one 36306D IntegerSpecification 36304D in aPropertyValue 36384B. The IntegerSpecificaton 36304D includes anIntegerValue 36308D, a LowerIntegerValue 36316D, and anUpperlntegerValue 36324D at the seventh level 36314. The IntegerValue36308D is of a type GDT 36312D “IntegerValue” 36314D, and there is zeroor one 36310 DIntegerValue 36308D in a IntegerSpecification 36304D. TheLowerIntegerValue 36316D is of a type GDT 36320D “IntegerValue” 36322D,and there is zero or one 36318D LowerlntegerValue 36316D in aIntegerSpecification 36304D. The UpperlntegerValue 36324D is of a typeGDT 36328D “IntegerValue” 36330D, and there is zero or one 36326DUpperlntegerValue 36324D in a IntegerSpecification 36304D.

There is zero or one 36334D DateTimeSpecification 36332D in aPropertyValue 36384B. The DateTimeSpecification 36332D includes aDateTime 36336D, a StartDateTime 36344D, and an EndDateTime 36352D atthe seventh level 36314. The DateTime 36336D is of a type GDT 36340D“DateTime” 36342D, and there is zero or one 36338D DateTime 36336D in aDateTimeSpecification 36332D. The StartDateTime 36344D is of a type GDT36348D “DateTime” 36350D, and there is zero or one 36346D StartDateTime36344D in a DateTimeSpecification 36332D. The EndDateTime 36352D is of atype GDT 36356D “DateTime” 36358D, and there is zero or one 36354DEndDateTime 36352D in a DateTimeSpecification 36332D.

There is zero or one 36362D NameSpecification 36360D in a PropertyValue36384B. The NameSpecification 36360D includes a Name 36364D at theseventh level 36314. The Name 36364D is of a type GDT 36368D “Name”36370D, and there is zero or one 36366D Name 36364D in aNameSpecification 36360D.

There is zero or one 36380D IndicatorSpecification 36378D in aPropertyValue 36384B. The The IndicatorSpecification 36378D includes anIndicator 36382D. The Indicator 36382D is of a type GDT 36386D“Indicator” 36388D, and there is zero or one 36384D Indicator 36382D ina IndicatorSpecification 36378D.

The Model package 36390D includes a Model entity 36392D at the thirdlevel 36306 and a PropertyDefinitionClass 36332E, a PropertyDataTypepackage 36386E, a Propery package 36380F, a CatalogueItemPropertypackage 36394G, a CatalogueSectionType package 36328H, and aCatalogueSchema package 36394H. The Model entity 36392D is of a type“Catalogue Model” 36398D, and there is zero or one 36394D Model entity36392D in a Model package 36390D.

The Model entity 36392D includes an@propertyDataTypeListCompleteTransmissionIndicator 36300E, an@propertyListCompleteTransmissionIndicator 36308E, an@catalogueSectionTypeListCompleteTransmissionIndicator 36316E, and an@catalogueSchemaListCompleteTransmissionIndicator 36324E at the fourthlevel 36308. The @propertyDataTypeListCompleteTransmissionIndicator36300E is of a type GDT 36304E “CompleteTransmissionIndicator” 36306E,and there is zero or one 36302E@propertyDataTypeListCompleteTransmissionIndicator 36300E in a Modelentity 36392D. The @propertyListCompleteTransmissionIndicator 36308E isof a type GDT 36312E “CompleteTransmissionIndicator” 36314E, and thereis zero or one 36310E@propertyListCompleteTransmissionIndicator 36308Ein a Model entity 36392D. The@catalogueSectionTypeListCompleteTransmissionIndicator 36316E is of atype GDT 36320E “CompleteTransmissionIndicator” 36322E, and there iszero or one 36318E@catalogueSectionTypeListCompleteTransmissionIndicator 36316E in a Modelentity 36392D. The @catalogueSchemaListCompleteTransmissionindicator36324E is of a type GDT 36328E “CompleteTransmissionIndicator” 36330E,and there is zero or one 36326E@catalogueSchemaListCompleteTransmissionIndicator 36324E in a Modelentity 36392D.

The PropertyDefinitionClass package 36332E includes aPropertyDefinitionClass entity 36334E at the fourth level 36308. ThePropertyDefinitionClass entity 36334E is of a type GDT 36338E“PropertyDefinitionClass” 36340E, and there is any number of 36336EPropertyDefinitionClass entity 36334E in a PropertyDefinitionClasspackage 36332E.

The PropertyDefinitionClass 36334E includes an ID 36342E, aPreferredName 36350E, and a DefinedProperty 36358E at the fifth level36310. The ID 36342E is of a type GDT 36346E “PropertyDefinitionClassID”36348E, and there is one 36344E ID 36342E in a PropertyDefinitionClass36334E. The PreferredName 36350E is of a type GDT 36354E “Name” 36356E,and there is one 36352E PreferredName 36350E in aPropertyDefinitionClass 36334E. There is any number of 36360EDefinedProperty 36358E in a PropertyDefinitionClass 36334E.

The DefinedProperty 36358E includes a Reference 36362E and anOrdinalNumberValue 36378E of the sixth level 36312. The Reference 36362Eis of a type GDT 36366E “PropertyReference” 36368E, and there is one36364E Reference 36362E in a DefinedProperty 36358E.

The Reference 36362E includes an ID 36370E at the seventh level. The ID36370E is of a type GDT 36374E “PropertyID” 36376E, and there is one36372E ID 36370E in a Reference 36362E.

The OrdinalNumberValue 36378E is of a type GDT 36382E“OrdinalNumberValue” 36384E, and there is zero or one 36380EOrdinalNumberValue 36378E in a DefinedProperty 36358E.

The PropertyDataType entity 36388E is of a type GDT 36392E“PropertyDataType” 36394E, and there is any number of 36390EPropertyDataType entity 36388E in a PropertyDataType package 36386E.

The PropertyDataType package 36386E includes a PropertyDataType entity36388E at the fifth level 36310. The PropertyDataType entity 36388E isof a type GDT 36392E “PropertyReference” 36394E, and there is any number36390E of PropertyDataType entity 36388E in a PropertyDataType package36386E.

The PropertyDataType 36388E includes an @actionCode 36396E, an ID36304F, a PreferredName 36312F, a FormatCode 36328F, aMaximumTotalDigitNumberValue 36336F, a FractionalDigitNumberValue36344F, a PropertyDefinitionClassReference 36352F, and anAlloedPropertyValueElement 36368F at the fifth level 36310. The@actionCode 36396E is of a type GDT 36300F “ActionCode” 36302F, andthere is zero or one 36398E @actionCode 36396E in a PropertyDataType36388E. The ID 36304F is of a type GDT 36308F “PropertyDataTypeID”36310F, and there is zero or one 36306F ID 36304F in a PropertyDataType36388E. The PreferredName 36312F is of a type GDT 36316F “Name” 36318F,and there is one or more 36314F PreferredName 36312F in aPropertyDataType 36388E.

The PreferredName 36312F includes an @languageCode 36320F at the sixthlevel 36312. The @IanguageCode 36320F is of a type GDT 36324F“LanguageCode” 36326F, and there is zero or one 36322F@languageCode36320F in a PreferredName 36312F.

The FormatCode 36328F is of a type GDT 36332F“PropertyDataTypeFormatCode” 36334F, and there is one 36330F FormatCode36328F in a PropertyDataType 36388E. The MaximumTotalDigitNumberValue36336F is of a type GDT 36340F “DigitNumberValue” 36342F, and there iszero or one 36338F MaximumTotalDigitNumberValue 36336F in aPropertyDataType 36388E. The FractionalDigitNumberValue 36344F is of atype GDT 36348F “DigitNumberValue” 36350F, and there is zero or one36346F FractionalDigitNumberValue 36344F in a PropertyDataType 36388E.The PropertyDefinitionClassReference 36352F is of a type GDT 36356F“PropertyDefinitionClassReference” 36358F, and there is zero or one36354F PropertyDefinitionClassReference 36352F in a PropertyDataType36388E.

The PropertyDefinitionClassReference 36352F includes an ID 36360F at thesixth level 36312. The ID 36360F is of a type GDT 36364F“PropertyDefinitionClassID” 36366F, and there is one 36362F ID 36360F ina PropertyDefinitionClassReference 36352F.

There is any number of 36370F AllowedPropertyValueElement 36368F in aPropertyDataType 36388E. The AllowedPropertyValueElement 36368F includesa PropertyValue 36372F at the sixth level 36312. The PropertyValue36372F is of a type GDT 36376F “PropertyValue” 36378F, and there is one36374F PropertyValue 36372F in an AllowedPropertyValueElement 36368F.

The Property package 36380F includes a Property entity 36382F at thefourth level 36308. The Property entity 36382F is of a type GDT 36386F“Property” 36388F, and there is any number of 36384F Property entity36382F in a Property package 36380F.

The Property entity 36382F includes an @actionCode 36390F, an ID 36398F,a DefinitionClassReference 36306G, a PreferredName 36322G, aPropertyDataTypeReference 36330G, an AspectID 36346G, aTargetInterfaceElementID 36354G, a MultipleValueIndicator 36362G, aTextSearchableIndicator 36370G, a ParametricSearchAbleIndicator 36378G,and a ValuationRequiredIndicator 36386G. The @actionCode 36390F is of atype GDT 36394F “ActionCode” 36396F, and there is zero or one 36392F@actionCode 36390F in a Property entity 36382F. The ID 36398F is of atype GDT 36302G “PropertyID” 36304G, and there is one 36300G ID 36398Fin a Property entity 36382F. The DefinitionClassReference 36306G is of atype GDT 36310G “PropertyDefinitionClassReference” 36312G, and there iszero or one 36308G DefinitionClassReference 36306G in a Property entity36382F.

The DefinitionClassReference 36306G includes an ID 36314G at the sixthlevel 36312. The ID 36314G is of a type GDT 36318G“PropertyDefinitionClassID” 36320G, and there is one 36316G ID 36314G ina DefinitionClassReference 36306G.

The PreferredName 36322G is of a type GDT 36326G “Name” 36328G, andthere is at least one 36324G PreferredName 36322G in a Property entity36382F. The PropertyDataTypeReference 36330G is of a type GDT 36334G“PropertyDataTypeReference” 36336G, and there is one 36332GPropertyDataTypeReference 36330G in a Property entity 36382F.

The PropertyDataTypeReference 36330G includes an ID 36338G at the sixthlevel 36312. The ID 36338G is of a type GDT 36342G “PropertyDataTypeID”36344G, and there is one 36340G ID 36338G in a PropertyDataTypeReference36330G. The AspectID 36346G is of a type GDT 36350G “AspectID” 36352G,and there is any number of 36348G AspectID 36346 G in a Property entity36382F. The TargetInterfaceElementID 36354G is of a type GDT 36358G“InterfaceElementID” 36360G, and there is any number of 36356GTargetInterfaceElementID 36354G in a Property entity 36382F. TheMultipleValueIndicator 36362G is of a type GDT 36366G“PropertyMultipleValueIndicator” 36368G, and there is zero or one 36364GMultipleValueIndicator 36362G in a Property entity 36382F. TheTextSearchableIndicator 36370G is of a type GDT 36374G“TextSearchableIndicator” 36376G, and there is zero or one 36372GTextSearchableIndicator 36370G in a Property entity 36382F. TheParametricSearchableIndicator 36378G is of a type GDT 36382G“PropertyParametricSearchableIndicator” 36384G, and there is zero or one36380G ParametricSearchableIndicator 36378G in a Property entity 36382F.The ValuationRequiredIndicator 36386G is of a type GDT 36390G“PropertyValuationRequiredIndicator” 36392G, and there is zero or one36388G ValuationRequiredIndicator 36386G in a Property entity 36382F.

The CatalogueItemProperty package 36394G includes aCatalogueItemProperty entity 96G. The CatalogueItemProperty entity36396G is of a type “CatalogueItemProperty” 36302H, and there is anynumber of 36398G CatalogueItemProperty entity 36396G in aCatalogueItemProperty package 36394G.

The CatalogueItemProperty entity 36396G includes a ProptertyReference36304H and an OrdinalNumberValue 36320H at the fifth level 36310. ThePropertyReference 36304H is of a type GDT 36308H “PropertyReference”36310H, and there is one 36306H PropertyReference 36304H in aCatalogueItemProperty entity 36396G.

The PropertyReference 36304H includes an ID 36312H at the sixth level36312. The ID 36312H is of a type GDT 36316H “PropertyID” 36318H, andthere is one 36314H ID 36312H in a PropertyReference 36304H.

The OrdinalNumberValue 36320H is of a type GDT 36324H“OrdinalNumberValue” 36326H, and there is one 36322H OrdinalNumberValue36320H in a CatalogueItemProperty entity 36396G.

The CatalogueSectionType package 36328H includes a CatalogueSectionTypeentity 36330H at the forth level 36308. The CatalogueSectionType entity36330H is of a type “Catalogue Section Type” 36336H, and there is anynumber of 36332H CatalogueSectionType entities 36330H in aCatalogueSectionType package 36328H.

The CatalogueSectionType entity 36330H includes an @actionCode 36338H,an ID 36346H, a Name 36354H, and a SectionProperty 36362H at the fifthlevel 36310. The @actionCode 36338H is of a type GDT 36342H “ActionCode”36344H, and there is zero or one 36340H@actionCode 36338H in aCatalogueSectionType 36330H. The ID 36346H is of a type GDT 36350H“CatalogueSectionTypeID” 36352H, and there is one 36348H ID 36346H in aCatalogueSectionType 36330H. The Name 36354H is of a type GDT 36358H“Name” 36360H, and there is any number of 36356H Name 36354H in aCatalogueSectionType 36330H. The SectionProperty 36362H is of a type“CatalogueSectionTypeSectionProperty” 36368H, and there is any number of36364H SectionProperty 36362H in a CatalogueSectionType 36330H.

The SectionProperty 36362H includes a PropertyReference 36370H and anOrdinalNumberValue 36386H at the sixth level 36312. ThePropertyReference 36370H is of a type GDT 36374H “PropertyReference”36376H, and there is one 36372H PropertyReference 36370H in aSectionProperty 36362H.

The PropertyReference 36370H includes an ID 36378H at the seventh level36314. The ID 36378H is of a type GDT 36382H “PropertyID” 36384H, andthere is one 36380H ID 36378H in a PropertyReference 36370H.

The OrdinalNumberValue 36386H is of a type GDT 36390H“OrdinalNumberValue” 36392H, and there is one 36388H OrdinalNumberValue36386H in a SectionProperty 36362H.

The CatalogueSchemea package 36394H includes a CatalogueSchema entity36396H at the fourth level 36308. The CatalogueSchema entity 36396H isof a type “Catalogue Schema” 36302I, and there is any number of 36398HCatalogueSchema entity 36396H in a CatalogueSchema package 36394H.

The CatalogueSchema entity 36396H includes an @actionCode 36304I, an@catalogueSectionListCompleteTransmissionIndicator 36312I, an@catalogueSectionRelationshipListCompleteTransmissionIndicator 36320I,an ID 36328I, a TypeCode 36336I, a Name 36344I, a CatalogueItemProperty36352I, a CatalogueSection 36384I, and a CatalogueSectionRelationship36370J at the fifth level 36310. The @actionCode 36304I is of a type GDT36308I “ActionCode” 36310I, and there is zero or one 36306I@actionCode36304I in a CatalogueSchema 36396H. The@catalogueSectionListCompleteTransmissionIndicator 36312I is of a typeGDT 36316I “CompleteTransmissionIndicator” 36318I, and there is zero orone 36314I@catalogueSectionListCompleteTransmissionIndicator 36312I in aCatalogueSchema 36396H. The@catalogueSectionRelationshipListCompleteTransmissionIndicator 36320I isof a type GDT 36324I “CompleteTransmissionIndicator” 36326I, and thereis zero or one36322I@catalogueSectionRelationshipListCompleteTransmissionIndicator36320I in a CatalogueSchema 36396H. The ID 36328I is of a type GDT36332I “CatalogueSchemaID” 36334I, and there is one 36330I ID 36328I ina CatalogueSchema 36396H. The TypeCode 36336I is of a type GDT 36340I“CatalogueSchemaTypeCode” 36342I, and there is zero or one 36338ITypeCode 36336I in a CatalogueSchema 36396H. The Name 36344I is of atype GDT 36348I “Name” 36350I, and there is any number of 36346I Name36344I in a CatalogueSchema 36396H. The CatalogueItemProperty 36352I isof a type “CatalogueSchemaCatalogueItemProperty” 36358I, and there isany number of 36354I CatalogueItemProperty 36352I in a CatalogueSchema36396H.

The CatalogueItemProperty 36352I includes a PropertyReference 36360I andan QrdinalNumberValue 36376I at the sixth level 36312. ThePropertyReference 36360I is of a type GDT 36364I “PropertyReference”36366I, and there is one 36362I PropertyReference 36360I in aCatalogueItemProperty 36352I.

The PropertyRefernce 36360I includes an ID 36368I at the seventh level36314. The ID 36368I is of a type GDT 36372I “PropertyID” 36374I, andthere is one 36370I ID 36368I in a PropertyReference 36360I.

The OrdinalNumberValue 36376I is of a type GDT 36380I“OrdinalNumberValue” 36382I, and there is one 36378I OrdinalNumberValue36376I in a CatalogueItemProperty 36352I.

The CatalogueSection 36384I is of a type “CatalogueSection” 36390I, andthere is any number of 36386I CatalogueSection 36384I in aCatalogueSchema 36396H.

The CatalogueSection 36384I includes an @actionCode 36392I, an@propertyValuationListCompleteTransmissionIndicator 36300J, an ID36308J, a TypeID 36316J, a Name 36324J, a PropertyValuation 36332J, anda CatalogueItemProperty 36340J The @actionCode 36392I is of a type GDT36396I “ActionCode” 36398I, and there is zero or one 36394I@actionCode36392I in a CatalogueSection 36384I. The@propertyValuationListCompleteTransmissionIndicator 36300J is of a typeGDT 36304J “CompleteTransmissionIndicator” 36306J, and there is zero orone 36302J @propertyValuationListCompleteTransmissionIndicator 36300J ina CatalogueSection 36384I. The ID 36308J is of a type GDT 36312J“CatalogueSectionID” 36314J, and there is one 36310J ID 36308J in aCatalogueSection 36384I. The TypeID 36316J is of a type GDT 36320J“CatalogueSectionTypeID” 36322J, and there is zero or one 36318J TypeID36316J in a CatalogueSection 36384I. The Name 36324J is of a type GDT36328J “Name” 36330J, and there is any number of 36326J Name 36324J in aCatalogueSection 36384I. The PropertyValuation 36332J is of a type GDT36336J “PropertyValuation” 36338J, and there is any number of 36334JPropertyValuation 36332J in a CatalogueSection 36384I. TheCatalogueItemProperty 36340J is of a type“CatalogueSectionCatalogueItemProperty” 36346J, and there is any numberof 36342J CatalogueItemProperty 36340J in a CatalogueSection 36384I.

The CatalogueItemProperty 36340 J includes a PropertyReference 36348J,and an OrdinalNumberValue 36362J at the seventh level 36314. ThePropertyReference 36348J is of a type GDT 36352J “PropertyReference”36354J, and there is one 36350J PropertyReference 36348J in aCatalogueItemProperty 36340J. The OrdinalNumberValue 36362J is of a typeGDT 36366J “OrdinalNumberValue” 36368J, and there is one 36364JOrdinalNumberValue 36362J in a CatalogueItemProperty 36340J.

The CatalogueSectionRelationship 36370J is of a type“CatalogueSectionRelationship” 36376J, and there is any number of 36372JCatalogueSectionRelationship 36370J in a CatalogueSchema 36396H.

The CatalogueSectionRelationship 36370J includes an @actionCode 36378J,a SourceCatalogueSectionID 36386J, and a TargetCatalogueSectionID 36394Jat the sixth level 36312. The @actionCode 36378J is of a type GDT 36382J“ActionCode” 36384J, and there is zero or one 36380J @actionCode 36378Jin a CatalogueSectionRelationship 36370J. The SourceCatalogueSectionID36386J is of a type GDT 36390J “CatalogueSectionID” 36392J, and there isone 36388J SourceCatalogueSectionID 36386J in aCatalogueSectionRelationship 36370J. The TargetCatalogueSectionID 36394Jis of a type GDT 36398J “CatalogueSectionID” 36300K, and there is one36396J TargetCatalogueSectionID 36394J in a CatalogueSectionRelationship36370J.

The Content package 36302K includes a Content entity 36304K at the thirdlevel, a CatalogueItem package 36344K, and a CatalogueView package36358L. The Content entity 36304K is of a type “CatalogueContent”36310K, and there is zero or one 36306K Content entity 36304K in aContent package 36302K.

The Content entity 36304K includes an@catalogueItemListCompleteTransmissionIndicator 36312K, an@catalogueItemRelationshipListCompleteTransmissionIndicator 36320K, an@catalogueViewListCompleteTransmissionIndicator 36328K, and aCatalogueSchemaID 36336K at the fourth level 36308. The@catalogueItemListCompleteTransmissionIndicator 36312K is of a type GDT36316K “CompleteTransmissionIndicator” 36318K, and there is zero or one36314K @catalogueItemListCompleteTransmissionIndicator 36312K in aContent 36304K. The@catalogueItemRelationshipListCompleteTransmissionIndicator 36320K is ofa type GDT 36324K “CompleteTransmissionIndicator” 36326K, and there iszero or one36322K@catalogueItemRelationshipListCompleteTransmissionIndicator 36320Kin a Content 36304K. “The@catalogueViewListCompleteTransmissionIndicator 36328K is of a type GDT36332K “CompleteTransmissionIndicator” 36334K, and there is zero or one36330K @catalogueViewListCompleteTransmissionIndicator 36328K in aContent 36304K. The CatalogueSchemaID 36336K is of a type GDT 36340K“CatalogueSchemaID” 36342K, and there is zero or one 36338KCatalogueSchemaID 36336K in a Content 36304K.

The CatalogueItem package 36344K includes a CatalogueItem entity 36346Kand a CatalogueItemRelationship 36318L at the fourth level 36308. TheCatalogueItem entity 36346K is of a type “Catalogue Item” 36352K, andthere is any number of 36348K CatalogueItem entity 36346K in aCatalogueItem package 36344K.

The CatalogueItem entity 36346K includes an @actionCode 36354K, an@propertyValuationListCompleteTransmissionIndicator 36362K, an ID36370K, a Description 36378K, a Classification 36386K, and aPropertyValuation 36310L at the fifth level 36310. The @actionCode36354K is of a type GDT 36358K “ActionCode” 36360K, and there is zero orone 36356K @actionCode 36354K in a CatalogueItem 36346K. The@propertyValuationListCompleteTransmissionIndicator 36362K is of a typeGDT 36366K “CompleteTransmissionIndicator” 36368K, and there is zero orone 36364K @propertyValuationListCompleteTransmissionIndicator 36362K ina CatalogueItem 36346K. The ID 36370K is of a type GDT 36374K“CatalogueItemID” 36376K, and there is one 36372K ID 36370K in aCatalogueItem 36346K. The Description 36378K is of a type GDT 36382K“Description” 36384K, and there is any number of 36380K Description36378K in a CatalogueItem 36346K. The Classification 36386K is of a type“CatalogueItemClassification” 36392K, and there is any number of 36388KClassification 36386K in a CatalogueItem 36346K.

The Classification 36386K includes a CatalogueSchemaID 36394K and aCatalogueSectionID 36302L at the sixth level 36312. TheCatalogueSchemaID 36394K is of a type GDT 36398K “CatalogueSchemaID”36300L, and there is zero or one 36396K CatalogueSchemaID 36394K in aClassification 36386K. The CatalogueSectionID 36302L is of a type GDT36306L “CatalogueSectionID” 36308L, and there is one 36304LCatalogueSectionID 36302L in a Classification 36386K.

The PropertyValuation 36310L is of a type GDT 36314L “PropertyValuation”36316L, and there is any number of 36312L PropertyValuation 36310L in aCatalogueItem 36346K.

The CatalogueItemRelationship 36318L is of a type“CatalogueItemRelationship” 36324L, and there is any number of 36320LCatalogueItemRelationship 36318L in a Content 36304K.

The CatalogueItemRelationship 36318L includes an @actionCode 36326L, aSourceCatalogueItemID 36334L, a TargetCatalogueItemID 36342L, and aTypeCode 36350L at the fifth level 36310. The @actionCode 36326L is of atype GDT 36330L “ActionCode” 36332L, and there is zero or one 36328L@actionCode 36326L in a CatalogueItemRelationship 36318L. TheSourceCatalogueItemID 36334L is of a type GDT 36338L “CatalogueItemID”36340L, and there is one 36336L SourceCatalogueItemID 36334L in aCatalogueItemRelationship 36318L. The TargetCatalogueItemID 36342L is ofa type GDT 36346L “CatalogueItemID” 36348L, and there is one 36344LTargetCatalogueItemID 36342L in a CatalogueItemRelationship 36318L. TheTypeCode 36350L is of a type GDT 36354L“ObjectStructureRelationshipTypeCode” 36356L, and there is one 36352LTypeCode 36350L in a CatalogueItemRelationship 36318L.

The CatalogueView Package includes a CatalogueView entity 36360L at thefourth level 36308. The CatalogueView entity 36360L is of a type“CatalogueView” 36366L, and there is any number of 36362L CatalogueViewentity 36360L in a CatalogueView package 36358L.

The CataloguView entity includes an @actionCode 36368L, an@itemListCompleteTransmissionIndicator 36376L, an@itemRelationshipTypeListCompleteTransmissionIndicator 36384L, an@excludedPropertyListCompleteTransmissionIndicator 36392L, an ID 36300M,a Name 36308M, a Schema 36316M, an Item 36364M, an ItemRelationshipType36388M, and an ExcludedProperty 36312N at the fifth level 36310. The@actionCode 36368L is of a type GDT 36372L “ActionCode” 36374L, andthere is zero or one 36370L @actionCode 36368L in a CatalogueView36360L. The @itemListCompleteTransmissionIndicator 36376L is of a typeGDT 36380L “CompleteTransmissionIndicator” 36382L, and there is zero orone 36378L @itemListCompleteTransmissionIndicator 36376L in aCatalogueView 36360L. The@itemRelationshipTypeListCompleteTransmissionIndicator 36384L is of atype GDT 36388L “CompleteTransmissionIndicator” 36390L, and there iszero or one 36386L@itemRelationshipTypeListCompleteTransmissionIndicator 36384L in aCatalogueView 36360L. The@excludedPropertyListCompleteTransmissionIndicator 36392L is of a typeGDT 36396L “CompleteTransmissionIndicator” 36398L, and there is zero orone 36394L @excludedPropertyListCompleteTransmissionIndicator 36392L ina CatalogueView 36360L. The ID 36300M is of a type GDT 36304M“CatalogueViewID” 36306M, and there is one 36302M ID 36300M in aCatalogueView 36360L. The Name 36308M is of a type GDT 36312M “Name”36314M, and there is any number of 36310M Name 36308M in a CatalogueView36360L. The Schema 36316M is of a type “CatalogueViewSchema” 36322M, andthere is any number of 36318M Schema 36316M in a CatalogueView 36360L.

The Schema 36316M includes an @sectionListCompleteTransmissionIndicator36324M, a CatalogueSchemaID 36332M, and a Section 36340M at the sixthlevel 36312. The @sectionListCompleteTransmissionIndicator 36324M is ofa type GDT 36328M “CompleteTransmissionIndicator” 36330M, and there iszero or one 36326M @sectionListCompleteTransmissionIndicator 36324M in aSchema 36316M. The CatalogueSchemaID 36332M is of a type GDT 36336M“CatalogueSchemaID” 36338M, and there is one 36334M CatalogueSchemaID36332M in a Schema 36316M. The Section 36340M is of a type“CatalogueViewSchemaSection” 36346M, and there is any number of 36342MSection 36340M in a Schema 36316M.

The Section 36340M includes an @actionCode 36348 and aCatalogueSectionld 36356M at the seventh level 36314. The @actionCode36348M is of a type GDT 36352M “ActionCode” 36354M, and there is zero orone 36350M @actionCode 36348M in a Section 36340M. TheCatalogueSectionID 36356M is of a type GDT 36360M “CatalogueSectionID”36362M, and there is one 36358M CatalogueSectionID 36356M in a Section36340M.

The Item 36364M is of a type “CatalogueViewItem” 36370M, and there isany number of 36366M Item 36364M in a CatalogueView 36360L.

The Item 36364M includes an @actionCode 36372M and a CatalogueItemID36380M at the sixth level 36312. The @actionCode 36372M is of a type GDT36376M “ActionCode” 36378M, and there is zero or one 36374M @actionCode36372M in a Item 36364M. The CatalogueItemID 36380M is of a type GDT36384M “CatalogueItemID” 36386M, and there is one 36382M CatalogueItemID36380M in a Item 36364M.

The ItemRelationshipType 36388M is of a type“CatalogueViewItemRelationshipType” 36394M, and there is any number of36390M ItemRelationshipType 36388M in a CatalogueView 36360L.

The ItemRelationshipType 36388M includes an @actionCode 36396M and aCatalogueItemRelationshipTypeCode 36304N at the sixth level 36312. The@actionCode 36396M is of a type GDT 36300N “ActionCode” 36302N, andthere is zero or one 36398M @actionCode 36396M in a ItemRelationshipType36388M. The CatalogueItemRelationshipTypeCode 36304N is of a type GDT36308N “ObjectStructureRelationshipTypeCode” 36310N, and there is one36306N CatalogueItemRelationshipTypeCode 36304N in aItemRelationshipType 36388M.

The ExcludedProperty 36312N is of a type “CatalogueViewExcludedProperty”36318N, and there is any number of 36314N ExcludedProperty 36312N in aCatalogueView 36360L.

The ExcludedProperty 36312N includes an @actionCode 36320N and aPropertyReference 36328N at the sixth level 36312. The @actionCode36320N is of a type GDT 36324N “ActionCode” 36326N, and there is zero orone 36322N@actionCode 36320N in a ExcludedProperty 36312N. ThePropertyReference 36328N is of a type GDT 36332N “PropertyReference”36334N, and there is one 36330N PropertyReference 36328N in aExcludedProperty 36312N.

The PropertyReference 36328N includes an ID 36335N at the seventh level.The ID 36336N is of a type GDT 36340N “PropertyID” 36342N, and there isone 36338N ID 36336N in a PropertyReference 36328N.

(7) Message Data Type Catalogue Publication Transmission Package Message

The data model for the message data typeCataloguePublicationTransmissionPackage Message used to implement aCataloguePublicationTransmissionPackageNotification message 35912 isdepicted in FIG. 364. The message data typeCataloguePublicationTransmissionPackageMessage includes aCataloguePublicationTransmissionPackageMessage package 36402. TheCataloguePublicationTransmissionPackageMessage package 36402 includes aMessageHeader package 36404, a TransmissionInformation package 36406, aCataloguePublicationTransmission 36408, and aCataloguePublicationTransmissionPackageMessage object or entity 36410.

(a) Message Header Package

The MessageHeader package 36404 groups the business-related informationrelevant for sending a Business Document in a message. The MessageHeaderpackage 36404 includes a MessageHeader entity 36412 and a SenderPartyentity 36416. There is a 1:1 relationship 36414 between theMessageHeader entity 36412 and the CatalogueUpdateMessage entity 36410.There is a 1:c relationship 36418 between the MessageHeader entity 36412and the SenderParty entity 36416.

As discussed above, the MessageHeader entity 36412 groups thebusiness-related information from the sending application's point ofview for identifying the Business Document in a message, informationabout the sender, and potentially information about the receiver. TheMessageHeader entity 36412 is of type GDT BusinessDocumentMessageHeader.

The SenderParty entity 36416 is the party responsible for sending of abusiness document on a business-related application level. TheSenderParty entity 36416 is of type GDTBusinessDocumentMessageHeaderParty.

(b) Transmission Information Package

The TransmissionInformation package 36406 groups the informationpertaining to the transmission of the object or entity (e.g., theCataloguePublicationTransmissionPackageMessage entity 36410) included inthe message. The TransmissionInformation package 36406 includes aTransmissionLog entity 36420, which is a collection of events thatoccurred during processing of the transmitted business document object.The TransmissionLog is subdivided into one or more TransmissionLogItem(“Item”) entities 36424. Each TransmissionLogItem entity 36424 providesinformation about an event that occurred during processing of therespective transmitted business document object. EachTransmissionLogItem entity 36424 is of type GDT: LogItem. TheMinimumRequestedLogItemSeverityCode stated in messageCataloguePublicationRequest 35910 determines which LogItems are to bereturned by specifying their severity. There is a 1:c relationship 36422between the CataloguePublicationTransmissionPackageMessage entity 36410and the TransmissionLog entity 36420 and a 1:n relationship 36426between the TransmissionLog entity 36420 and each TransmissionLogItementity 36424. A TransmissionLog entity 36420 provides information aboutthe identification of a transmission.

(c) Catalogue Publication Transmission Package

The CataloguePublicationTransmission package 36408 groups informationpertaining to a Catalogue publication transmission. TheCataloguePublicationTransmission package 36408 includes aCataloguePublicationTransmission entity 36428. There is a 1:1relationship 36430 between the CatalogueUpdateMessage entity 36410 andthe CataloguePublicationTransmission entity 36428.

(i) CataloguePublicationTransmission Entity

The CataloguePublicationTransmission entity 36428 specifies a package ofa catalogue publication transmission (e.g., all or portion of aCataloguePublicationRequest message 35910) and information about thereception of this package and the validity of the package's content. TheCataloguePublicationTransmission entity 36428 includes an ID, aPackageOrdinalNumberValue, and a PackageCompletedIndicator. The ID is oftype GDT: TransmissionID and identifies the transmission to which thepackage belongs. The PackageOrdinalNumberValue is of type GDT:OrdinalNumberValue and identifies the package in the transmission. ThePackageCompletedIndicator is of type GDT:BusinessTransactionCompletedIndicator and specifies whether thetransmission package sent as part of a CataloguePublicationRequestmessage 35910 was successfully received and if the package includesvalid data or not.

(d) Message Data Type—Element Structure

FIGS. 365A-B depict the element structure for aCataloguePublicationTransmissionPackageNotification message 35912. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface.

The element structure is similar to the above described data model ofthe message data typeCataloguePublicationTransmissionPackageNotification message as reflectedin FIG. 364, but provides additional information regarding the detailsfor interfacing with or implementing aCataloguePublicationTransmissionPackageMessage, such as aCataloguePublicationTransmissionPackageNotification message 35912. Asshown in FIG. 365A, the element structure identifies the differentpackages 36500 that may be in a respectiveCataloguePublicationTransmissionPackageNotification message 35912. Theelement structure for theCataloguePublicationTransmissionPackageNotification message 35912includes three levels 36502, 36504 and 36506 each of which is associatedwith a respective package 36500. The element structure identifies theoccurrence or cardinality 36508 and data type information (i.e., type36510 and name 36512) for the elements at the respective levels 36502,36504, and 36506.

The outermost package of this interface is aCataloguePublicationTransmissionPackageMessage package 36516, whichincludes a CataloguePublicationTransmissionPackageMessage entity 36518at the first level 36502. TheCataloguePublicationTransmissionPackageMessage entity 36518 is ofgeneric data type (“GDT”) 36520CataloguePublicationTransmissionPackageMessage 36522.

The CataloguePublicationTransmissionPackageMessage package 36516includes a MessageHeader package 36524, a TransmissionInformationpackage 36526, and a CataloguePublicationTransmission package 36528. TheMessageHeader package 36524 includes a MessageHeader entity 36530, whichis of type GDT 36534 BusinessDocumentMessageHeader 36536. There is one36532 MessageHeader entity 36530 for eachCataloguePublicationTransmissionPackageMessage entity 36518.

The MessageHeader entity 36530 includes an ID 36540 and aCreationDateTime 36548. The ID 36540 is of type GDT 36544BusinessDocumentMessageID 36546. The CreationDateTime 36548 is of typeGDT 36552 DateTime 36554. There is one 36542 ID 36540 for eachMessageHeader entity 36530 and one 36550 CreationDateTime 36548 for eachMessageHeader entity 36530.

The MessageHeader entity 36530 also includes a SenderParty entity 36556.The SenderParty entity 36556 is of type GDT 36560BusinessDocumentMessageHeaderParty 36562. There is one or zero 36558SenderParty entity 36556 for each MessageHeader entity 36530.

The TransmissionInformation package 36526 includes a TransmissionLog36564. There is one or zero 36176 TransmissionLog 36564 for eachCataloguePublicationTransmissionPackageMessage entity 36518. TheTransmissionLog 36564 includes an Item 36568 of type GDT 36572 LogItem36574. There is one or more 36570 Items 36568 for each TransmissionLog36564.

The CataloguePublicationTransmission package 36528 includes aCataloguePublicationTransmission entity 36576. TheCataloguePublicationTransmission entity 36576 is of type GDT 36580CataloguePublicationTransmissionPackage 36582. There is one 36578CataloguePublicationTransmission entity 36576 for eachCataloguePublicationTransmissionPackageMessage entity 36518. TheCataloguePublicationTransmission entity 36576 includes an ID 36584, aPackageOrdinalNumberValue 36592, and a PackageCompletedIndicator 36500A.The ID 36584 is of type GDT 36588 TransmissionID 36590. ThePackageOrdinalNumberValue 36592 is of type GDT 36596 OrdinalNumberValue36598. The PackageCompletedIndicator 36500A is of type GDT 36504ABusinessTransactionCompletedIndicator 36506A. There is one 36586 ID36584 for each CataloguePublicationTransmission entity 36576. There isone 36594 PackageOrdinalNumberValue 36592 for eachCataloguePublicationTransmission entity 36576. There is one 36502APackageCompleted Indicator 36500A for eachCataloguePublicationTransmission entity 36576.

(8) Message Data Type Catalogue Publication Confirmation Message

The data model for the message data typeCataloguePublicationConfirmationMessage used to implement aCataloguePublicationConfirmation message 35914 is depicted in FIG. 366A.The message data type CataloguePublicationConfirmationMessage includes aCataloguePublicationConfirmationMessage package 36602. TheCataloguePublicationConfirmationMessage package 36602 includes aMessageHeader package 36604, a TransmissionInformation package 36506, aCatalogue package 36608, and a CataloguePublicationConfirmationMessageobject or entity 36610.

(a) Message Header Package

The MessageHeader package 36604 includes a MessageHeader entity 36612and a SenderParty entity 36616. There is a 1:1 relationship 36614between the MessageHeader entity 36612 and theCataloguePublicationConfirmationMessage entity 36610. There is a 1:crelationship 36618 between the MessageHeader entity 36612 and theSenderParty entity 36616.

As discussed above, the MessageHeader entity 36612 groups thebusiness-related information from the sending application's or businessentity's point of view for identifying the Business Document in amessage, information about the sender, and potentially information aboutthe receiver. The MessageHeader entity 36612 is of type GDTBusinessDocumentMessageHeader.

The SenderParty entity 36616 is the party responsible for sending of abusiness document on a business-related application level. TheSenderParty entity 36616 is of type GDTBusinessDocumentMessageHeaderParty.

(b) Transmission Information Package

The TransmissionInformation package 36606 groups the informationpertaining to the transmission of the object or entity (e.g., theCataloguePublicationConfirmationMessage entity 36610) included in themessage. The TransmissionInformation package 36606 includes aTransmissionHeader entity 36620 and a TransmissionLog entity 36622. TheTransmissionHeader entity 36620 provides information about theidentification of a transmission. The TransmissionHeader entity 36620includes an ID of type GDT: TransmissionID. The TransmissionLog entity36622 is a collection of events that occurred during processing of thetransmitted business document object (e.g., theCataloguePublicationConfirnationMessage entity 36610). There is a 1:crelationship 36624 between the CataloguePublicationConfirmationMessageentity 36610 and the TransmissionHeader entity 36620. There is also a1:c relationship 36626 between theCataloguePublicationConfirmationMessage entity 36610 and theTransmissionLog entity 36622. The TransmissionLog is subdivided into oneor more TransmissionLogItem (“Item”) entities 36628. EachTransmissionLogItem entity 36628 provides information about an eventthat occurred during processing of a CataloguePublicationRequest message35910. Each TransmissionLogItem entity 36628 is of type GDT: LogItem.The MinimumRequestedLogItemSeverityCode stated in messageCataloguePublicationRequest 35910 determines which LogItems are to bereturned by specifying their severity. There is a 1:n relationship 36630between the TransmissionLog entity 36622 and each TransmissionLogItementity 36628.

(c) Catalogue Package

The catalogue package 36608 groups the information pertaining to acatalogue. The catalogue package 36608 includes a Catalogue entity36632. There is a 1:1 relationship 36634 between theCataloguePublicationConfirmationMessage entity 36610 and the Catalogueentity 36632.

(i) CataloguePublicationTransmission Entity

The Catalogue entity 36632 in a CataloguePublicationConfirmation message36614 provides confirmation whether the publication or deletion of acatalogue was successful or not. The Catalogue entity 36632 includes anID and a PackageCompletedIndicator. The ID is of type GDT :CatalogueIDand identifies the catalogue upon which publication or deletion is beingconfirmed. The PublicationCompletedIndicator is of type GDTBusinessTransactionCompletedIndicator and specifies whether thepublishing or deletion of the catalogue was successful or not.

(d) Message Data Type—Element Structure

FIGS. 367A-C depict the element structure for aCataloguePublicationConfirmation message 35914. The element structure issimilar to the above described data model of the message data typeCataloguePublicationConfirmationMessage as reflected in FIG. 366, butprovides additional information regarding the details for interfacingwith or implementing a CataloguePublicationConfirmationMessage, such asa CataloguePublicationConfirmation message 35914. The element structureidentifies the different packages 36700 in the interface, and representsthe entities at various levels within the interface. As depicted in FIG.367, the interface for CataloguePublicationConfirmationMessage includesthree levels 36702, 36704, and 36706. The outermost package 36700 ofthis interface is a CataloguePublicationConfirmationMessage package36714, which includes a CataloguePublicationConfirmationMessage entity36716 at the first level 36702, a MessageHeader package 36722, aTransmissionInformation package 36756, and a Catalogue package 36786.The CataloguePublicationConfirmationMessage entity 36716 is of a typeMDT 36718 “CataloguePublicationConfirmationMessage” 36720.

The MessageHeader package 36722 includes a MessageHeader entity 36724 atthe second level 36704. The MessageHeader entity 36724 is of a type GDT36728 “BusinessDocumentMessageHeader” 36730, and there is one 36732MessageHeader entity 36724 for each MessageHeader package 36722.

The MessageHeader entity 36724 includes an ID 36732, CreationDateTime36740, and SenderParty 36748 at the third level 36706. The ID 36732 isof a type GDT 36736 “BusinessDocumentMessageID” 36738 and there is one36740 ID 36734 in a MessageHeader entity 36724. The CreationDateTime36740 is of a type GDT 36744 “DateTime” 36746 and there is one 36742CreationDateTime 36740 in a MessageHeader 36724. The SenderParty 36748is of a type GDT 36752 “BusinessDocumentMessageHeaderParty” 36754 andthere is zero or one 36750 SenderParty 36748 in a MessageHeader 36724.

The TransmissionInformation package 36756 includes TransmissionHeader36758 and a TransmissionLog 36774 at the second level 36704. TheTransmissionHeader 36758 is of a type“BusinessDocumentTransmissionHeader” 36764 and there is zero or one36760 TransmissionHeader 36758 in a TransmissionInformation package36756.

The TransmissionInformationHeader 36758 includes an ID 36766 at thethird level 36706. The ID 36766 is of a type GDT 36770 “TransmissionID”36772 and there is one 36768 ID 36766 in a TransmissionHeader 36758.

There is zero or one 36776 TransmissionLog 36774 in aTransmissionInformation package 36756. The TransmissionLog 36774includes an Item 36778 at the third level 36706. The Item 36778 is of atype GDT 36782 “LogItem” 36784, and there is one or more Item 36778 in aTransmissionLog 36774.

The Catalogue package 36786 includes a Catalogue entity 36788 at thesecond level 36704. The Catalogue entity 36788 is of a type“CataloguePublicationConfirmation” 36794 and there is one 36790Catalogue entity 36788 in a Catalogue package 36786.

The Catalogue entity 367088 includes an ID 36796 and aPublicationCompletedIndicator 36704A. The ID 36796 is of a type GDT36700A “CatalogueID” 36702A, and there is one 36798 ID 36796 in aCatalogue entity 36788. The PublicationCompletedIndicator 36704A is of atype GDT 36708A “BusinessTransactionCompletedIndicator” 36710A, andthere is one 36706A PublicationCompletedIndicator 36704A in a Catalogueentity 36788.

(9) Message Data Type Catalogue Publication Transmission CancellationRequest Message

The data model for the message data typeCataloguePublicationTransmissionCancellation RequestMessage used toimplement a CataloguePublicationTransmissionCancellationRequest message35916 is depicted in FIG. 368A. The message data typeCataloguePublicationTransmissionCancellationRequestMessage includes aCataloguePublicationTransmissionCancellationRequestMessage package36802. The CataloguePublicationTransmissionCancellationRequestMessagepackage 36802 includes a MessageHeader package 36804, aTransmissionInformation package 36506, aCataloguePublicationTransmission package 36808, and aCataloguePublicationTransmissionCancellationRequestMessage object orentity 36810.

(a) Message Header Package

The MessageHeader package 36804 includes a MessageHeader entity 36812and a SenderParty entity 36816. There is a 1:1 relationship 36814between the MessageHeader entity 36812 and theCataloguePublicationTransmissionCancellationRequestMessage entity 36810.There is a 1:c relationship 36818 between the MessageHeader entity 36812and the SenderParty entity 36816.

As discussed above, the MessageHeader entity 36812 groups thebusiness-related information from the sending application's or businessentity's point of view for identifying the Business Document in amessage, information about the sender, and potentially information aboutthe receiver. The MessageHeader entity 36812 is of type GDTBusinessDocumentMessageHeader.

The SenderParty entity 36816 is the party responsible for sending of abusiness document on a business-related application level. TheSenderParty entity 36816 is of type GDTBusinessDocumentMessageHeaderParty.

(b) Transmission Information Package

The TransmissionInformation package 36806 groups the informationpertaining to the transmission of the object or entity (e.g., theCataloguePublicationTransmissionCancellationRequestMessage entity 36810)included in the message. The TransmissionInformation package 36806includes a TransmissionHeader entity 36820. The TransmissionHeaderentity 36820 provides information about the identification of atransmission. The TransmissionHeader entity 36820 includes aMinimalRequestedLogItemSeverityCode of type GDT: LogItemSeverityCode.The MininmalRequestedLogItemSeverityCode specifies the severity of logitems to returned by aCataloguePublicationTransmissionCancellationConfirmation message 35918.There is a 1:c relationship 36822 between theCataloguePublicationTransmissionCancellationRequestMessage entity 36810and the TransmissionHeader entity 36820.

(c) CataloguePublicationTransmission Package

The CataloguePublicationTransmission package 36808 groups theinformation pertaining to a catalogue publication transmission. TheCataloguePublicationTransmission package 36808 includes a Cataloguepackage 36824 and a CataloguePublicationTransmission entity 36826. Thereis a 1:1 relationship 36828 between theCataloguePublicationTransmissionCancellationRequestMessage entity 36810and the CataloguePublicationTransmission entity 36826.

(i) CataloguePublicationTransmission Entity

The CataloguePublicationTransmission entity 36826 in aCataloguePublicationTransmissionCancellationRequest message 36814 is therequest to cancel the transmission of a catalogue and to restore anearlier published state (if such exists) of the catalogue. Moreover, nomore packages are sent for this transmission. TheCataloguePublicationTransmission entity 36826 includes an ID of type GDT:TransmissionID that identifies the catalogue transmission of theoriginal catalogue publication request.

(ii) Catalogue Package

The Catalogue package 36824 groups the information pertaining to thecatalogue to be restored. The Catalogue package 36824 includes aCatalogue entity 36830. There is a 1:1 relationship 36832 between theCataloguePublicationTransmission entity 36826 and the Catalogue entity36830.

(iii) Catalogue

The Catalogue entity 36830 specifies the information about a cataloguenecessary in the context of aCataloguePublicationTransmissionCancellationRequest so that, forexample, the Catalogue Search Engine is able to restore the catalogueidentified by the Catalogue entity 36830. The Catalogue entity 36830includes an ID of type GDT :CatalogueID, which identifies the catalogue.

(d) Message Data Type—Element Structure

FIGS. 369A-C depict the element structure for aCataloguePublicationTransmissionCancellationRequest message 35916. Theelement structure is similar to the above described data model of themessage data typeCataloguePublicationTransmissionCancellationRequestMessage as reflectedin FIG. 368A, but provides additional information regarding the detailsfor interfacing with or implementing aCataloguePublicationTransmissionCancellationRequestMessage data type,such as a CataloguePublicationTransmissionCancellationRequest message35916. As shown in FIG. 369A, the element structure identifies thedifferent packages 36900 that may be in a respectiveCataloguePublicationTransmissionCancellationRequest message 35916.

The element structure for theCataloguePublicationTransmissionCancellationRequest message 35916includes four levels 36902, 36904, 36906, and 36908 each of which isassociated with a respective package 36900. The element structureidentifies the occurrence or cardinality 36910 and data type information(i.e., type 36912 and name 36914) for the elements at the respectivelevels 36902, 36904, 36906, and 36908.

The outermost package of this interface is aCataloguePublicationTransmissionCancellationRequestMessage package36918, which includes aCataloguePublicationTransmissionCancellationRequestMessage entity 36918at the first level 36902. TheCataloguePublicationTransmissionCancellationRequestMessage entity 36918is of generic data type (“GDT”) 36922CataloguePublicationTransmissionCancellationRequestMessage 36924.

The CataloguePublicationTransmissionCancellationRequestMessage package36918 includes a MessageHeader package 36926, a TransmissionInformationpackage 36928, and a CataloguePublicationTransmission package 36930. TheMessageHeader package 36926 includes a MessageHeader entity 36932, whichis of type GDT 36936 BusinessDocumentMessageHeader 36938. There is one36934 MessageHeader entity 36932 for eachCataloguePublicationTransmissionCancellationRequestMessage entity 36920.

The MessageHeader entity 36932 includes an ID 36942 and aCreationDateTime 36950. The ID 36942 is of type GDT 36946BusinessDocumentMessageID 36948. The CreationDateTime 36950 is of typeGDT 36954 DateTime 36956. There is one 36944 ID 36942 for eachMessageHeader entity 36932 and one 36952 CreationDateTime 36950 for eachMessageHeader entity 36932.

The MessageHeader entity 36932 also includes a SenderParty entity 36958.The SenderParty entity 36958 is of type GDT 36962BusinessDocumentMessageHeaderParty 36964. There is one or zero 36960SenderParty entity 36958 for each MessageHeader entity 36932.

The TransmissionInformation package 36928 includes a TransmissionHeaderentity 36966. The TransmissionHeader entity 36966 is of type GDT 36970BusinessDocumentTransmissionHeader 36972. There is one or zero 36968TransmissionHeader entity 36966 for eachCataloguePublicationTransmissionCancellationRequestMessage entity 36920.The TransmissionHeader entity 36966 includes aMinimalRequestedLogItemSeverityCode 36976 of type GDT 36980LogItemSeverityCode 36982. There is one or zero 36978MinimalRequestedLogItemSeverityCode 36976 for each TransmissionHeaderentity 36966.

The CataloguePublicationTransmission package 36930 includes aCataloguePublicationTransmission entity 36984. TheCataloguePublicationTransmission entity 36984 is of type GDT 36988CataloguePublicationTransmissionCancellationRequest 36990. There is one36986 CataloguePublicationTransmission entity 36984 for eachCataloguePublicationTransmissionCancellationRequestMessage entity 36918.The CataloguePublicationTransmission entity 36984 includes an ID 36992.The ID 36992 is of type GDT 36996 TransmissionID 36998. There is one36994 ID 36992 for each CataloguePublicationTransmission entity 36984.

The CataloguePublicationTransmission package 36930 also includes aCatalogue package 36900A. The Catalogue package 36900A includes aCatalogue entity 36902A. In one implementation, there is one 36904ACatalogue entity 36902A for each CataloguePublicationTransmission entity36984. The Catalogue entity 36902A includes an ID 36906A. The ID 36906Ais of type GDT 36910A CatalogueID 36912A. There is one 36906A ID 36906Afor each Catalogue entity 36902A.

(10) Message Data Type Catalogue Publication Transmission CancellationConfirmation Message

The data model for the message data typeCataloguePublicationTransmissionCancellation ConfirmationMessage used toimplement a CataloguePublicationTransmissionCancellationConfirmationmessage 35918 is depicted in FIG. 370A. The message data typeCataloguePublicationTransmissionCancellationConfirmationMessage includesa CataloguePublicationTransmissionCancellationConfirmationMessagepackage 37002. TheCataloguePublicationTransmissionCancellationConfirmationMessage package37002 includes a MessageHeader package 37004, a TransmissionInformationpackage 37006, a CataloguePublicationTransmission package 37008, and aCataloguePublicationTransmissionCancellationConfirmationMessage objector entity 37010.

(a) Message Header Package

The MessageHeader package 37004 includes a MessageHeader entity 37012and a SenderParty entity 37016. There is a 1:1 relationship 37014between the MessageHeader entity 37012 and theCataloguePublicationTransmissionCancellationConfirmationMessage entity37010. There is a 1:c relationship 37018 between the MessageHeaderentity 37012 and the SenderParty entity 37016. The MessageHeader entity37012 is of type GDT BusinessDocumentMessageHeader. The SenderPartyentity 37016 is of type GDT BusinessDocumentMessageHeaderParty.

(b) Transmission Information Package

The TransmissionInformation package 37006 groups the informationpertaining to the transmission of the object or entity (e.g., theCataloguePublicationTransmissionConfirmationCancellationMessage entity37010) included in the message. The TransmissionInformation package36406 includes a TransmissionLog entity 37020, which is a collection ofevents that occurred during processing of the transmitted businessdocument object. The TransmissionLog entity 37020 includes one or moreTransmissionLogItem (“Item”) entities 37024. Each TransmissionLogItementity 37024 provides information about an event that occurred duringprocessing of the respective transmitted business document object. EachTransmissionLogItem entity 37024 is of type GDT: LogItem. TheMinimumRequestedLogItemSeverityCode stated in aCataloguePublicationTransmissionCancellationRequest message 35916determines which LogItems are to be returned by specifying theirseverity. There is a 1:c relationship 37022 between theCataloguePublicationTransmissionConfirmationCancellation Message entity37010 and the TransmissionLog entity 37020 and a 1:n relationship 37026between the TransmissionLog entity 37020 and each TransmissionLogItementity 37024.

(c) CataloguePublicationTransmission Package

The CataloguePublicationTransmission package 37008 groups theinformation pertaining to a catalogue publication transmission. TheCataloguePublicationTransmission package 37008 includes a Cataloguepackage 37028 and a CataloguePublicationTransmission entity 37030. Thereis a 1:1 relationship 37032 between theCataloguePublicationTransmissionCancellationConfirmationMessage entity37010 and the CataloguePublicationTransmission entity 37030.

(i) CataloguePublicationTransmission Entity

The CataloguePublicationTransmission entity 37030 in aCataloguePublicationTransmissionCancellationConfirmation message 37018is the confirmation whether the transmission of a catalogue has beencancelled successfully and an earlier published state of this catalogue(if such exists) has been restored or not. TheCataloguePublicationTransmission entity 37030 includes an ID of type GDT:TransmissionID that identifies the transmission of the cataloguepublication request which was requested to be cancelled. TheCataloguePublicationTransmission entity 37030 also includes aCancellationCompletedIndicator of type GDT:BusinessTransactionCompletedIndicator that specifies whether thecatalogue publication transmission was cancelled successfully or not. Aspreviously discussed,CataloguePublicationTransmissionCancellationConfirmation message 37018is sent by the Catalogue Search Engine 3596 to the Catalogue AuthoringTool 3594 in order to signal that the publication has been cancelledsuccessfully or not.

(ii) Catalogue Package

The Catalogue package 37028 groups the information pertaining to thecatalogue to be restored. The Catalogue package 37028 includes aCatalogue entity 37034. There is a 1:1 relationship 37036 between theCataloguePublicationTransmission entity 37030 and the Catalogue entity37034.

(iii) Catalogue

The Catalogue entity 37030 specifies the information about a cataloguein the context of aCataloguePublicationTransmissionCancellationConfirmation message 35918to confirm cancellation by the Catalogue Search Engine 3596 to theCatalogue Authoring Tool 3594. The Catalogue entity 37030 includes an IDof type GDT :CatalogueID, which identifies the catalogue.

(d) Message Data Type—Element Structure

FIGS. 371A-C depict the element structure for aCataloguePublicationTransmissionCancellationConfirmation message 35918.The element structure is similar to the above described data model ofthe message data typeCataloguePublicationTransmissionCancellationConfirmationMessage asreflected in FIG. 369A, but provides additional information regardingthe details for interfacing with or implementing aCataloguePublicationTransmissionCancellationConfirmationMessage datatype, such as a CataloguePublicationTransmissionCancellationConfirmationmessage 35918. As shown in FIG. 371A, the element structure identifiesthe different packages 37100 that may be in a respectiveCataloguePublicationTransmissionCancellationConfirmation message 35918.The element structure for theCataloguePublicationTransmissionCancellationConfirmation message 35918includes four levels 37102, 37104, 37106, and 37108 each of which isassociated with a respective package 37100. The element structureidentifies the occurrence or cardinality 37110 and data type information(i.e., type 37112 and name 37114) for the elements at the respectivelevels 37102, 37104, 37106, and 37108.

The outermost package of this interface is aCataloguePublicationTransmissionCancellationConfirmationMessage package37118, which includes aCataloguePublicationTransmissionCancellationConfirmationMessage entity37120 at the first level 37102. TheCataloguePublicationTransmissionCancellationConfirmationMessage entity37120 is of generic data type (“GDT”) 37122CataloguePublicationTransmissionCancellationConfirmationMessage 37124.

The CataloguePublicationTransmissionCancellationConfirmationMessagepackage 37118 includes a MessageHeader package 37126, aTransmissionInformation package 37128, and aCataloguePublicationTransmission package 37130. The MessageHeaderpackage 37126 includes a MessageHeader entity 37132, which is of typeGDT 37136 BusinessDocumentMessageHeader 37138. There is one 37134MessageHeader entity 37132 for eachCataloguePublicationTransmissionCancellationConfirmationMessage entity37120.

The MessageHeader entity 37132 includes an ID 37142 and aCreationDateTime 37150. The ID 37142 is of type GDT 37146BusinessDocumentMessageID 37148. The CreationDateTime 37150 is of typeGDT 37154 DateTime 37156. There is one 37144 ID 37142 for eachMessageHeader entity 37132 and one 37152 CreationDateTime 37150 for eachMessageHeader entity 37132.

The MessageHeader entity 37132 also includes a SenderParty entity 37158.The SenderParty entity 37158 is of type GDT 37162BusinessDocumentMessageHeaderParty 37164. There is one or zero 37160SenderParty entity 37158 for each MessageHeader entity 37132.

The TransmissionInformation package 37128 includes a TransmissionLogentity 37166. There is one or zero 37168 TransmissionLog entity 37166for each CataloguePublicationTransmissionCancellationConfirmationMessageentity 37120. The TransmissionLog 37166 includes an Item 37170 of typeGDT 37174 LogItem 37176. There is one or more 37172 Items 37170 for eachTransmissionLog entity 37166.

The CataloguePublicationTransmission package 37130 includes aCataloguePublicationTransmission entity 37178. TheCataloguePublicationTransmission entity 37178 is of type GDT 37182CataloguePublicationTransmissionCancellationConfirtnation 37184. Thereis one 37180 CataloguePublicationTransmission entity 37178 for eachCataloguePublicationTransmissionCancellationConfirmationMessage entity37120. The CataloguePublicationTransmission entity 37178 includes an ID37186. The ID 37186 is of type GDT 37190 TransmissionID 37192. There isone 37188 ID 37186 for each CataloguePublicationTransmission entity37178.

The CataloguePublicationTransmission entity 37178 also includes aPackageCompletedIndicator 37194. The PackageCompletedIndicator 37194 isof type GDT 37198 BusinessTransactionCompletedIndicator 37100A. There isone 37196 PackageCompleted Indicator 37194 for eachCataloguePublicationTransmission entity 37178.

The CataloguePublicationTransmission package 37130 further includes aCatalogue package 37102A. The Catalogue package 37102A includes aCatalogue entity 37104A. In one implementation, there is one 37106ACatalogue entity 37104A for each CataloguePublicationTransmission entity37178. The Catalogue entity 37104A includes an ID 37108A. The ID 37108Ais of type GDT 37112A CatalogueID 37114A. There is one 37110A ID 37108Afor each Catalogue entity 37104A.

(11) Message Data Type Catalogue Publication Transmission Item LockRequest Message

The data model for the message data typeCataloguePublicationTransmissionItemLock RequestMessage used toimplement a CataloguePublicationTransmissionItemLockRequest message35920 is depicted in FIG. 372A. The message data typeCataloguePublicationTransmissionItemLockRequestMessage includes aCataloguePublicationTransmissionItemLockRequestMessage package 37202.The CataloguePublicationTransmissionItemLockRequestMessage package 37202includes a MessageHeader package 37204, a TransmissionInformationpackage 36506, a CataloguePublicationTransmission package 37208, and aCataloguePublicationTransmissionItemLockRequestMessage object or entity37210.

(a) Message Header Package

The MessageHeader package 37204 includes a MessageHeader entity 37212and a SenderParty entity 37216. There is a 1:1 relationship 37214between the MessageHeader entity 37212 and theCataloguePublicationTransmissionItemLockRequestMessage entity 37210.There is a 1:c relationship 37218 between the MessageHeader entity 37212and the SenderParty entity 37216. The MessageHeader entity 37212 is oftype GDT BusinessDocumentMessageHeader. The SenderParty entity 37216 isof type GDT BusinessDocumentMessageHeaderParty.

(b) Transmission Information Package

The TransmissionInformation package 37206 groups the informationpertaining to the transmission of the object or entity (e.g., theCataloguePublicationTransmissionItemLockRequestMessage entity 37210)included in the message. The TransmissionInformation package 37206includes a TransmissionHeader entity 37220. The TransmissionHeaderentity 37220 provides information about the identification of thetransmission. The TransmissionHeader entity 37220 includes aMinimalRequestedLogItemSeverityCode of type GDT: LogItemSeverityCode.The MininmalRequestedLogItemSeverityCode specifies the severity of logitems to returned by theCataloguePublicationTransmissionItemLockConfirmation message 35920.There is a 1:c relationship 37222 between theCataloguePublicationTransmissionItemLockRequestMessage entity 37210 andthe TransmissionHeader entity 37220.

(c) CataloguePublicationTransmission Package

The CataloguePublicationTransmission package 37208 groups theinformation pertaining to a catalogue publication transmission. TheCataloguePublicationTransmission package 37208 includes a Cataloguepackage 37224 and a CataloguePublicationTransmission entity 37226. Thereis a 1:1 relationship 37228 between theCataloguePublicationTransmissionItemLockRequestMessage entity 37210 andthe CataloguePublicationTransmission entity 37226.

(i) CataloguePublicationTransmission Entity

The CataloguePublicationTransmission entity 37226 in aCataloguePublicationTransmissionItemLockRequest message 37214 is therequest to lock single items of the catalogue included in the cataloguepublication transmission. To lock means if the catalogue is not yetpublished the items are not published; if the catalogue is alreadypublished, the publication of these items is revoked. TheCataloguePublicationTransmission entity 37226 includes an ID of type GDT:TransmissionID that identifies the CataloguePublicationTransmission ofwhich the items are to be locked.

(ii) Catalogue Package

The Catalogue package 37224 groups the information pertaining to thecatalogue. The Catalogue package 37224 includes a Content package 37230and a Catalogue entity 37232. There is a 1:c relationship 37234 betweenthe CataloguePublicationTransmission entity 37226 and the Catalogueentity 37232.

(iii) Catalogue

The Catalogue entity 37232 specifies the information about a cataloguenecessary in the context of aCataloguePublicationTransmissionItemLockRequest so that, for example,the Catalogue Search Engine is able to lock the identified catalogueitems. The Catalogue entity 37232 includes an ID of type GDT:CatalogueID, which identifies the catalogue from which selected itemsare to be locked.

(iv) Catalogue Publication Transmission Catalogue Content Package

The CatalogueContent package 37230 includes a CatalogueItem package37236 and a Content entity 37238, which specifies the list of businessobjects or entitites which are to be locked. There is a 1:1 relationship37240 between the Catalogue entity 37232 and the Content entity 37238.

(a) Catalogue Publication Transmission Catalogue Content Catalogue ItemPackage

The CatalogueItem package 37236 groups the information pertaining to theitems to be locked. The CatalogueItem package 37236 includes aCatalogueItem entity 37242, which includes the information about anidentified catalogue item to allow the Catalogue Search Engine 3596 tolock the identified catalogue item. The CatalogueItem entity 37242includes an ID, which identifies the catalogue item to be locked. Thereis a 1:n relationship 37244 between the Content entity 37238 and theCatalogueItem entity 37242.

(d) Message Data Type—Element Structure

FIGS. 373A-C depict the element structure for aCataloguePublicationTransmissionItemLockRequest message 35920. Theelement structure is similar to the above described data model of themessage data type CataloguePublicationTransmissionItemLockRequestMessageas reflected in FIG. 372A, but provides additional information regardingthe details for interfacing with or implementing aCataloguePublicationTransmissionItemLockRequestMessage data type, suchas a CataloguePublicationTransmissionItemLockRequest message 35920. Asshown in FIG. 373A, the element structure identifies the differentpackages 37300 that may be in a respectiveCataloguePublicationTransmissionItemLockRequest message 35920. Theelement structure for theCataloguePublicationTransmissioniItemLockRequest message 35920 includessix levels 37302, 37304, 37306, 37308, 37310, and 37312 each of which isassociated with a respective package 37300. The element structureidentifies the occurrence or cardinality 37314 and data type information(i.e., type 37316 and name 37318) for the elements at the respectivelevels 37302, 37304, 37306, 37308, 37310, and 37312.

The outermost package of this interface is aCataloguePublicationTransmissionItemLockRequestMessage package 37320,which includes a CataloguePublicationTransmissionItemLockRequestMessageentity 37322 at the first level 37302. TheCataloguePublicationTransmissionItemLockRequestMessage entity 37322 isof generic data type (“GDT”) 37323CataloguePublicationTransmissionItemLockRequestMessage 37324.

The CataloguePublicationTransmissionItemLockRequestMessage package 37320includes a MessageHeader package 37326, a TransmissionInformationpackage 37328, and a CataloguePublicationTransmission package 37330. TheMessageHeader package 37326 includes a MessageHeader entity 37332, whichis of type GDT 37336 BusinessDocumentMessageHeader 37338. There is one37334 MessageHeader entity 37332 for eachCataloguePublicationTransmissionItemLockRequestMessage entity 37322.

The MessageHeader entity 37332 includes an ID 37340 and aCreationDateTime 37348. The ID 37340 is of type GDT 37344BusinessDocumentMessageID 37346. The CreationDateTime 37348 is of typeGDT 37352 DateTime 37354. There is one 37342 ID 37340 for eachMessageHeader entity 37332 and one 37350 CreationDateTime 37348 for eachMessageHeader entity 37332.

The MessageHeader entity 37332 also includes a SenderParty entity 37356.The SenderParty entity 37356 is of type GDT 37360BusinessDocumentMessageHeaderParty 37362. There is one or zero 37358SenderParty entity 37356 for each MessageHeader entity 37332.

The TransmissionInformation package 37328 includes a TransmissionHeaderentity 37364. The TransmissionHeader entity 37364 is of type GDT 37368BusinessDocumentTransmissionHeader 37370. There is one or zero 37366TransmissionHeader entity 37364 for eachCataloguePublicationTransmissionItemLockRequestMessage entity 37322. TheTransmissionHeader entity 37364 includes aMinimalRequestedLogItemSeverityCode 37372 of type GDT 37376LogItemSeverityCode 37378. There is one or zero 37374MinimalRequestedLogItemSeverityCode 37372 for each TransmissionHeaderentity 37364.

The CataloguePublicationTransmission package 37330 includes aCataloguePublicationTransmission entity 37380. TheCataloguePublicationTransmission entity 37380 is of type GDT 37384CataloguePublicationTransmissionItemLockRequest 37386. There is one37382 CataloguePublicationTransmission entity 37380 for eachCataloguePublicationTransmissionItemLockRequestMessage entity 37322. TheCataloguePublicationTransmission entity 37380 includes an ID 37388. TheID 37388 is of type GDT 37392 TransmissionID 37394. There is one 37390ID 37388 for each CataloguePublicationTransmission entity 37380.

The CataloguePublicationTransmission package 37330 also includes aCatalogue package 37396. The Catalogue package 37396 includes aCatalogue entity 37398. In one implementation, there is one 37300ACatalogue entity 37398 for each CataloguePublicationTransmission entity37380. The Catalogue entity 37398 includes an ID 37302A. The ID 37302Ais of type GDT 37306A CatalogueID 37308A. There is one 37304A ID 37302Afor each Catalogue entity 37398.

The Catalogue package 37396 also includes a Content package 37310A. TheContent package 37310A includes a Content entity 37312A and anItempackage 37316A. In one implementation, there is one 37314A Contententity 37312A for each Catalogue entity 37398.

The Item package 37316A includes an Item entity 37318A. There is one ormore 37320A Item entities 37318A for each Content entity 37312A. EachItem entity 37318A includes an ID 37322A. The ID 37322A is of type GDT37326A CatalogueItemID 37328A. There is one 37324A ID 37322A for eachItem entity 37316A.

(12) Message Data Type Catalogue Publication Transmission Item LockConfirmation Message

The data model for the message data typeCataloguePublicationTransmissionCancellation ConfirmationMessage used toimplement a CataloguePublicationTransmissionItemLockConfirmation message35920 is depicted in FIG. 374A. The message data typeCataloguePublicationTransmissionItemLockConfirmationMessage includes aCataloguePublicationTransmissionItemLockConfirmationMessage package37402. The CataloguePublicationTransmissionItemLockConfirmationMessagepackage 37402 includes a MessageHeader package 37404, aTransmissionInformation package 37406, aCataloguePublicationTransmission package 37408, and aCataloguePublicationTransmissionItemLockConfirmationMessage object orentity 37410.

(a) Message Header Package

The MessageHeader package 37404 includes a MessageHeader entity 37412and a SenderParty entity 37416. There is a 1:1 relationship 37414between the MessageHeader entity 37412 and theCataloguePublicationTransmissionItemLockConfirmationMessage entity37410. There is a 1:c relationship 37418 between the MessageHeaderentity 37412 and the SenderParty entity 37416. The MessageHeader entity37412 is of type GDT BusinessDocumentMessageHeader. The SenderPartyentity 37416 is of type GDT BusinessDocumentMessageHeaderParty.

(b) Transmission Information Package

The TransmissionInformation package 37406 groups the informationpertaining to the transmission of the object or entity (e.g., theCataloguePublicationTransmissionConfirmationCancellationMessage entity37410) included in the message. The TransmissionInformation package36406 includes a TransmissionLog entity 37420, which is a collection ofevents that occurred during processing of the transmitted businessdocument object. The TransmissionLog entity 37420 includes one or moreTransmissionLogItem (“Item”) entities 37424. Each TransmissionLogItementity 37424 provides information about an event that occurred duringprocessing of the respective transmitted business document object. EachTransmissionLogItem entity 37424 is of type GDT: LogItem. TheMinimumRequestedLogItemSeverityCode provided in aCataloguePublicationTransmissionItemLockRequest message 35920 determineswhich TransmissionLogItems are to be returned by specifying theirseverity. There is a 1:c relationship 37422 between theCataloguePublicationTransmissionConfirmationCancellation Message entity37410 and the TransmissionLog entity 37420 and a 1:n relationship 37426between the TransmissionLog entity 37420 and each TransmissionLogItementity 37424.

(c) CataloguePublicationTransmission Package

The CataloguePublicationTransmission package 37408 groups theinformation pertaining to a catalogue publication transmission. TheCataloguePublicationTransmission package 37408 includes a Cataloguepackage 37428 and a CataloguePublicationTransmission entity 37430. Thereis a 1:1 relationship 37432 between theCataloguePublicationTransmissionItemLockConfirmationMessage entity 37410and the CataloguePublicationTransmission entity 37430.

(i) CataloguePublicationTransmission Entity

The CataloguePublicationTransmission entity 37430 in aCataloguePublicationTransmissionItemLockConfirmation message 35920 isthe confirmation whether identified items of the catalogue included inthe catalogue publication transmission could be locked or not. To lockmeans: if the catalogue is not yet published the items are notpublished; if the catalogue is already published, the publication ofthese items is revoked. The CataloguePublicationTransmission entity37430 includes an ID of type GDT :TransmissionID that identifies theCatalogue publication transmission or the original catalogue publicationrequest of which items where requested to be locked. TheCataloguePublicationTransmission entity 37430 also includes aItemLockCompletedIndicator of type GDT:BusinessTransactionCompletedIndicator that specifies whether theidentified items were locked or not.

(ii) Catalogue Package

The Catalogue package 37428 groups the information pertaining to thecatalogue. The Catalogue package 37428 includes a Catalogue entity37434. There is a 1:c relationship 37436 between theCataloguePublicationTransmission entity 37430 and the Catalogue entity37434.

(iii) Catalogue

The Catalogue entity 37434 specifies the information about a cataloguein the context of a message 35922 to confirm to the Catalogue AuthoringTool 3594 that an identified item is locked by the Catalogue SearchEngine 3596. The Catalogue entity 37430 includes an ID of type GDT:CatalogueID, which identifies the catalogue from which the identifieditems are to be locked.

(d) Message Data Type—Element Structure

FIGS. 375A-C depict the element structure for aCataloguePublicationTransmissionItemLockConfirmation message 35920. Theelement structure is similar to the above described data model of themessage data typeCataloguePublicationTransmissionItemLockConfirmationMessage as reflectedin FIG. 374A, but provides additional information regarding the detailsfor interfacing with or implementing aCataloguePublicationTransmissionItemLockConfirmationMessage data type,such as a CataloguePublicationTransmissionItemLockConfirmation message35920. As shown in FIG. 375A, the element structure identifies thedifferent packages 37500 that may be in a respectiveCataloguePublicationTransmissionItemLockConfirmation message 35920. Theelement structure for theCataloguePublicationTransmissionItemLockConfirmation message 35920includes four levels 37502, 37504, 37506, and 37508 each of which isassociated with a respective package 37500. The element structureidentifies the occurrence orcardinality 37510 and data type information(i.e., type 37512 and name 37514) for the elements at the respectivelevels 37502, 37504, 37506, and 37508.

The outermost package of this interface is aCataloguePublicationTransmissionItemLockConfirmationMessage package37518, which includes aCataloguePublicationTransmissionItemLockConfirmationMessage entity 37520at the first level 37502. TheCataloguePublicationTransmissionItemLockConfirmationMessage entity 37520is of generic data type (“GDT”) 37522CataloguePublicationTransmissionItemLockConfirmationMessage 35920.

The CataloguePublicationTransmissionItemLockConfirmationMessage package37518 includes a MessageHeader package 37526, a TransmissionInformationpackage 37528, and a CataloguePublicationTransmission package 37530. TheMessageHeader package 37526 includes a MessageHeader entity 37532, whichis of type GDT 37536 BusinessDocumentMessageHeader 37538. There is one37534 MessageHeader entity 37532 for eachCataloguePublicationTransmissionItemLockConfinnationMessage entity37520.

The MessageHeader entity 37532 includes an ID 37542 and aCreationDateTime 37550. The ID 37542 is of type GDT 37546BusinessDocumentMessageID 37548. The CreationDateTime 37550 is of typeGDT 37554 DateTime 37556. There is one 37544 ID 37542 for eachMessageHeader entity 37532 and one 37552 CreationDateTime 37550 for eachMessageHeader entity 37532.

The MessageHeader entity 37532 also includes a SenderParty entity 37558.The SenderParty entity 37558 is of type GDT 37562BusinessDocumentMessageHeaderParty 37564. There is one or zero 37560SenderParty entity 37558 for each MessageHeader entity 37532.

The TransmissionInformation package 37528 includes a TransmissionLogentity 37566. There is one or zero 37568 TransmissionLog entity 37566for each CataloguePublicationTransmissionItemLockConfirmationMessageentity 37520. The TransmissionLog 37566 includes an Item 37570 of typeGDT 37574 LogItem 37576. There is one or more 37572 Items 37570 for eachTransmissionLog entity 37566.

The CataloguePublicationTransmission package 37530 includes aCataloguePublicationTransmission entity 37578. TheCataloguePublicationTransmission entity 37578 is of type GDT 37582CataloguePublicationTransmissionItemLockConfirmation 37584. There is one37580 CataloguePublicationTransmission entity 37578 for eachCataloguePublicationTransmissionItemLockConfirmationMessage entity37520. The CataloguePublicationTransmission entity 37578 includes an ID37586. The ID 37586 is of type GDT 37590 TransmissionID 37592. There isone 37588 ID 37586 for each CataloguePublicationTransmission entity37578.

The CataloguePublicationTransmission entity 37578 also includes anItemLockCompletedIndicator 37594. The ItemLockCompletedIndicator 37594is of type GDT 37598 BusinessTransactionCompletedIndicator 37500A. Thereis one 37596 ItemLockCompleted Indicator 37594 for eachCataloguePublicationTransmission entity 37578.

The CataloguePublicationTransmission package 37530 further includes aCatalogue package 37502A. The Catalogue package 37502A includes aCatalogue entity 37504A. In one implementation, there is one 37506ACatalogue entity 37504A for each CataloguePublicationTransmission entity37578. The Catalogue entity 37504A includes an ID 37508A. The ID 37508Ais of type GDT 37512A CatalogueID 37514A. There is one 37510A ID 37508Afor each Catalogue entity 37504A.

(13) Message Data Type Catalogue Publication Transmission Content ChangeRequest Message

The message data typeCataloguePublicationTransmissionContentChangeRequestMessage 375A02includes the object CataloguePublicationTransmission contained in thebusiness document in the view required for theCataloguePublicationTransmissionContentChangeRequest, and thebusiness-related information relevant for sending of a business documentin a message.

The message data typeCataloguePublicationTransmissionContentChangeRequestMessage 375A02contains the MessageHeader package 375A04, TransmissionInformationpackage 375A06, and CataloguePublicationTransmission package 375A08. Themessage data typeCataloguePublicationTransmissionContentChangeRequestMessage 375A02provides a structure for message typeCataloguePublicationTransmissionContentChangeRequest.

(a) Message Header Package

The CataloguePublicationTransmissionContentMessageHeader package 375A04is similar to the CatalogueUpdateMessage message header.

(b) Transmission Information Package

The TransmissionInformation package 375A06 groups information pertainingto the transmission of the object (CataloguePublicationTransmission)contained in the message and contains the TransmissionHeader entity. TheTransmissionHeader entity 375A16 specifies a minimum requested severityof events occurring during processing of a transmission which has to belogged and returned. The TransmissionHeader entity 375A16 contains aMinimumRequestedLogItemSeverityCode that specifies the severity of logitems to be returned by messageCataloguePublicationTransmissionItemLockConfirmation. (GDTLogItemSeverityCode). Also within the TransmissionInformation package375A06 is the CataloguePublicationTransmission package 375A08.

(c) Catalogue Publication Transmission Package

CataloguePublicationTransmission Package 375A08 groups informationpertaining to a catalogue publication transmission (e.g., it groups theCataloguePublicationTransmission with its package, Catalogue).

(i) Catalogue Publication Transmission Entity

A CataloguePublicationTransmission in the view required for theCataloguePublicationTransmissionContentChangeRequest contains theinformation that is necessary to request the update of catalog items ofthe catalog publication transmission. The entityCataloguePublicationTransmission 375A18 contains an ID element thatidentifies the CataloguePublicationTransmission of which the itemsshould be updated. The ID is of type GDT TransmissionID.

(ii) Catalogue Publication Transmission Catalogue Package

The CataloguePublicationTransmissionCatalogue Package 375A20 containsthe package CatalogueContent 375A22.

(iii) Catalogue

A Catalogue 375A24 in the view required for theCataloguePublicationTransmissionContentChangeRequest contains allinformation necessary to update (change, delete and create) catalogitems.

A catalog (in general) can be a structured directory of catalog items,where each item represents an object, and provides information about theobject. The Catalogue 375A24 can contain catalogue header informationand content information, where content information contains the items ofthe catalog and their structural assignment within the catalog structure(see package CatalogueContent). The Catalogue 375A24 can contain theelements/attributes: @completeTransmissionIndicator, @languageCode,@currencyCode, @unitCode, and ID.

@completeTransmissionIndicator can indicate whether all data of thecatalog is included or not. The value should be “false” (GDTCompleteTransmissionIndicator). @languageCode can specify the languagefor a specific description/name, where the value is the default (GDTLanguageCode). @currencyCode can specify the currency in element Amount,where the value is the default (GDT CurrencyCode). @unitCode can specifya unit code in element Quantity, where the value is the default (GDTMeasureUnitCode). ID can identify the catalog from which the itemsshould be changed, deleted or created (GDT CatalogueID). In variations,@actionCode is not needed as default “02” (CHANGE) can be used asdeletion and replacement of catalog is not allowed via this message.

(iv) Catalogue Publication Transmission Catalogue Content Package

CataloguePublicationTransmissionCatalogueContent Package groups aCatalogueContent package 375A22 with the packages CatalogueItem 375A26,CatalogueView 375A28, and a CatalogueContent entity 375A30. Contentspecifies the list of items, which have to be updated (changed, deletedor created). The CatalogContent 375A30 contains the elementsCatalogueItemListCompleteTransmissionIndicator,CatalogueItemRelationshipListCompleteTransmissionIndicator,CatalogueViewListCompleteTransmissionIndicator, and CatalogueSchemaID.

CatalogueItemListCompleteTransmissionIndicator can specify whether thelist of Items is transmitted completely. The value should be “false”(GDT CompleteTransmissionIndicator).CatalogueItemRelationshipListCompleteTransmissionIndicator can specifywhether the list of ItemRelationships is transmitted completely. Thevalue should be “false”. (GDT CompleteTransmissionIndicator).CatalogueViewListCompleteTransmissionIndicator can specify whether thelist of Views is transmitted completely. The value should be “false”(GDT CompleteTransmissionIndicator). CatalogueSchemaID can identify acatalogue schema to which the content belongs, and act as a defaultvalue for objects without a specified CatalgueSchemaID on a level beyondthat (GDT CatalogueSchemaID).

The CataloguePublicationTransmissionCatalogueContentCatalogueItemPackage 375A26 groups the CatalogueItems to be updated with theirrelationships. The CatalogueItem package 375A26 contains the entitiesCatalogueItem 375A32 and CatalogueItemRelationship 375A34. ACatalogueItem 375A32 contains all information about a catalogue itemnecessary to change, delete or update it and contains theelements/attributes @actionCode,PropertyValuationListCompleteTransmissionIndicator, and ID.

@actionCode can specify the operation to be performed on the item. Thisvalue can also be effectual for all objects underneath unless another@actionCode redefines this value (GDT ActionCode).PropertyValuationListCompleteTransmissionIndicator can indicate whetherthe list of PropertyValuation is transmitted completely or not (GDTCompleteTransmissionIndicator). ID can identify a catalogue item (GDTCatalogueItemID). In any case, the catalogue item ID should not beconfused with the identifier of the business object the item represents.

A CatalogueItemDescription 375A36 provides a description for an item invarious locales (e.g., in different languages). CatalogueItemDescription375A36 is of type GDT Description.

A CatalogueItemClassification 375A38 can classify an item by assigningit to a Section within one of the catalog's schemas which the itembelongs to. A CatalogueItemClassification 375A38 contains the elementsSchemaID, which can identify the schema that the item references (GDTCatalogueSchemaID); and SectionID, which can identify the Section thatthe item references. (GDT CatalogueSectionID). A system may enforce thatan Item may only be classified within a schema of the catalog, and onlyonce per schema. However, an item need not be classified in every schemaexplicitly. The Section specified by the SectionID should be defined inthe Schema specified by the CatalogueSchemaID.

A CatalogueItemPropertyValuation 375A40 can specify the value of aproperty that can be attributed to the object the item represents,according to one of the catalog schemas. CatalogueItemPropertyValuation375A38 is of type GDT: PropertyValuation, where the elements used are@actionCode, which can specify the operation to be performed on theproperty; PropertyReference; and ValueGroup with elements ID, ParentID,OrdinalNumberValue and PropertyValue (which can specify the value of theproperty/component).

PropertyValue is of type GDT PropertyValue, where the elements used areAmountSpecification, QuantitySpecification, Decimal Specification,FloatSpecification, IntegerSpecification, DateTimeSpecification,NameSpecification, IndicatorSpecification, and Integrity. Each propertyvaluation should refer to a property defined in the Schema orSchemaSection to which the Item belongs.

A CatalogueItemRelationship 375A34 can specify a relationship withcertain semantics between any two catalog items and can contain theelements/attributes @actionCode, (GDT ActionCode),SourceCatalogueItemID, TargetCatalogueItemID, and TypeCode. @actionCodecan specify the operation to be performed on an item relationship. Thisvalue can be effectual for all objects underneath unless another@actionCode redefines this value (GDT ActionCode). SourceCatalogueItemIDcan identify the source item (GDT CatalogueItemID).TargetCatalogueItemID can identify the target item (GDTCatalogueItemID). TypeCode can specify the semantics of the relationshipexisting between two items (GDT ObjectStructureRelationshipTypeCode).

The CatalogueContentCatalogueView Package 375A28 groups all informationpertaining to catalog views, and contains the entity CatalogueView. ACatalogueView entity 375A42 defines a restricted subset of a catalog byspecifying catalog items to be included. A CatalogueView 375A42 cancontain one or more CatalogueViewItems 375A44 which specify itemsincluded in the view, and contains the elements/attributes @actionCode,ID, Name, and ItemListCompleteTransmissionIndicator.

@actionCode can specify the operation to be performed on a view. Thisvalue is also effectual for all objects underneath unless another@actionCode redefines this value. Here the @actionCode has to be ofvalue “02” (CHANGE) (GDT ActionCode). ID can identify a view ID (GDTCatalogueViewID). Name can provide a name for the view in variouslanguages (GDT Name). ItemListCompleteTransmissionIndicator can specifywhether the item list is transmitted completely, where the value shouldbe “false” (GDT CompleteTransmissionIndicator).

A CatalogueViewItem 375A44 specifies a catalog item to be included inthe catalogue view. A CatalogueViewItem 375A44 can contain theelements/attributes @actionCode and ID. @actionCode can specify theoperation to be performed on an item of a view. This value can also beeffectual for all objects underneath unless another @actionCoderedefines this value (GDT ActionCode). ID can identify an item to beincluded in the catalogue view(GDT CatalogueItemID). The item referredto should be included in the catalogue using an appropriate catalogueitem (either within the same transmission or an earlier transmission).

(d) Message Data Type—Element Structure

FIGS. 375CA-CL depict the element structure for aCataloguePublicationTransmissionContentChangeRequestMessage. As shown inFIG. 375CA, the element structure identifies the different packages375C00 that may be in a respectiveCataloguePublicationTransmissionContentChangeRequestMessage. The elementstructure for theCataloguePublicationTransmissionContentchangeRequestMessage includesnine levels 375C01, 375C02, 375C03, 375C04, 375C05, 375C06, 375C07,375C08, and 375C09 each of which is associated with a respective package375C00. The element structure identifies the occurrence or cardinality375C10 and data type information (i.e., name 375C11) for the elements atthe respective levels 375C01, 375C02, 375C03, 375C04, 375C05, 375C06,375C07, 375C08, and 375C09.

The outermost package of this interface is aCataloguePublicationTransmissionContentChangeRequestMessage package375C12, which includes aCataloguePublicationTransmissionContentChangeRequestMessage entity375C13 at the first level 375C01. TheCataloguePublicationTransmissionContentChangeRequestMessage entity375C13 is of generic data type (“GDT”)CataloguePublicationTransmissionContentChangeRequestMessage 375C14.

The CataloguePublicationTransmissionContentChangeRequestMessage package375C12 includes a MessageHeader package 375C15, aTransmissionInformation package 375C28, and aCataloguePublicationTransmission package 375C35. The MessageHeaderpackage 375C16 includes a MessageHeader entity 375C16 at the secondlevel 375C02, which is of type GDT BusinessDocumentMessageHeader 375C18.There is one 375C17 MessageHeader entity 375C16 for eachCataloguePublicationTransmissionContentChangeRequestMessage entity375C13.

The MessageHeader entity 375C16 includes an ID 375C19 and aCreationDateTime 375C22 at the third level 375C03. The ID 375C19 is oftype GDT BusinessDocumentMessageID 375C21. The CreationDateTime 375C22is of type GDT DateTime 375C24. There is one 375C20 ID 375C19 for eachMessageHeader entity 375C16 and one 375C23 CreationDateTime 375C22 foreach MessageHeader entity 375C16.

The MessageHeader entity 375C16 also includes a SenderParty 375C25 atthe third level 375C03. The SenderParty 375C25 is of typeGD26BusinessDocumentMessageHeaderParty 375C27. There is one or zero375C60 SenderParty 375C25 for each MessageHeader entity 375C16.

The TransmissionInformation package 375C28 includes a TransmissionHeaderentity 375C29 at the second level 375C02. There is one or zero 375C30TransmissionHeader entity 375C29 for eachCataloguePublicationTransmissionContentChangeRequestMessage entity375C13. The TransmissionHeader 375C29 includes aMinimalRequestedLogItemSeverityCode 375C32 of type GDTLogItemSeverityCode 375C34. There is one or more 375C33MinimalRequestedLogItemSeverityCode 375C32 for each TransmissionHeaderentity 375C29.

The CataloguePublicationTransmission package 375C35 includes aCataloguePublicationTransmission entity 375C36 at the second level375C02. The CataloguePublicationTransmission entity 375C36 is of typeGDT CataloguePublicationTransmissionContentChangeRequest375C38. There isone 375C37 CataloguePublicationTransmission entity 375C36 for eachCataloguePublicationTransmissionContentChangeRequestMessage entity375C13. The CataloguePublicationTransmission entity 375C36 includes anID 375C39. The ID 375C39 is of type GDT TransmissionID 375C41. There isone 375C40 ID 375C39 for each CataloguePublicationTransmission entity375C36.

The CataloguePublicationTransmission package 375C35 further includes aCatalogue package 375C42. The Catalogue package 375C42 includes aContent package 375C61. The Catalogue package 375C42 includes aCatalogue entity 375C43 at the third level 375C03. The Catalogue entity375C43 is of type GDTCataloguePublicationTransmissionContentChangeRequestCatalogue 375C45.There is one 375C44 Catalogue entity 375C43 for eachCataloguePublicationTransmission entity 375C36.

The Catalogue entity 375C43 includes a @completeTrans-missionIndicator375C46, a @languageCode 375C49, a @currencyCode 375C52, a@unitCode375C55 and an ID 375C58 at the forth level 375C04. The@completeTrans-missionIndicator 375C46 is of type GDTCompleteTransmissionIndicator 375C48. There is one 375C47@completeTrans-missionIndicator 375C46 for each Catalogue entity 375C43.The @languageCode 375C49 is of type GDT LanguageCode 375C51. There iszero or one 375C50 @languageCode 375C49 for each Catalogue entity375C43. The @currencyCode 375C52 is of type GDT CurrencyCode 375C54.There is zero or one 375C53 @currencyCode 375C52 for each Catalogueentity 375C43. The @unitCode375C55 is of type GDT MeasureUnitCode375C57. There is zero or one 375C56 @unitCode375C55 for each Catalogueentity 375C43. The ID 375C58 is of type GDT CatalogueID 375C60. There isone 375C59 ID 375C58 for each Catalogue entity 375C43.

The Content package 375C61 includes a CatalogItem package 375C76 and aCatalogView package 375C60A. The Content package 375C61 includes aContent entity 375C62 at the forth level 375C04. The Content package375C61 is of type GDTCataloguePublicationTransmissionContentChangeRequestCatalogueContent375C64. There is one 375C44 Content package 375C61 for eachCataloguePublicationTransmission entity 375C36. The Catalogue entity375C43 includes a @catalogueItemListComplete TransmissionIndicator375C65, a @catalogueItemRelationshipListCompleteTransmissionIndicator375C68, a @catalogueViewListCompleteTransmissionIndicator 375C71, and aCatalogueSchemaID 375C74 at the fifth level 375C05. The@catalogueItemListCompleteTransmissionIndicator 375C65 is of type GDTCompleteTransmissionIndicator 375C67. There is one 375C66@catalogueItemListComplete TransmissionIndicator 375C65 for eachCatalogue entity 375C43. The@catalogueItemRelationshipListCompleteTransmissionIndicator 375C68 is oftype GDT CompleteTransmissionIndicator 375C70. There is zero or one375C69 @catalogueItemRelationshipListCompleteTransmissionIndicator375C68 for each Catalogue entity 375C43. The@catalogueViewListCompleteTransmissionIndicator 375C71 is of type GDTCompleteTransmissionIndicator 375C73. There is zero or one 375C72@catalogueViewListCompleteTransmissionIndicator 375C71 for eachCatalogue entity 375C43. The CatalogueSchemaID 375C74 is of type GDTCatalogueSchemaID 375C76. There is zero or one 375C75 CatalogueSchemaID375C74 for each Catalogue entity 375C43

The CatalogItem package 375C76 includes a CatalogueItem 375C78, and aCatalogueRelationship 375C45A at the fifth level 375C05. TheCatalogueItem 375C78 includes a @actionCode 375C81, a@propertyValuationListCompleteTransmissionIndicator 375C84, an ID375C87,a Description 375C90, a Classification 375C93, and a PropertyValuation375C02A. The @actionCode 375C81 is of type GDT ActionCode 375C83. Thereis zero or one 375C82 @actionCode 375C81 for each Catalogue entity375C43. The @propertyValuationListCompleteTransmissionIndicator 375C84is of type GDT CompleteTransmissionIndicator 375C86. There is zero orone 375C85 @propertyValuationListCompleteTransmissionIndicator 375C84for each Catalogue entity 375C43. The ID 375C87 is of type GDTCatalogueItemID 375C89. There is one 375C88 ID375C87 for each ID entity375C87. The Description 375C90 is of type GDTCatalogueItemClassification 375C95. There is zero to n 375C94Description 375C90 for each each Catalogue entity 375C43. TheClassification 375C93 is of type GDT CatalogueItemClassification 375C95.There is zero to n 375C94 Classification 375C93 for each each Catalogueentity 375C43.

The Classification 375C93 includes a CatalogueSchemaID 375C96 and aCatalogueSectionID 375C99 at the seventh level 375C07. TheCatalogueSchemaID 375C96 is of type GDT CatalogueSchemaID 375C98. Thereis zero to n 375C74 CatalogueSchemaID 375C96 for each each Catalogueentity 375C43. The CatalogueSectionID 375C99 is of type GDTCatalogueSectionID375COlA. There is one 375C00A CatalogueSectionID375C99 for each each Catalogue entity 375C43.

The PropertyValuation 375C02A includes an @actionCode 375C05A, aPropertyReference 375C08A, and a ValueGroup 375C14A at the seventh level375C07. The PropertyValuation 375C02A is of type GDT PropertyValuation375C04A. There is zero or n 375C03A PropertyValuation 375C02A for eachCatalogue entity 375C43. The @actionCode 375C05A is of type GDTActionCode 375C07A. There is zero or one 375C06A @actionCode 375C05A foreach Catalogue entity 375C43. The PropertyReference 375C08A is of typeGDT PropertyReference 375C10A. There is one 375C09A PropertyReference375C08A for each Catalogue entity 375C43. The PropertyReference 375C08Aincludes an ID 375C11A at the eight level 36708. The ID 375C11A isoftype GDT PropertyID 375C13A. There is one 375C012A ID 375C11A for eachCatalogue entity 375C43.

The ValueGroup 375C14A includes an ID 375C17A, a ParentID 375C20A, anOrdinalNumberValue 375C23A and a Property Value 375C26A at level eight375C08. The ValueGroup 375C14A is of type GDT PropertyValuelterator375C16A. There is one 375C012A ValueGroup 375C14A for each Catalogueentity 375C43. The ID 375C17A is of type GDT Identifier375Cl9A. There iszero to one 375C018A ID 375C17A for each Catalogue entity 375C43. TheParentID 375C20A is of type GDT Identifier 375C22A. There is zero to one375C21A ParentID 375C20A for each Catalogue entity 375C43. TheOrdinalNumberValue 375C23A is of type GDT OrdinalNumberValue 375C25A.There is zero to one 375C24A OrdinalNumberValue 375C23A for eachCatalogue entity 375C43. The Property Value 375C26A is of type GDTProperty Value 375C28A. There is zero to n 375C027A Property Value375C26A for each Catalogue entity 375C43.

The Property Value 375C26A includes a AmountSpecification 375C29A, aQuantitySpecification 375C31A, a DecimalSpecification 375C33A, aFloatSpecification 375C35A, an IntegerSpecification 375C37A,DateTimeSpecification 375C39A, a NameSpecification 375C41A, and aIndicatorSpecification 375C43A at level nine 375C09. TheAmountSpecification 375C29A is of type GDT Property Value 375C28A andthere is zero to 1 375C027A for each Catalogue entity 375C43. TheQuantitySpecification 375C31A is of type GDT Property Value 375C28A andthere is zero to 1 375C027A for each Catalogue entity 375C43. TheDecimalSpecification 375C33A is of type GDT Property Value 375C28A andthere is zero to 1 375C027A for each Catalogue entity 375C43. TheFloatSpecification 375C35A is of type GDT Property Value 375C28A andthere is zero to 1 375C027A for each Catalogue entity 375C43. TheIntegerSpecification 375C37A is of type GDT Property Value 375C28A andthere is zero to 1 375C027A for each Catalogue entity 375C43. TheDateTimeSpecification 375C39A is of type GDT Property Value 375C28A andthere is zero to 1 375C027A for each Catalogue entity 375C43. TheNameSpecification 375C41A is of type GDT Property Value 375C28A andthere is zero to 1 375C027A for each Catalogue entity 375C43. TheIndicatorSpecification 375C43A is of type GDT Property Value 375C28A andthere is zero to 1 375C027A for each Catalogue entity 375C43. TheProperty Value 375C26A is of type GDT Property Value 375C28A. There iszero to n 375C027A Property Value 375C26A for each Catalogue entity375C43.

The CatalogueItemRelationship 375C45A includes an @actionCode 375C48A, aSourceDatalogueItem 375C51A, a TargetCatalogueItemID 375C54A, and aTypeCode 375C57A at level 6 375C06. The CatalogueItemRelationship375C45A is of type GDT CatalogueItemRelationship 375C47A. There is zeroto n 375C46A OrdinalNumberValue 375C23A for each Catalogue entity375C43. The @actionCode 375C48A is of type GDT ActionCode 375C50A. Thereis zero to n 375C49A @actionCode 375C48A for each Catalogue entity375C43. The SourceDatalogueItem 375C51A is of type GDTSourceDatalogueItem 375C53A. There is one 375C52A SourceDatalogueItem375C51A for each Catalogue entity 375C43. The TargetCatalogueItemID375C54A is of type GDT CatalogueItemID 375C56A. There is one 375C55ATargetCatalogueItemID 375C54A for each Catalogue entity 375C43. TheTypeCode 375C57A is of type GDTObjectStructureRelationshipTypeCode375C59A. There is one 375C58ATypeCode 375C57A for each Catalogue entity 375C43.

The CatalogueView 375C61A includes an @actionCode 375C64A, an@itemListCompleteTransmissionIndicator 375C67A, an ID 375C70A, a Name375C73A, and an Item 375C67A at level 6 375C06. The CatalogueView375C61A is of type GDTCataloguePublicationTransmissionContentChangeRequestCatalogueView375C63A. There is one to n 375C62A CatalogueView 375C61A for eachCatalogue entity 375C43. The @actionCode 375C64A is of type GDTActionCode 375C66A. There is zero to n 375C65A @actionCode 375C64A foreach CatalogueView 375C61A. The @itemListCompleteTransmissionIndicator375C67A is of type GDT CatalogueView 375C61A. There is zero to one375C69A @itemListCompleteTransmissionIndicator 375C67A for eachCatalogueView 375C61A. The ID 375C70A is of type GDT CatalogueViewID375C72A. There is one 375C71A ID 375C70A for each CatalogueView 375C61A.The Name 375C73A is of type GDT Name 375C75A. There is zero to n 375C74AName 375C73A for each CatalogueView 375C61A. The Item 375C67A is of typeGDT CatalogueViewItem 375C81A. There is zero ton 375C77A for eachCatalogueView 375C61A.

The Item 375C67A includes an @actionCode 375C79A and a CatalogueItemID375C82A at level 7. The Item 375C67A is of type GDTCatalogueViewItem375C78A. There is zero to n 375C77A Item 375C67A foreach Item 375C67A. The @actionCode 375C79A is of type GDT ActionCode375C81A. There is zero to one 375C80A @actionCode 375C79A for each Item375C67A. The CatalogueItemID 375C82A is of type GDT CatalogueItemID375C84A. There is one 375C83A CatalogueItemID 375C82A for each Item375C67A.

(14) Message Data Type Catalogue Publication Transmission Content ChangeConfirmation Message

The message data typeCataloguePublicationTransmissionContentChangeConfirmationMessageincludes the object CataloguePublicationTransmission in the viewrequired for theCataloguePublicationTransmissionContentChangeConfirmation informationconcerning the transmission of the object and the generalbusiness-related information relevant for sending the message.

The message data type contains the packages MessageHeader package375B04, TransmissionInformation package 375B06, andCataloguePublicationTransmission package 375B08. The message data typeCataloguePublicationTransmissionContentChangeConfirmationMessageprovides the structure for message typeCataloguePublicationTransmissionContentChangeConfirmation. This messageis the response to messageCataloguePublicationTransmissionContentChangeRequest 375B02.

(a) Message Header Package

In the Header Package 375B04, an element ReferenceID can be used, whichreferences the corresponding messageCataloguePublicationTransmissionContentChangeRequest, to which thismessage is the Confirmation. The MessageHeader package includes amessage header entity 375B12 and may include a SenderParty entity375B14.

(b) Transmission Information Package

The TransmissionInformation package 375B06 groups information pertainingto the transmission of the object (CataloguePublicationTransmission)contained in the message, and contains the entity TransmissionLog375B20, which can contain one or more of an Item entity 375B22.

(i) Transmission Log

A TransmissionLog 375B20 is a collection of events that occurred duringprocessing of the transmitted business document object. It can containthe entity TransmissionLogItem 375B22.

(ii) TransmissionLogItem

A TransmissionLogItem 375B22 is the information about an event thatoccurred during processing of the transmitted business document object.TransmissionLogItem 375B22 is of type GDT LogItem. TheMinimumRequestedLogItemSeverityCode stated in messageCataloguePublicationTransmissionContentChangeRequest determines whichLogItems are to be returned by specifying their severity.

(c) Catalogue Publication Transmission Package

The CataloguePublicationTransmission package 375B08 groups theCataloguePublicationTransmission with the package Catalogue 375B28.

(i) CataloguePublicationTransmission

A CataloguePublicationTransmission entity 375B30 in the view requiredfor CataloguePublicationTransmissionContentChangeConfirmation containsthe information that may be necessary to confirm whether single items ofthe catalogue contained in theCataloguePublicationTransmissionContentChangeRequest could be created,changed, or deleted. The entity CataloguePublicationTransmission 375B30contains the elements ID and ContentChangeCompletedIndicator.

ID can identify the Catalogue publication transmission of which itemswhere requested to be created, changed or deleted (GDT TransmissionID).ContentChangeCompletedIndicator can specify whether the items could becreated, changed, or deleted (GDTBusinessTransactionCompletedIndicator).

Also, the CataloguePublicationTransmission package 375B08 can containthe package Catalogue 375B28. The CataloguePublicationTransmissionshould be the same as in the corresponding messageCataloguePublicationTransmissionContentChangeRequest, to which thismessage is the Confirmation. Either all Items could be updated or none.

(ii) Catalogue Publication Transmission Catalogue Package

The CataloguePublicationTransmissionCatalogue Package 375B28 groups thecatalogue.

(iii) Catalogue

A Catalogue 375B32 in the view required forCataloguePublicationTransmissionContentChangeConfirmation can specifythe catalog of which the items have been updated. The Catalogue package375B28 contains the element CatalogueID, which can identify thecatalogue of the transmission of which the items could be created,updated, or deleted (GDT CatalogueID). The Catalogue 375B32 should bethe same as in the corresponding messageCataloguePublicationTransmissionContentChangeRequest, to which thismessage is the Confirmation.

(d) Message Data Type—Element Structure

FIGS. 375DA-B depict the element structure for aCataloguePublicationTransmissionContentChangeConfirmationMessage. Asshown in FIG. 375DA, the element structure identifies the differentpackages 375D00 that may be in a respectiveCataloguePublicationTransmissionContentChangeConfirmationMessage. Theelement structure for theCataloguePublicationTransmissionContentChangeConfirmationMessageincludes four levels L1 375D01, L2 375D02, L3 375D03, and L4 375D04 eachof which is associated with a respective package 375D00. The elementstructure identifies the occurrence or cardinality 375D05 and data typeinformation (i.e., name 375D06) for the elements at the respectivelevels 375D01, 375D02, 375D03, and 375D04.

The outermost package of this interface is aCataloguePublicationTransmissionContentChangeConfirmationMessage package375D07, which includes aCataloguePublicationTransmissionContentChangeConfirmationMessage entity375D08 at the first level 375D01. TheCataloguePublicationTransmissionContentChangeConfirmationMessage entity375D08 is of generic data type (“GDT”)CataloguePublicationTransmissionContentChangeConfirmationMessage 375D09.

The CataloguePublicationTransmissionContentChangeConfirmationMessagepackage 375D07 includes a MessageHeader package 375D10, aTransmissionInformation package 375D26, and aCataloguePublicationTransmission package 375D32. The MessageHeaderpackage 375D10 includes a MessageHeader entity 375D11 at the secondlevel 375D02, which is of type GDT BusinessDocumentMessageHeader 375D13.There is one 375D12 MessageHeader entity 375D11 for eachCataloguePublicationTransmissionContentChangeConfirmationMessage package375D07.

The MessageHeader entity 375D11 includes an ID 375D14, a Reference ID375D17, and a CreationDateTime 375D20 at the third level 375D03. The ID375D14 is of type GDT BusinessDocumentMessageID 375D16. There is one375D15 ID 375D19 for each MessageHeader entity 375D11. The Reference ID375D17 is of type GDT BusinessDocumentMessageID 375D19. There is one375D18 Reference ID 375D17 for each MessageHeader entity 375D11. TheCreationDateTime 375D20 is of type GDT DateTime 375D22. There is one375D21 CreationDateTime 375D20 for each MessageHeader entity 375D11.

The MessageHeader entity 375D11 also includes a SenderParty 375D23 atthe third level 375D03. The SenderParty 375D23 is of typeGD26BusinessDocumentMessageHeaderParty 375D25. There is one or zero375D24 SenderParty 375D23 for each MessageHeader entity 375D11.

The TransmissionInformation package 375D26 includes a TransmissionHeaderentity 375D27 at the second level 375D02. There is one or zero 375D26TransmissionHeader entity 375D27 for eachCataloguePublicationTransmissionContentChange ConfirmationMessage entity375D08. The TransmissionHeader 375D29 includes an Item 375D29 of typeGDT LogItem 375D31. There is one or more 375D30 Item 375D29 for eachTransmissionHeader entity 375D27.

The CataloguePublicationTransmission package 375D32 includes aCataloguePublicationTransmission entity 375D33 at the second level375D02. The CataloguePublicationTransmission entity 375D33 is of typeGDT CataloguePublicationTransmissionContentChangeConfirmationMessage.There is one 375D34 CataloguePublicationTransmission entity 375D33 foreach CataloguePublicationTransmissionContentChangeConfirmationMessageentity 375D08. The CataloguePublicationTransmission entity 375D33includes an ID 375D36 and a ContentChangeCompletedIndicator 375D39. TheID 375D36 is of type GDT TransmissionID 375D38. There is one 375D37 ID375D36 for each CataloguePublicationTransmission entity 375D33. TheContentChangeCompletedIndicator 375D39 is of type GDTBusinessTransactionCompletedIndicator375D41. There is one 375D40ContentChangeCompletedIndicator 375D39 for eachCataloguePublicationTransmission entity 375D33.

The CataloguePublicationTransmission package 375D32 further includes aCatalogue package 375D42. The Catalogue package 375D42 includes aCatalogue entity 375D43 at the third level 375D03. The Catalogue entity375D43 is of type GDT CatalogueContentChangeConfirmation 375D45. Thereis one 375D44 Catalogue entity 375D43 for eachCataloguePublicationTransmission entity 375D33.

The Catalogue entity 375D43 includes an ID 375D46. The ID 375D36 is oftype GDT CatalogueID 375D48. There is one 375D47 ID 375D47 for eachCataloguePublicationTransmission entity 375D33.

(15) An Application Catalog Content Management (CCM)

The context in which the exchange of Catalog data takes place can assistin understanding the Catalogue interfaces. An application CatalogContent Management (CCM) can be an ABAP Add-On built on an WebApplication Server (e.g., SAP's Web Application Server). The applicationcan contain the subcomponents a) a Catalog Authoring Tool (CAT), and b)a Catalog Search Engine (CSE).

FIG. 375BB shows the two CCM components CAT 375B36 and CSE 375B38, andhow the components relate to each other. CAT 375B36 and CSE 375B38 areindependent of each other, meaning that they can be replaced by asimilar component and still communicate with each other. This isprovided that the applications conform to a Catalog XML interface (e.g.,the SAP Catalog XML 1.0 interface) for communication. This XML-basedcommunication is facilitated by XI, regardless of the deploymentscenario.

(a) Catalog Authoring Tool (CAT)

CAT 375B36 enables a content manager to manage the structure andcontents of a Catalog. Structure refers to the categorization schemesused to classify items (such as products) in a Catalog. Management ofCatalog content entails tasks such as uploading an external Catalog,mapping the external categorization schemes into internal ones,enriching the Catalog with, say, images and text, and publishingapproved Catalog objects (such as sections and items) to CSE.

(b) Catalog Search Engine (CSE)

CSE 375B38 enables a Catalog user to navigate efficiently through apublished Catalog, access the desired information in the most efficientmanner and add the selected items to an external shopping cart. Inaddition, CSE 375B38 allows the publishing (replication) of an alreadypublished Catalog from one system to another.

g) Purchase Order Information Interfaces

The A2A PurchaseOrder interface is the interface that is used to informinterested applications about creating, changing, confirming, anddeleting a purchase order. From the perspective of thePurchaseOrderLegalDocument this interface is also used to transmitinformation for creation of a legal text document or to transmit thelegal text document itself.

Numerous complex processes exist that run in distributed systemlandscapes and that are dependent on information about purchase orders.Examples of these are planning processes that have to be informed of theamount of MRP-relevant products ordered and logistics processes thathave to be informed of expected goods receipts in good time. Thestandard system already provides for many of these processes, which arecovered by specialized messages. However, there will always becustomer-specific processes that are implemented at the project level.The PurchaseOrderInformation Interface serves as a generic interface forimplementing such customer-specific processes that depend on purchaseorder information. From the perspective of thePurchaseOrderLegalDocument, the PurchaseOrderInformation Interface alsooffers direct integration with a document management (specifically, thisis the application “Document Builder” that we shall refer to generallyfrom here on as Document Management). This generates a legal textdocument with corresponding legal clauses using the business dataframework of the purchase order and sends this as an attachment back tothe procurement system.

(1) Message Types

The PurchaseOrderInformation Interface combines the message typesPurchaseorderInformation, PurchaseOrderLegalDocumentRequest andPurchaseOrderLegalDocumentNotification. PurchaseOrderInformation isbased on the message data type PurchaseOrderInformationMessage whereasthe other two message types are based on the message data typePurchaseOrderLegalDocumentMessage. Both message data types have incommon that they contain the BusinessDocumentObject PurchaseOr-der inthe PurchaseOrderInformation perspective. This view contains all thepurchase order data that is required for A2A purchase order scenariossince a comprehensive transmission of purchase order information isdesirable.

(a) Message Type Purchase Order Information

PurchaseOrderInformation is the information from a procurement systemfor interested recipients about the status of a purchase order(PurchaseOrder). This includes purchase order changes, orderconfirmations, and order cancellations. The structure of thePurchaseOrderInformation message is the structure of thePurchaseOrderInformationMessage.

(b) Purchase Order Legal Document Request

A PurchaseOrderLegalDocumentRequest is the request from Purchasing toDocument Management to generate a legal text document from the purchaseorder. The message type PurchaseOrderLegalDocumentRequest can bepredetermined by the message data type PurchaseOrderLegalDocumentMessagewhich contains the object PurchaseOrder in the PurchaseOrderInformationview. A PurchaseOrderLegalDocumentRequest message can place a purchaseorder at the disposal of the Document Management System. In the DocumentManagement System enhancements are made and added in the form ofattachments. The business object purchase order remains unchanged instructure. The process ownership remains in the procurement system.

(c) PurchaseOrderLegalDocumentNotification

A PurchaseOrderLegalDocumentNotification is a notification from DocumentManagement to Purchasing with a legal text document for a PurchaseOrder.The message type PurchaseOrderLegalDocumentNotification can bepredetermined by the message data type PurchaseOrderLegalDocumentMessagewhich contains the object PurchaseOrder in the PurchaseOrderInformationview. A generated legal text document can be transmitted as structureelement LegalDocumentAttachment. The other structure elements of the MDTPurchaseOrderLegalDocumentMessage might not be used.

(2) Message Choreography

FIG. 376 shows the interaction between the represented Purchase OrderInformation interfaces in a contract process. The following messagechoreography describes the possible logical sequence of the messagesthat might be necessary to realize a scenario between a Sales server37600, a Purchasing server 37602, a Fulfillment Coordination server37604, a Supply Chain Planning server 37606, a Supply Chain Executionserver 37608, and a Document Management System server 37610.

A PurchaseOrderRequest message 37612 is sent from the Purchasing server37602 to the Sales server 37600. The PurchaseOrderRequest message 37612is a request from a purchaser to a seller to deliver goods or provideservices. A PurchaseOrderConfirmation message 37614 is sent from theSales server 37600 to the Purchasing server 37602. ThePurchaseOrderConfirmation message 37614 is a confirmation, partialconfirmation, or change from a seller to the purchaser, regarding therequested delivery of goods or provision of services. APurchaseOrderInformation message 37616 is sent from the Purchasingserver 37602 to the Fulfillment Coordination server 37604. ThePurchaseOrderInformation message 37616 is information from a purchasingsystem for interested recipients about the current state of a purchaseorder when creating or changing a purchase order, confirming a purchaseorder or canceling a purchase order. The PurchaseOrderInformationmessage 37616 can also be sent from the Fulfillment Coordination server37604 to the Supply Chain Planning server 37606.

A DeliveryExecutionRequest message 37618 is sent from the FulfillmentCoordination server 37604 to the Supply Chain Execution server 37608.The DeliveryExecutionRequest message 37618 is a request to a warehouseor supply chain execution to prepare and execute the outbound deliveryof goods or the acceptance of an expected or announced inbound delivery.Optionally, the DeliveryExecutionRequest message 37618 can be sent fromthe Purchasing server 37602 to the Supply Chain Execution server 37608.

A DeliveryInformation message 37620 is sent from the FulfillmentCoordination server 37604 to the Purchasing server 37602 and to theSupply Chain Planning server 37606. The DeliveryInformation message37620 is a message about the creation, change, and execution status of adelivery. A PurchaseOrderLegalDocumentRequest message 37622 is sent fromthe Purchasing server 37602 to the Document Management System server37610. The PurchaseOrderLegalDocumentRequest message 37622 is therequest from Purchasing to Document Management to generate a legal textdocument from the purchase order. APurchaseOrderLegalDocumentNotification message 37624 is sent from theDocument Management System server 37610 to the Purchasing server 37602.The PurchaseOrderLegalDocumentNotification message 37624 is thenotification from Document Management to Purchasing with a legal textdocument for a purchase order. The PurchaseOrderInformation message canbe sent regardless of the type of communication with the vendor, thatis, PurchaseOrderInformation is sent if the purchase order is sent tothe vendor by fax or if a pur-chase order is confirmed by e-mail andcreated manually in the procurement system on the user inter-face. Thecurrent purchase order status can be transmitted in full with everyPurchaseOrderInformation message. Data that has not been transmitted isimplicitly considered deleted. This is especially the case for itemsthat have not been transmitted.

The initiative for creation of the legal text document can come from thepurchaser (PurchaseOrderLegal-Document scenario). In some instances, alegal department is called on in parallel and with manual coordina-tion,to come up with the legal wording based on the business data frameworkof the purchase order. On agreement, the legal wording is signed and isusually filed as an unstructured text document on a file server. Thismanual process of coordination between a structured document in theprocurement system and a legal text document is being converted to asystem-integrated process by means of the messagesPurchaseOrderLegalDocumentRequest andPurchaseOrderLegalDocumentNotification.

In the framework of the purchase order process, Purchasing can send thecurrent status of the structured business document at certain times toDocument Management using the PurchaseOrderLegalDocumen-tRequest. Theconditions that trigger sending of the status are determined by theDocument Management user. Document Management then creates the legaltext document from the structured data framework. Here DocumentManagement can avail of predefined contract clauses and text passages inorder to make the legal department's internal process more efficient.The resulting legal text document is then returned to Purchasing in theform of an attachment with the PurchaseOrderLegalDocumentNotification,where the structure of the business object Purchase Order does notchange.

(a) Serializing Messages

All PurchaseOrderInformation messages can be sent exactly once in order(EOIO) and serialized using message queues. Each purchase order shouldhave its own message queue (as opposed to one queue for all purchaseorders) so that one failed message does not block all the otherPurchaseOrderInformation mes-sages in the entire system.

(b) Error Handling

In order to restart a process that is corrupt as a result of a failedmessage, the procurement system must provide an option for transmittingthe current status of a purchase order at any time using aPurchaseOr-derInformation message.

(c) Interfaces

The PurchaseOrderInformation messages can be implemented in theprocurement system by means of the following message interfaces:PurchaseOrderInformation_Out, PurchaseOrderLegalDocumentRequest_Out, andPurchaseOrderLegalDocumentNotification_In.

(3) Message Data Type Data Model—PurchaseOrderInformationMessage

FIG. 377 depicts the data model for the PurchaseOrderInformationMessage.The message data type PurchaseOrderInformationMessage groups togetherthe business information that is relevant for sending a businessdocument in a message and the PurchaseOrderInformation object in thebusiness document. It includes a PurchaseOrderInformationMessage package37700, which includes a PurchaseOrder package 37704 and aPurchaseOrderInformationMessage entity 37706. Optionally, aPurchaseOrderInformationMessage package 37700 includes a MessageHeaderpackage (not shown).

To ensure that the elements and entities in the message data typePurchaseOrderInformationMessage are used correctly with regard to theirchangeability in an ordering process, if it is specified that an elementor entity is not changed, changes might not permitted once the elementor entity has been created. The element or entity can be assigned a newvalue when a purchase order or a new item within a purchase order iscreated; this value can no longer be changed in other messages. Themessage data type PurchaseOrderInformationMessage makes the structureavailable for the message types PurchaseOrderInformation and therelevant interfaces.

Methods and systems consistent with the subject matter described hereinuse the package template for a BusinessTransactionDocument for an SCMMaster Data depicted in FIG. 270B to derive thePurchaseOrderInformationMessage interface. There is a 1:c relationshipbetween entities in this Interface unless otherwise noted herein orindicated in the Figures.

(a) Purchase Order Package

The PurchaseOrder package 37704 includes a Party package 37718, aLocation package 37720, a DeliveryInformation package 37722, aPaymentInformation package 37724, an Attachment package 37726, aDescription package 37728, a FollowUpMessage package 37730, an Itempackage 37732, and a PurchaseOrder entity 37734. There is a 1:1relationship between the PurchaseOrderInformationMessage entity 37706and the PurchaseOrder entity 37734.

(i) Purchase Order

The PurchaseOrder identifies the information about the status of apurchase order. This includes purchase order change, confirmation, orcancellation. The PurchaseOrder entity 37734 is divided intoPurchaseOrderItems that each specify an ordered product or additionalinformation relevant for such a product, such as information about billsof material (BOMs) or discount and value limits (seePurchaseOrderInformationItem package).

In addition to the buying party and the seller, additional parties maybe involved in the purchase order (see Party package). Locations may bespecified for the purchase order delivery (see Location package).Delivery and payment terms may also be agreed upon (seeDeliveryInformation package and PaymentInformation package).

Notes or references to attachments may be specified for the purchaseorder (see Description package and Attachment package). The types offollow-up documents that are expected may also be specified (seeFollowUpMessage package).

The PurchaseOrder entity 37734 is of type GDT: PurchaseOrderInformation.The PurchaseOrder entity 37734 includes an ID, a BuyerPostingDateTime, aBuyerLastChangeDateTime, and a Note. The ID is a unique identifierspecified by the buyer for the purchase order. The BuyerPostingDateTimeis the creation date/time of the purchase order at the buyer. TheBuyerPostingDateTime is of type GDT: DateTime. TheBuyerLastChangeDateTime is the date/time of the last change made to thepurchase order by the buyer. The BuyerLastChangeDateTime is of type GDT:DateTime. The Note is a short description or the title of the purchaseorder. It is generally used to provide the user with a simple method forsearching for a particular purchase order. The Note is of type GDT:Note.

Within any given purchase order, monetary amounts and prices aretypically in the same currency. Preferably, the ID will not change oncea purchase order has been created and the BuyerPostingDateTime will notchange once a purchase order has been created.

(ii) Purchase Order Party Package

The Party package 37718 groups together the business parties involved inthe purchase order. It includes a BuyerParty entity 37736, a SellerPartyentity 37738, a ProductRecipientParty entity 37740, a VendorParty entity37742, a ManufacturerParty entity 37744, a BillToParty entity 37746, aPayerParty entity 37748, and a CarrierParty entity 37750.

Either the ID or the ID and address may be transferred for each party.If the ID is transferred, the ID address defined in the master data isused. If the ID and address are transferred, the ID identifies the partyand the address is deemed to be a document address that is differentfrom the master data address. A default logic is used for the partiesfrom the header to the items and within item hierarchies. Partiesspecified in the header are used for the items for which a correspondingparty is not explicitly transferred and that are directly assigned tothe header. In accordance with the same logic, parties transferred atthe item level are used for the subitems assigned to the relevant itemin an item hierarchy. The default logic is used for the party as awhole, including the contact person. Parts of a party specified at theheader level or for a hierarchy item should not be specified in moredetail at the item level. The default logic is a simplified version ofthe transferred message. As regards logic, parties at the header leveland for hierarchy items behave as if they have been explicitlytransferred for the subitems of the message.

(a) Buyer Party

The BuyerParty is a party that buys goods or services. The BuyerPartyentity 37736 is of type GDT: BusinessTransactionParty. The sameBuyerParty may be used for all of the items in a purchase order. TheBuyerParty typically does not change once a purchase order has beencreated. The BuyerParty should typically be specified.

Changes can be made to the BuyerParty/Contact, and a differentBuyerParty/Contact is permitted for each item. Changes can be made tothe address of the BuyerParty, but different addresses should not bepermitted for each item. If a ProductRecipientParty is not specified inthe ordering process, the BuyerParty may also be used as theProductRecipientParty. If a ProductRecipientParty and ShipToLocation arenot specified in the ordering process, the BuyerParty address may beused as the ship-to address. If a BillToParty is not specified in theordering process, the BuyerParty may also be used as the BillToParty. Ifa BillToParty and PayerParty are not specified in the ordering process,the BuyerParty may also be used as the PayerParty.

(b) Seller Party

The SellerParty is a party that sells goods or services. The SellerPartyentity 37738 is of type GDT: BusinessTransactionDocumentParty. The sameSeller Party may be used for the items in a purchase order. The SellerParty should not be changed once a purchase order has been created. TheSeller Party should typically be specified.

Changes can be made to the SellerParty/Contact and a differentSellerParty/Contact is permitted for each item. Changes can be made tothe address of the Seller Party, but different addresses should not bepermitted for each item. If a VendorParty is not specified in theordering process, the Seller Party may also be used as the VendorParty.If a VendorParty and ShipFromLocation are not specified in the orderingprocess, the address of the SellerParty may also be used as theship-from address for the material items.

(c) Product Recipient Party

The ProductRecipientParty is a party to which goods are delivered or forwhom services are provided. The ProductRecipientParty entity 37740 is oftype GDT: BusinessTransactionDocumentParty. The ProductRecipientPartyentity 37740 includes the same type of information as the BuyerPartyentity 37736.

If a ShipToLocation is not explicitly specified in the ordering process,the ProductRecipientParty address may be used as the ship-to address.The ProductRecipientParty is not synonymous with the ShipToLocation andshould be used when the ProductRecipientParty (company or person) isdifferent than the BuyerParty.

(d) Vendor Party

The VendorParty is a party that delivers goods or provides services. TheVendorParty entity 37742 is of type GDT:BusinessTransactionDocumentParty. The VendorParty entity 37742 includesthe same type of information as the BuyerParty entity 37736.

If a ShipFromLocation is not specified in the ordering process, theaddress of the VendorParty may be used as the ship-from address for thematerial items. The VendorParty is not the company or person that issolely responsible for transporting the goods. Rather, the CarrierPartyis responsible for this. The VendorParty is not synonymous with theShipFromLocation and should be used when the VendorParty (company orperson) is different than the SellerParty.

(e) Manufacturer Party

The ManufacturerParty is a party that manufactures goods. TheManufacturerParty entity 37744 is of type GDT:BusinessTransactionDocumentParty. The ManufacturerParty entity 37744includes the same type of information as the BuyerParty entity 37736.

The ManufacturerParty entity 37744 may be used for material items. Thedefault logic (from header to item to subitems) is used for materialitems. For other items, the ManufacturerParty is typically ignored. TheManufacturerParty can be used to uniquely define the context of aManufacturerProductID.

(f) Bill To Party

The BillToParty is a party to which the invoice for goods or services issent. The BillToParty entity 37746 is of type GDT:BusinessTransactionDocumentParty. The BillToParty entity 37746 includesthe same type of information as the BuyerParty entity 37736.

If a PayerParty is not specified in the ordering process, theBillToParty may also be used as the PayerParty. Conversely, theBillToParty may not be explicitly derived from the PayerParty.

(g) Payer Party

The PayerParty is a party that pays for goods or services. ThePayerParty entity 37748 is of type GDT:BusinessTransactionDocumentParty. The PayerParty entity 37748 includesthe same type of information as the BuyerParty entity 37736.

(h) Carrier Party

The CarrierParty is a party that transports goods. The CarrierPartyentity 37750 is of type GDT: BusinessTransactionDocumentParty. TheCarrierParty entity 37750 includes the same type of information as theBuyerParty entity 37736.

The CarrierParty can be used for material items. The default logic (fromheader to item to subitems) is typically used for material items.

(iii) Purchase Order Location Package

The Location package 37720 groups together the locations relevant forthe purchase order. It includes a ShipToLocation entity 37792 and aShipFromLocation entity 37794.

A similar default logic to that used for Parties is also used forlocations. Either the ID or the address, or both can be transferred toeach location. If the ID is transferred, the ID address defined in themaster data is used. If the address is transferred, it is this addressthat is used (if necessary, a location is assigned at the addressrecipient). If the ID and address are transferred, the ID identifies thelocation and the address is deemed to be a document address that isdifferent to the master data address.

(a) Ship To Location

The ShipToLocation is the location to which goods are to be delivered orwhere services are to be provided. The ShipToLocation entity 37792 is oftype GDT: BusinessTransactionDocumentLocation.

(b) Ship From Location

The ShipFromLocation is the location from which goods are to be shipped.The ShipFromLocation entity 37794 is of type GDT:BusinessTransactionDocumentLocation. The ShipFromLocation entity 37794may be used for material items. The default logic (from header to itemto subitems) is typically used for material items. For the other items,the ShipFromLocation may be ignored.

(iv) Purchase Order Delivery Information Package

The DeliveryInformation package 37722 groups together the informationfor a delivery required for a purchase order. The DeliveryInformationpackage 37722 includes a DeliveryTerms entity 37710A. A similar defaultlogic to that used for Parties is also used for DeliveryTerms.

The DeliveryTerms entity 37710A includes an Incoterms entity 37712A, aPartialDelivery entity 37714A, a QuantityTolerance entity 37716A, aTransport entity 37718A, and a Description entity 37720A.

The DeliveryTerms are the conditions and agreements that are valid forexecuting the delivery and transporting the ordered goods and for thenecessary services and activities. The DeliveryTerms entity 37710A is oftype GDT: DeliveryTerms. Within the DeliveryTerms, the Incoterms and thetransport may be used for material items.

(v) Purchase Order Payment Information Package

The PaymentInformation package 37724 groups together the paymentinformation about the purchase order. The PaymentInformation package37724 includes a CashDiscountTerms entity 37722A and a PaymentFormentity 37724A.

The CashDiscountTerms are the terms of payment in an ordering process.The CashDiscountTerms entity 37722A is of type GDT: CashDiscountTerms.The CashDiscountTerms entity 37722A includes a MaximumDiscount entity37726A and a NormaIDiscount entity 37728A.

The PaymentForm is the payment form together with the data required. ThePaymentForm entity 37724A includes a PaymentFormCode, which is the codedrepresentation of the payment form. The PaymentFormCode is of type GDT:PaymentFormCode. The PaymentForm entity 37724A also includes aPaymentCard entity 37730A. The PaymentCard entity 37730A is of type GDT:PaymentCard, and is a credit card or a customer card.

(vi) Purchase Order Attachment Package

The Attachment package 37726 groups together the attachment informationregarding the purchase order. It includes an Attachment entity 37732A,an AttachmentWebAddress entity 37734A, and aLegalDocumentAttachment37736A. There is a 1:cn relationship between thePurchaseOrder entity 37734 and the Attachment entity 37732A, and a 1:cnrelationship between the PurchaseOrder entity 37734 and theAttachmentWebAddress entity 37734A.

The Attachment 37732A is any document that refers to the purchase order.The Attachment entity 37732A is of type GDT: Attachment.

The AttachmentWebAddress 37734A identifies the address of a documentthat relates to the order. The document can be of any type. TheAttachmentWebAddress entity 37734A is of type GDT: AttachmentWebAddress.

LegalDocumentAttachment37736A is an attachment that contains the legalcontract text of the purchase order.

(vii) Purchase Order Description Package

The Description package 37728 groups together the texts regarding thepurchase order. The Description package37728 includes a Descriptionentity 37736A and an InternalDescription entity 37738A. There is a 1:crelationship between the PurchaseOrder entity 37734 and the Descriptionentity 37736A, and a 1:c relationship between the PurchaseOrder entity37734 and the InternalDescription entity 37738A.

The Description is a natural-language text regarding the purchase order,which is visible to business parties. The Description entity 37736A isof type GDT: Description. The Description can be used for the types oftextual information about the transferred purchase order and not justthe current message. An example of this would be information statingthat the Purchasing employee responsible is on vacation as of a specificdate, and indicating the name and telephone number of a substitute as ofthis date.

An InternalDescription is a natural-language text regarding the purchaseorder, which is not visible to business parties. The InternalDescriptionentity 37738A is of type GDT: Description.

(viii) Purchase Order Follow-Up Message Package

The FollowUpMessage package 37730 groups together the information aboutsubsequent messages that the buyer expects to receive from the sellerwith regard to the purchase order. The FollowUpMessage package 37730includes a FollowUpPurchaseOrderConfirmation entity 37740A, aFollowUpDespatchedDeliveryNotification entity 37742A, aFollowUpServiceAcknowledgementRequest entity 37744A, and aFollowUpInvoiceRequest entity 37746A. There is a respective 1:crelationship between the PurchaseOrder entity 37734 and theFollowUpPurchaseOrderConfirmation entity 37740A, theFollowUpDespatchedDeliveryNotification entity 37742A, theFollowUpServiceAcknowledgementRequest entity 37744A, and theFollowUpInvoiceRequest entity 37746A.

The FollowUpPurchaseOrderConfirmation identifies information aboutwhether and in what form the buyer expects to receive confirmation ofthe purchase order from the seller. TheFollowUpPurchaseOrderConfirmation entity 37740A includes aRequirementCode, which is a coded representation of information aboutwhether the buyer expects to receive confirmation of the purchase orderfrom the seller. The RequirementCode is of type GDT:FollowUpMessageRequirementCode. The RequirementCode may have the values“02” (Expected) and “04” (Unexpected).

The FollowUpDespatchedDeliveryNotification identifies information aboutwhether the buyer wants to be informed by the seller of any outbounddeliveries. The FollowUpDespatchedDeliveryNotification entity 37742Aincludes a RequirementCode, which is a coded representation ofinformation about whether the buyer expects the seller to sendnotification of any outbound deliveries of the ordered goods. TheRequirementCode is of type GDT: FollowUpMessageRequirementCode. TheRequirementCode may have the values “02” (Expected) and “04”(Unexpected).

The FollowUpServiceAcknowledgementRequest identifies information aboutwhether the buyer wants to be informed by the seller of any servicesprovided. The FollowUpServiceAcknowledgementRequest entity 37744Aincludes a RequirementCode, which is a coded representation ofinformation about whether the buyer wants to be informed by the sellerof any services provided. The RequirementCode is of type GDT:FollowUpMessageRequirementCode. The RequirementCode may have the values“02” (Expected) and “04” (Unexpected). The RequirementCode may bechanged by the buyer. If the buyer changes the RequirementCode from“Unexpected” to “Expected” during an ordering process, the seller shouldinform the buyer of the new services provided once the change has beenreceived. If the buyer changes the RequirementCode from “Expected” to“Unexpected,” the seller should not send any further information aboutservices provided. The seller can transfer the confirmation of theservices either electronically using a ServiceAcknowledgementRequestmessage or by traditional methods of communication, such as e-mail orfax. In addition to service items, a confirmation of a service also cancontain planned or unplanned material items for materials that wererequired when the service was provided.

The FollowUpInvoiceRequest identifies information about whether thebuyer expects to receive an invoice from the seller. TheFollowUpInvoiceRequest entity 37746A includes a RequirementCode and anEvaluatedReceiptSettlementIndicator. The RequirementCode is a codedrepresentation of information about whether the buyer expects to receivean invoice from the seller. The RequirementCode is of type GDT:FollowUpMessageRequirementCode. The EvaluatedReceiptSettlementIndicatorindicates whether or not the purchase order settlement is to beprocessed automatically by the goods receipt, without an invoice. TheEvaluatedReceiptSettlementIndicator is of type GDT:EvaluatedReceiptSettlementIndicator. The RequirementCode may have thevalues “01” (Required) and “05” (Forbidden). If theEvaluatedReceiptSettlementIndicator is set to “true,” theRequirementCode should be set to “Forbidden.”

(ix) Purchase Order Item Package

The PurchaseOrderItem package 37732 includes a ScheduleLine package37748A, a ProductInformation package 37750A, a PriceInformation package37752A, a Party package 37754A, a Location package 37756A, aDeliveryInformation package 37758A, aBusinessTransactionDocumentReference package 37760A, an Attachmentpackage 37762A, a Description package 37764A, and a PurchaseOrderItementity 37766A. There is a 1:cn relationship between the PurchaseOrderentity 37734 and the PurchaseOrderItem entity 37766A. Items are arrangedhierarchically using a Hierarchy Relationship 37768A. The HierarchyRelationship 37768A is the relationship between a sub-item and ahigher-level parent item in an item hierarchy. There is a 1:cnrelationship between the Item entity 37766A and its subordinateentities, and a 1:c relationship between the Item entity 37766A and itssuperordinate entities.

(a) Purchase Order Item

The PurchaseOrderItem specifies a product ordered by the purchase orderor additional information about ordered products. This informationincludes specifications on discounts in kind, substitute products, andvalue limits. The PurchaseOrderItem entity 37766A includes detailedinformation about a particular product (see Product package) and itsprice (see PriceInformation package). The quantities of the product and(delivery) dates are specified in the schedule line (see ScheduleLinepackage).

For the PurchaseOrderItem entity 37766A (compared to the information ofthe PurchaseOrder), deviating parties, locations, and delivery terms maybe defined (see Party package, Location package, and DeliveryInformationpackage). The PurchaseOrderItem entity 37766A may contain references toother business documents that are relevant for the item (seeBusinessTransactionDocumentReference package). Notes or references toattachments can also be specified for the PurchaseOrderItem (seeDescription package and Attachment package).

A PurchaseOrderItem entity 37766A can be subordinate to anotherPurchaseOrderItem within a hierarchy to represent a businessrelationship between the two items. This could be information about adiscount in kind or substitute product for an ordered product, forexample. This relationship can also be used to group together purchaseorder items, that is, a PurchaseOrderItem can group together otherPurchaseOrderItems. The PurchaseOrderItem 37766A is of type GDT:PurchaseOrderItem.

The PurchaseOrderItem entity 37766A includes the elments ID andConfirmedInformationOutdatedIndicator.

The ID elment is the ID is the identifier assigned by the buyer to apurchase order item and is of type GDT:BusinessTransactionDocumentItemID. The identifier is unique within aparticular purchase order and is of type GDT:BusinessTransactionDocumentItemID. AConfirmedInformationOutdatedIndicator indicates whether the confirmationinformation Con-firmedPrice and ConfirmedScheduleLine transmitted withthe item refers to the current purchase order status or whether it isoutdated because changes have been made to the purchase order.ConfirmedInformationOutdatedIndicator is of type GDT:InformationOutdatedIndicator.

In one implementation and with respect to the Message Data Type, the IDelement must not be changed once an item has been created; the SellerIDelement must not be changed once an item has been created; and theUnplannedItemPermissionCode element must not be changed once an item hasbeen created.

In one implementation and with respect to the Message TypePurchaseOrderRequest, the SellerID must not be used; theAcceptanceStatusCode must not be used; and theUnconfirmedQuantityCanceledIndicator must not be used.

In one implementation and with respect to the Message TypePurchaseOrderChangeRequest, the AcceptanceStatusCode must not be usedand the UnconfirmedQuantityCanceledIndicator must not be used.

From a semantic point of view, items can contain other items. Thisenables item hierarchies to be mapped. From a technical point of view,the item type is not defined recursively, since this cannot be handledby some commonly-used XML tools. The hierarchies are mapped using theentity HierarchyRelationship. There are various item categories, whichare governed by a variety of constraints. An item can have severalconstraint types. In this case, the item satisfies the constraints ofits constraint types. Which constraint types can be combined with oneanother and how is specified in the description of the constraint types.The following constraint types exist: (1) Standard items are the itemsto which no lower-level items have been assigned in the hierarchy. Anitem that is not referenced by another item, using the ParentItemID is astandard item; (2) Hierarchy items are items to which at least one otherlower-level item has been assigned in the hierarchy. An item that isreferenced by at least one other item, using the ParentItemID is ahierarchy item. Items are typically either standard or hierarchy items;(3) Subitems are items that have been assigned below a hierarchy itemand not directly to the purchase order header. Subitems can be bothstandard items and hierarchy items. A subitem is an item that referencesanother item using the ParentItemID; (4) Material items are items whoseproduct is a material. Items whose ProductTypeCode is “1” (Material) arematerial items; (5) Service items are items whose product is a service.Items whose ProductTypeCode is “2” (Service) are service items; (6)Unspecified product items are items for which it is not specifiedwhether they refer to a material or a service. Items whoseProductTypeCode is not specified are unspecified product items. Itemsare material, service, or unspecified product items. An unspecifiedproduct item satisfies the constraints of a material, service, or limititem; (7) Grouping hierarchy items are hierarchy items that logicallygroup together other items. Multilevel grouping hierarchies arepermitted, that is, a grouping hierarchy item can contain subitems thatare also grouping hierarchy items. Hierarchy items whose subitems haveHierarchyRelationshipTypeCode “002” (Group) are grouping hierarchyitems; subitems with a different HierarchyRelationshipTypeCode are notpermitted. Grouping hierarchy items are not permitted to be subitems ofother types of hierarchy items; (8) Substitute product hierarchy itemsare hierarchy items for which at least one subitem with a substituteproduct exists. Multilevel substitute product hierarchies are notpermitted, that is, a substitute product cannot be substituted.Hierarchy items whose subitems have HierarchyRelationshipTypeCode “006”(Substitute Product) are substitute product hierarchy items; subitemswith a different HierarchyRelationshipTypeCode are not permitted.Substitute product hierarchy items can be used as subitems in groupinghierarchies. Substitute product subitems can be transferred in thePurchaseOrderConfirmation message. The buyer can reject proposedsubstitute products by cancelling the entire associated substituteproduct hierarchy item; (9) BOM hierarchy items are hierarchy items thatgroup together other items in a BOM. Multilevel BOM hierarchies arepermitted. Hierarchy items with at least one subitem withHierarchyRelationshipTypeCode “001” (Bill of Material) are BOM hierarchyitems; additional subitems are permitted with theHierarchyRelationshipTypeCode “003” (Discount in Kind); (10) Discount inkind hierarchy items are hierarchy items for which a goods discount isgranted in the form of an inclusive or exclusive bonus quantity.

Multilevel discount in kind hierarchies are not permitted, that is, nodiscount in kind can be granted for discount in kind. The goods discountis described in the form of one or more subitems in the discount in kindhierarchy item. Hierarchy items with at least one subitem withHierarchyRelationshipTypeCode “003” (Discount in Kind) are discount inkind hierarchy items; additional subitems are permitted with theHierarchyRelationshipTypeCode “001” (Bill of Material). Hierarchy itemsare grouping, BOM, or discount in kind hierarchy items. A hierarchy itemcan be both a BOM and discount in kind hierarchy item, if a discount inkind has been granted for a BOM; (11) Limit items are both standard andunspecified product items for which the exact requirements are unknownat the time of ordering. Items with a ProcurementCostUpperLimit arelimit items. Limit items are not permitted to be subitems of BOM ordiscount in kind hierarchy items. No substitute product subitems arepermitted for limit items. Dependencies between elements or entities ofthis item category are described under “Notes” for the relevant elementor entity.

The PurchaseOrderItem contains the HierarchyRelationship entity.

(b) Hierarchy Relationship

A HierarchyRelationship is the relationship between a subitem and ahigher-level parent item in an item hierarchy. The HierarchyRelationship37768A includes a ParentItemID and a TypeCode. The ParentItemID is thereference to the parent item with the item number assigned by the buyer.The ParentItemID is of type GDT: BusinessTransactionDocumentItemID. TheTypeCode represents the hierarchical relationship between the subitemand its higher-level parent item. The TypeCode is of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode. TheParentItemID and the TypeCode typically do not changed once an item hasbeen created.

(c) Purchase Order Item Product Information Package

The ProductInformation package 37750A groups together the informationfor identifying, describing, and classifying a product in an orderingprocess. It includes a Product entity 37770A and a ProductCategoryentity 37772A. There is a 1:c relationship between the PurchaseOrderItementity 37766A and the Product entity 37770A, and a 1:c relationshipbetween the PurchaseOrderItem entity 37766A and the ProductCategoryentity 37772A. The product package is not used in grouping hierarchyitems.

The Product includes the details about a product as generally understoodfrom a commercial point of view in business documents. These are thedetails for identifying a product and product type, and the descriptionof the product. The Product entity 37770A is of type GDT:BusinessTransactionDocumentProduct. For limit items, the description(Note) can be used in the Product entity 37770A. The product number andProductTypeCode are typically not used. The ProductTypeCode typicallydoes not change once an item has been created. With the exception ofgrouping hierarchy items, at least the product number or the productdescription (Note) is specified when a new item is created. If both theproduct number and description are specified, the description isadditional information in the message and can typically be ignored bythe recipient. In substitute product subitems, the ProductTypeCode isthe same as the parent item ProductTypeCode. In substitute productsubitems, the product is the substitute product proposed by the vendorfor the product ordered in the associated substitute product hierarchyitem.

The ProductCategory includes the details about a product category asgenerally understood from a commercial point of view in businesstransaction documents. It includes details for identifying the productcategory using an internal ID, a standard ID, and IDs assigned byinvolved parties. The ProductCategory entity 37772A is of type GDT:BusinessTransactionDocumentProductCategory.

(d) Purchase Order Item Price Information Package

The PriceInformation package 37752A groups together the priceinformation in an order item. The Price package includes a Price entity37774A, a ConfirmedPrice entity 37776A, and a ProcurementCostUpperLimitentity 37778A. There is a respective 1:c relationship between thePurchaseOrderItem entity 37766A and the Price entity 37774A, theConfirmedPrice entity 37776A, and the ProcurementCostUpperLimit entity37778A.

The Price is typically not used in grouping hierarchy and discount inkind items. The ProcurementCostUpperLimit is typically used for limititems, whereas the Price and the Confirmed Price are typically not used.The ProcurementCostUpperLimit is typically not used for any items otherthan limit items. The PriceInformation package 37752A for a purchaseorder item includes prices; it typically does not contain anyinformation about how the prices are calculated (pricing scales, and soon).

(i) Price

The Price is the order price specified by the buyer. The Price entity37774A includes a NetUnitPrice, which is the net price specified by thebuyer for the base quantity (without tax or cash discount) of theproduct. The NetUnitPrice is of type GDT: Price. The Price entity 37774Aalso includes a NetAmount, which is an amount specified by the buyer forthe ordered products without taxes and without cash discount. TheNetAmount is of type GDT: Amount.

In BOM hierarchies: (1) if the price is specified for the item at thetop of the BOM hierarchy and not for the subitems, this price applies;(2) if the price is specified for standard items (end nodes in thehierarchy tree) in the BOM hierarchy, these prices apply, where theprice of the entire BOM is the total of the individual prices; and (3)if a price is specified at different levels in the BOM hierarchy, theprice that appears above the others in the tree applies. Differencesbetween the total of the individual prices and the price at the nexthighest hierarchy level are permissible. These may be caused bydiscounts for the entire BOM. In substitute product subitems, the Pricecan be used to transfer substitute product prices. The same rules applyhere as for the Price in BOM hierarchies.

(ii) Confirmed Price

The ConfirmedPrice is the purchase order price confirmed by the seller.The ConfirmedPrice entity 37776A includes a NetUnitPrice, which is thenet price (without tax or cash discount) confirmed by the seller for thebase quantity of the product. The NetUnitPrice is of type GDT: Price. InBOM and substitute product hierarchies, the same rules apply for theConfirmedPrice as for the Price.

(e) Purchase Order Item Party Package

The PurchaseOrderItemParty Package 37754A is similar to the Partypackage 37718 at the header level. The PurchaseOrderItemParty Package37754A includes a BuyerParty entity 37780A, a SellerParty entity 37782A,a ProductRecipientParty entity 37784A, a VendorParty entity 37786A, aManufacturerParty entity 37788A, a BillToParty entity 37790A, aPayerParty entity 37792A, and a CarrierParty entity 37794A. There is arespective 1:c relationship between the PurchaseOrderItem entity 37766Aand the BuyerParty entity 37780A, the SellerParty entity 37782A, theProductRecipientParty entity 37784A, the VendorParty entity 37786A, theManufacturerParty entity 37788A, the BillToParty entity 37790A, thePayerParty entity 37792A, and the CarrierParty entity 37794A. Each ofthe BuyerParty entity 37780A, the SellerParty entity 37782A, theProductRecipientParty entity 37784A, the VendorParty entity 37786A, theManufacturerParty entity 37788A, the BillToParty entity 37790A, thePayerParty entity 37792A, and the CarrierParty entity 37794A includesthe same type of information as the BuyerParty entity 37736 above.

(f) Purchase Order Item Location Package

The PurchaseOrderItemLocation Package 37756A is similar to the Locationpackage 37722 at the header level. The PurchaseOrderItemLocation Package37756A includes a ShipToLocation entity 37712B and a ShipFromLocationentity 37714B. There is a 1:c relationship between the PurchaseOrderItementity 37766A and the ShipToLocation entity 37712B, and there is a 1:crelationship between the PurchaseOrderItem entity 37766A and theShipFromLocation entity 37714B. The ShipToLocation entity 37712B and theShipFromLocation entity 37714B include the same type of information asthe ShipToLocation entity 37792.

(g) Purchase Order Item Delivery Information Package

The PurchaseOrderDeliveryInformation Package 37758A is similar to theDeliveryInformation package 37722 at the header level. ThePurchaseOrderDeliveryLocation Package 37758A includes DeliveryTermsentity 37720B. There is a 1:c relationship between the PurchaseOrderItementity 37766A and the DeliveryTerms entity 37720B.

The DeliveryTerms entity 37720B includes an Incoterms entity 37722B, aPartialDelivery entity 37724B, a QuantityTolerance entity 37726B, aTransport entity 37728B, and a Description entity 37730B. There is a 1:crelationship between the DeliveryTerms entity 37720B and the Incotermsentity 37722B. There is a 1:c relationship between the DeliveryTermsentity 37720B and the PartialDelivery entity 37724B. There is a 1:crelationship between the DeliveryTerms entity 37720B and theQuantityTolerance entity 37726B. There is a 1:c relationship between theDeliveryTerms entity 37720B and the Transport entity 37728B. There is a1:c relationship between the DeliveryTerms entity 37720B and theDescription entity 37730B.

(h) Purchase Order Item Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 37760A groups togetherthe references to business documents that are relevant for thePurchaseOrderItem and have a business relationship with the item. TheBusinessTransactionDocumentReference package 37760A includes aQuoteReference entity 37732B, a PurchaseContractReference entity 37734B,an OriginPurchaseOrderReference entity 37736B, aBuyerProductCatalogueReference entity 37738B, and aSellerProductCatalogueReference entity 37740B. There is a respective 1:crelationship between the PurchaseOrderItem entity 37766A and theQuoteReference entity 37732B, the PurchaseContractReference entity37734B, the OriginPurchaseOrderReference entity 37736B, theBuyerProductCatalogueReference entity 37738B, and theSellerProductCatalogueReference entity 37740B. None of the entities inthe BusinessTransactionDocumentReference package 37760A should be usedin grouping hierarchy items.

Individual items in business documents should be referenced in thepurchase order messages from the item level. If an item assignment isnot recognized, an entire document can be referenced. In this case, therecipient cannot demand that the item numbers in both documents be thesame. It is the responsibility of the recipient to try to make thisassignment using other criteria that are not necessarily unique, such asthe product number. References are used for establishing relationshipsbetween different documents. If a reference has been provided, the datarelevant to the purchase order is transferred from the documentreferenced in the purchase order message (the product number in apurchase order item is transferred even if the product number can bederived directly from a bid reference). The data in the purchase ordermessage can differ in any number of ways from the referenced documents.The recipient is able to respond appropriately to such deviations.

A QuoteReference is a reference to a quotation or an item within aquotation. The QuoteReference entity 37732B is of type GDT:BusinessTransactionDocumentReference. The QuoteReference entity 37732Bmay reference one item, that is, one ItemID is permissible.

A PurchaseContractReference is a reference to a purchase contract oritem in a purchase contract. The PurchaseContractReference entity 37734Bis of type GDT: BusinessTransactionDocumentReference. In limit items,multiple contract references are possible; a maximum of one contractreference is permissible in other item types. APurchaseContractReference entity 37734B can reference one item, that is,one ItemID is permissible. Unless otherwise agreed, the seller isresponsible for determining the correct PurchaseContractReference for aspecified SellerContractReference.

An OriginPurchaseOrderReference is a reference to the origin purchaseorder or to an item within the origin purchase order in a third-partydeal. The OriginPurchaseOrderReference entity 37736B is of type GDT:BusinessTransactionDocumentReference. An OriginPurchaseOrderReferenceentity 37736B can reference one item, that is, one ItemID ispermissible. The OriginPurchaseOrderReference 37736B is used in thepurchase orders in a third-party deal, so that the seller can referencethe original purchase order of the ShipToParty with theOriginPurchaseOrderReference.

A BuyerProductCatalogueReference is a reference to the buyer's productcatalogue or an item within the buyer's product catalogue. TheBuyerProductCatalogueReference entity 37738B is of type GDT:CatalogueReference. A BuyerProductCatalogueReference entity 37738B canreference one item, that is, one ItemID is permissible. TheBuyerProductCatalogueReference entity 37738B should be filled if apurchase order item refers to a catalogue whose number and item numberswere assigned by the buyer. In the ordering process, theBuyerProductCatalogueReference can be used as a substitute productnumber if the product is defined in a catalogue rather than having itsown master record.

A SellerProductCatalogueReference is a reference to the seller's productcatalogue or an item within the seller's product catalogue. TheSellerProductCatalogueReference entity 37740B is of type GDT:CatalogueReference. A SellerProductCatalogueReference entity 37740B canreference one item, that is, one ItemID is permissible. TheSellerProductCatalogueReference entity 37740B should be filled if apurchase order item refers to a catalogue whose number and item numberswere assigned by the seller. In the ordering process, theSellerProductCatalogueReference can be used as a substitute productnumber if the product is defined in a catalogue rather than having itsown master record.

(i) Purchase Order Item Attachment Package

The PurchaseOrderItemAttachment Package is similar to the Attachmentpackage 37726 at the header level. The PurchaseOrderItemAttachmentPackage 37762A includes an Attachment entity 37742B and anAttachmentWebAddress entity 37744B. There is a 1:cn relationship betweenthe PurchaseOrderItem entity 37766A and the AttachmentWebAddress entity37744B, and a 1:cn relationship between the PurchaseOrderItem entity37766A and Attachment entity 37742B.

(j) Purchase Order Item Description Package

The PurchaseOrderItemDescription Package 37764A is similar to theDescription package 37728 at the header level. ThePurchaseOrderItemDescription Package 37764A includes a Descriptionentity 37746B and an InternalDescription entity 37748B. There is a 1:crelationship between the PurchaseOrderItem entity 37766A and theDescription entity 37746B, and a 1:c relationship between thePurchaseOrderItem entity 37766A and the InternalDescription entity37748B.

(k) Purchase Order Item Schedule Line Package

A ScheduleLine package 37748A groups together the quantity and dateinformation about a PurchaseOrderItem. The ScheduleLine package 37748Aincludes a ScheduleLine entity 37750B and a ConfirmedScheduleLine entity37752B. There is a 1:n relationship between the PurchaseOrderItem entity37766A and the ScheduleLine entity 37750B, and a 1:cn relationshipbetween the PurchaseOrderItem entity 37766A and theConfirmedScheduleLine entity 37752B.

There is no direct relationship between the ScheduleLine entity 37750Band the ConfirmedScheduleLine entity 37752B. This has the advantage thatthe case “10 pieces for 01/01 and 10 pieces for 02/01” ordered as “20pieces for 02/01” can be confirmed simply and without interpretation onthe part of the applications.

(i) Schedule Line

A ScheduleLine is a line containing the quantity and date of aperformance schedule required by the buyer for a purchase order. TheScheduleLine entity 37750B is of type GDT:PurchaseOrderItemScheduleLine. The ScheduleLine entity 37750B includes aDeliveryPeriod entity 37754B. There is a 1:c relationship between theScheduleLine entity 37750B and the DeliveryPeriod entity 37754B.

The ScheduleLine 37750B also includes an ID, a DeliveryPeriod, and aQuantity. The ID is the ScheduleLine number assigned by the procurementsystem. The ID is of type GDT: ScheduleLineID. The DeliveryPeriod is theperiod in which the buyer expects a product to be delivered or serviceprovided. The DeliveryPeriod is of type GDT: DateTimePeriod. TheQuantity is the purchase order quantity. The Quantity is of type GDT:Quantity.

Multiple ScheduleLines for a purchase order item with identicalDeliveryPeriod should not be permitted. All of the ScheduleLines for aparticular item typically use the same unit of measure. ScheduleLinesshould not be used for grouping hierarchy items. In this case, theScheduleLines is explicitly specified for the subitems. ScheduleLines donot have to be specified for limit items. At least one ScheduleLine isspecified for the other item types. Within a ScheduleLine, the quantityis not used for limit items. For the other types of items, the quantityis specified. In the ScheduleLines of subitems for discount in kind andBOM hierarchy items, the DeliveryPeriod of the subitems is identical tothe DeliveryPeriod of the relevant parent items. In the ScheduleLines ofsubstitute product subitems, the DeliveryPeriod of the subitems isidentical to the DeliveryPeriod of the relevant parent items. Thequantities and confirmed quantities of the subitems should be added tothe quantities of the parent items, and where deviations occur, thequantities of subitems are typically regarded as the valid quantities.The ID is optional; i.e., a procurement system does not have to numberthe ScheduleLines.

(ii) Confirmed Schedule Line

A ConfirmedScheduleLine is a line containing the quantity and date of aperformance schedule confirmed by the seller for a purchase order. TheConfirmedScheduleLine entity 37752B is of type GDT:PurchaseOrderItemScheduleLine. There is a 1:cn relationship between thePurchaseOrderItem entity 37766A and the ConfirmedScheduleLine entity37752B. The ConfirmedScheduleLine entity 37752B includes aDeliveryPeriod entity 37756B. There is a 1:c relationship between theConfirmedScheduleLine entity 37752B and the DeliveryPeriod entity37756B.

The ConfirmedScheduleLine entity 37752B also includes an ID, aDeliveryPeriod, and a Quantity. The ID is the ConfirmedScheduleLinenumber assigned by the procurement system. The ID is of type GDT:ScheduleLineID. The DeliveryPeriod is the period in which the sellerprovides the buyer with confirmation of a delivery or the provision of aservice. The DeliveryPeriod is of type GDT: DateTimePeriod. The Quantityis the quantity confirmed by the seller. The Quantity is of type GDT:Quantity.

Multiple ConfirmedScheduleLines are typically not permitted for apurchase order item with identical DeliveryPeriod. The same rules applyfor the use of the ConfirmedScheduleLine for the various item types asdescribed for the ScheduleLine. Confirmation of a partial quantity doesnot mean cancellation of the remaining quantity. It simply means thatthe seller has agreed to this partial quantity and has not yet made adecision about the remaining quantity. In order to cancel a remainingquantity, the seller reduces the quantity of the ScheduleLine (not thatof the ConfirmedScheduleLine) accordingly.

(4) Message Data Type Element Structure

The message data type element structure for the Purchase OrderInformation message is depicted in FIG. 378A. The element structure issimilar to the data model, but provides additional information regardingthe details of the interface. The element structure identifies thedifferent packages 37800 in the interface, and represents the entitiesat various levels within the interface. As depicted in FIG. 378A, theinterface for PurchaseOrderInformationMessage includes five levels37802, 37804, 37806, 37808, and 37810. The outermost package of thisinterface is a PurchaseOrderInformationMessage package 37816, whichincludes a PurchaseOrderInformationMessage entity 37818 at the firstlevel 37802. The PurchaseOrderInformationMessage entity 37818 has a datatype name “PurchaseOrderInformationMessage” 37820.

The PurchaseOrderInformationMessage package 37816 includes aMessageHeader package 37822 and a PurchaseOrderInformation package37896. The MessageHeader package 37822 includes a MessageHeader entity37824 at the second level 37804.

The MessageHeader entity 37824 has a data type name“BusinessDocumentMessageHeader” 37828. There is one 37826 MessageHeaderentity 37824 for each MessageHeader package 37822. The MessageHeaderentity 37824 includes an ID entity 37830, a ReferenceID entity 37836, aCreationDateTime entity 37842, a SenderParty entity 37848, and aRecipientParty entity 37890 at the third level 37806. The ID entity37830 has a data type name “BusinessDocumentMessageID” 37834. There isone 37832 ID entity 37830 for a MessageHeader entity 37824. TheReferenceID entity 37836 has a data type name“BusinessDocumentMessageID” 37840. There is zero or one 37838ReferenceID entity 37836 for a MessageHeader entity 37824. TheCreationDateTime entity 37842 has a data type name “DateTime” 37846.There is one 37844 CreationDateTime entity 37842 for a MessageHeaderentity 37824.

The SenderParty entity 37848 has a data type name“BusinessDocumentMessageParty” 37852. There is zero or one 37850SenderParty entity 37848 for a MessageHeader entity 37824. TheSenderParty entity 37848 includes an InternalID entity 37854, aStandardID entity 37860, and a ContactPerson entity 37866 at the fourthlevel 37808. The InternalID entity 37854 has a data type name“PartyInternalID” 37858. There is zero or one 37856 InternalID entity37854 for a SenderParty entity 37848. The StandardID entity 37860 has adata type name “PartyStandardID” 37864. There is any number of 37862StandardID entity 37860 for a SenderParty entity 37848.

The ContactPerson entity 37866 has a data type name “ContactPerson”37870. There is zero or one 37868 ContactPerson entity 37866 for aSenderParty entity 37848. The ContactPerson entity 37866 includes aBuyerID entity 37872, a SellerID entity 37878, and an Address entity37884 at the fifth level 37810. The BuyerID entity 37872 has a data typename “ContactPersonPartyID” 37876. There is zero or one 37874 BuyerIDentity 37872 for a ContactPerson entity 37866. The SellerID entity 37878has a data type name “ContactPersonPartyID” 37882. There is zero or one37880 SellerID entity 37878 for a ContactPerson entity 37866. TheAddress entity 37884 has a data type name “Address” 37888. There is zeroor one 37886 Address entity 37884 for a ContactPerson entity 37866.

The RecipientParty entity 37890 has a data type name“BusinessDocumentMessageParty” 37894. There is any number of 37892RecipientParty entity 37890 for a MessageHeader entity 37824.

The PurchaseOrderInformation package 37896 includes aPurchaseOrderInformation entity 37898 at the second level 37804, a Partypackage 37828A, a Location Package 37856B, a DeliveryInformation package37864B, a PaymentInformation package 37830C, an Attachment package37876C, a Description package 37890C, a FollowUpMessage package 37804D,and an Item package 37852D. The PurchaseOrderInformation entity 37898has a data type name “PurchaseOrderInformation” 37802A. There is one37800A PurchaseOrderInformation entity 37898 for eachPurchaseOrderInformation package 37896. The PurchaseOrderInformationentity 37898 includes an ID entity 37804F, a PostingDateTime entity37810A, a LastChangeDateTime entity 37816A, and a Note entity 37822A atthe third level 37803. The ID entity 37804F has a data type name“BusinessTransactionDocumentID” 37808A. There is one 37806A ID entity37804F for a PurchaseOrderInformation entity 37898. The PostingDateTimeentity 37810A has a data type name “DateTime” 37814A. There is zero orone 37812A PostingDateTime entity 37810A for a PurchaseOrderInformationentity 37898. The LastChangeDateTime entity 37816A has a data type name“DateTime” 37820A. There is zero or one 37818A LastChangeDateTime entity37816A for a PurchaseOrderInformation entity 37898. The Note entity37822A has a data type name “Note” 37826A. There is zero or one 37824ANote entity 37822A for a PurchaseOrderInformation entity 37898.

The Party package 37828A includes a BuyerParty entity 37830A, aSellerParty entity 37884A, a ProductRecipientParty entity 37890A, aVendorParty entity 37896A, a ManufacturerParty entity 37802B, aBillToParty entity 37808B, a PayerParty entity 37814B, a CarrierPartyentity 37820B, and a ShipToLocation entity 37826B at the third level37806.

The BuyerParty entity 37830A has a data type name“BusinessTransactionDocumentParty” 37834A. There is one 37832ABuyerParty entity 37830A for each Party package 37828A. The BuyerPartyentity 37830A includes a StandardID entity 37836A, a BuyerID entity37842A, a SellerID entity 37848A, an Address entity 37854A, and aContactPerson entity 37860A at the fourth level 37808. The StandardIDentity 37836A has a data type name “PartyStandardID” 37840A. There isany number of 37838A StandardID entity 37836A for a BuyerParty entity37830A. The BuyerID entity 37842A has a data type name “PartyPartyID”37846A. There is zero or one 37844A BuyerID entity 37842A for aBuyerParty entity 37830A. The SellerID entity 37848A has a data typename “PartyPartyID” 37852A. There is zero or one 37850A SellerID entity37848A for a BuyerParty entity 37830A. The Address entity 37854A has adata type name “Address” 37858A. There is zero or one 37856A Addressentity 37854A for a BuyerParty entity 37830A.

The ContactPerson entity 37860A has a data type name “ContactPerson”37864A. There is zero or one 37862A ContactPerson entity 37860A for aBuyerParty entity 37830A. The ContactPerson entity 37860A includes aBuyerID entity 37866A, a SellerID entity 37872A, and an Address entity37878A at the fifth level 37810. The BuyerID entity 37866A has a datatype name “ContactPersonPartyID” 37870A. There is zero or one 37868ABuyerID entity 37866A for a ContactPerson entity 37860A. The SellerIDentity 37872A has a data type name “ContactPersonPartyID” 37876A. Thereis zero or one 37874A SellerID entity 37872A for a ContactPerson entity37860A. The Address entity 37878A has a data type name “Address” 37882A.There is zero or one 37880A Address entity 37878A for a ContactPersonentity 37860A.

The SellerParty entity 37884A has a data type name“BusinessTransactionDocumentParty” 37888A. There is one 37886ASellerParty entity 37884A for each Party package 37828A. TheProductRecipientParty entity 37890A has a data type name“BusinessTransactionDocumentParty” 37894A. There is zero or one 37892AProductRecipientParty entity 37890A for each Party package 37828A. TheVendorParty entity 37896A has a data type name“BusinessTransactionDocumentParty” 37800B. There is zero or one 37898AVendorParty entity 37896A for each Party package 37828A. TheManufacturerParty entity 37802B has a data type name“BusinessTransactionDocumentParty” 37806B. There is zero or one 37804BManufacturerParty entity 37802B for each Party package 37828A. TheBillToParty entity 37808B has a data type name“BusinessTransactionDocumentParty” 37812B. There is zero or one 37810BBillToParty entity 37808B for each Party package 37828A. The PayerPartyentity 37814B has a data type name “BusinessTransactionDocumentParty”37818B. There is zero or one 37816B PayerParty entity 37814B for eachParty package 37828A. The CarrierParty entity 37820B has a data typename “BusinessTransactionDocumentParty” 37824B. There is zero or one37822B CarrierParty entity 37820B for each Party package 37828A.

The ShipToLocation entity 37826B has a data type name“BusinessTransactionDocumentLocation” 37830B. There is zero or one37828B ShipToLocation entity 37826B for each Party package 37828A. TheShipToLocation entity 37826B includes a StandardID entity 37832B, aBuyerID entity 37838B, a SellerID entity 37844B, and an Address entity37850B at the fourth level 37808. The StandardID entity 37832B has adata type name “LocationStandardID” 37836B. There is any number of37834B StandardID entity 37832B for a ShipToLocation entity 37826B. TheBuyerID entity 37838B has a data type name “LocationPartyID” 37842B.There is zero or one 37840B BuyerID entity 37838B for a ShipToLocationentity 37826B. The SellerID entity 37844B has a data type name“LocationPartyID” 37848B. There is zero or one 37846B SellerID entity37844B for a ShipToLocation entity 37826B. The Address entity 37850B hasa data type name “Address” 37854B. There is zero or one 37852B Addressentity 37850B for a ShipToLocation entity 37826B.

The Location Package 37856B includes a ShipFromLocation entity 37858B atthe third level 37806. The ShipFromLocation entity 37858B has a datatype name “BusinessTransactionDocumentLocation” 37862B. There is zero orone 37860B ShipFromLocation entity 37858B for each Location Package37856B.

The DeliveryInformation package 37864B includes a DeliveryTerms entity37866B at the third level 37806. The DeliveryTerms entity 37866B has adata type name “DeliveryTerms” 37870B. There is zero or one 37868BDeliveryTerms entity 37866B for each DeliveryInformation package 37864B.The DeliveryTerms entity 37866B includes a DeliveryItemGroupID entity37872B, a DeliveryPriorityCode entity 37878B, an Incoterms entity37884B, a PartialDelivery entity 37890B, a QuantityTolerance entity37896B, a Transport entity 37802C, and a Description entity 37824C atthe fourth level 37808.

The DeliveryItemGroupID entity 37872B has a data type name“BusinessTransactionDocumentItemGroupID” 37876B. There is zero or one37874B DeliveryItemGroupID entity 37872B for a DeliveryTerms entity37866B. The DeliveryPriorityCode entity 37878B has a data type name“BusinessTransactionPriorityCode” 37882B. There is zero or one 37880BDeliveryPriorityCode entity 37878B for a DeliveryTerms entity 37866B.The Incoterms entity 37884B has a data type name “Incoterms” 37888B.There is zero or one 37886B Incoterms entity 37884B for a DeliveryTermsentity 37866B. The PartialDelivery entity 37890B has a data type name“PartialDelivery” 37894B. There is zero or one 37892B PartialDeliveryentity 37890B for a DeliveryTerms entity 37866B. The QuantityToleranceentity 37896B has a data type name “QuantityTolerance” 37800C. There iszero or one 37898B QuantityTolerance entity 37896B for a DeliveryTermsentity 37866B.

The Transport entity 37802C includes a ServiceLevelCode entity 37806C, aModeCode entity 37812C, and a MeansDescriptionCode entity 37818C at thefifth level 37810. There is zero or one 37804C Transport entity 37802Cfor a DeliveryTerms entity 37866B. The ServiceLevelCode entity 37806Chas a data type name “TransportServiceLevelCode” 37810C. There is zeroor one 37808C ServiceLevelCode entity 37806C for a Transport entity37802C. The ModeCode entity 37812C has a data type name“TransportModeCode” 37816C. There is zero or one 37814C ModeCode entity37812C for a Transport entity 37802C. The MeansDescriptionCode entity37818C has a data type name “TransportMeansDescriptionCode” 37822C.There is zero or one 37820C MeansDescriptionCode entity 37818C for aTransport entity 37802C.

The Description entity 37824C has a data type name “Description” 37828C.There is zero or one 37826C Description entity 37824C for aDeliveryTerms entity 37866B.

The PaymentInformation package 37830C includes a CashDiscountTermsentity 37832C and a PaymentForm entity 37860C at the third level 37806.The CashDiscountTerms entity 37832C has a data type name“CashDiscountTerms” 37836C. There is zero or one 37834CCashDiscountTerms entity 37832C for each PaymentInformation package37830C. The CashDiscountTerms entity 37832C includes aPaymentBaselineDate entity 37838C, a MaximumCashDiscount entity 37844C,a NormalCashDiscount entity 37850C, and a FullPaymentDueDaysValue entity37856C at the fourth level 37808. The PaymentBaselineDate entity 37838Chas a data type name “Date” 37842C. There is zero or one 37840CPaymentBaselineDate entity 37838C for a CashDiscountTerms entity 37832C.The MaximumCashDiscount entity 37844C has a data type name“CashDiscount” 37848C. There is zero or one 37846C MaximumCashDiscountentity 37844C for a CashDiscountTerms entity 37832C. TheNormalCashDiscount entity 37850C has a data type name “CashDiscount”37854C. There is zero or one 37852C NormalCashDiscount entity 37850C fora CashDiscountTerms entity 37832C. There is zero or one 37858CFullPaymentDueDaysValue entity 37856C for a CashDiscountTerms entity37832C.

The PaymentForm entity 37860C includes a Code entity 37864C and aPaymentCard entity 37870C at the fourth level 37808. There is zero orone 37862C PaymentForm entity 37860C for each PaymentInformation package37830C. The Code entity 37864C has a data type name “PaymentFormCode”37868C. There is one 37866C Code entity 37864C for a PaymentForm entity37860C. The PaymentCard entity 37870C has a data type name “PaymentCard”37874C. There is zero or one 37872C PaymentCard entity 37870C for aPaymentForm entity 37860C.

The Attachment package 37876C includes an AttachmentWebAddress entity37878C and an InternalAttachmentWebAddress entity 37884C in the thirdlevel 37806. The AttachmentWebAddress entity 37878C has a data type name“AttachmentWebAddress” 37882C. There is any number of 37880CAttachmentWebAddress entity 37878C for each Attachment package 37876C.The InternalAttachmentWebAddress entity 37884C has a data type name“AttachmentWebAddress” 37888C. There is any number of 37886CInternalAttachmentWebAddress entity 37884C for each Attachment package37876C.

The Description package 37890C includes a Description entity 37892C andan InternalDescription entity 37898C at the third level 37806. TheDescription entity 37892C has a data type name “Description” 37896C.There is zero or one 37894C Description entity 37892C for eachDescription package 37890C. The InternalDescription entity 37898C has adata type name “Description” 37802D. There is zero or one 37800DInternalDescription entity 37898C for each Description package 37890C.

The FollowUpMessage package 37804D includes aFollowUpPurchaseOrderConfirmation entity 37806D, aFollowUpDespatchedDeliveryNotification entity 37816D, aFollowUpServiceAcknowledgementRequest entity 37826D, and aFollowUpInvoiceRequest entity 37836D at the third level 37806. TheFollowUpPurchaseOrderConfirmation entity 37806D includes aRequirementCode entity 37810D at the fourth level 37808. There is zeroor one 37808D FollowUpPurchaseOrderConfirmation entity 37806D for eachFollowUpMessage package 37804D. The RequirementCode entity 37810D has adata type name “FollowUpMessageRequirementCode” 37814D. There is one37812D RequirementCode entity 37810D for aFollowUpPurchaseOrderConfirmation entity 37806D.

The FollowUpDespatchedDeliveryNotification entity 37816D includes aRequirementCode entity 37820D at the fourth level 37808. There is zeroor one 37818D FollowUpDespatchedDeliveryNotification entity 37816D foreach FollowUpMessage package 37804D. The RequirementCode entity 37820Dhas a data type name “FollowUpMessageRequirementCode” 37824D. There isone 37822D RequirementCode entity 37820D for aFollowUpDespatchedDeliveryNotification entity 37816D.

The FollowUpServiceAcknowledgementRequest entity 37826D includes aRequirementCode entity 37830D at the fourth level 37808. There is zeroor one 37828D FollowUpServiceAcknowledgementRequest entity 37826D foreach FollowUpMessage package 37804D. The RequirementCode entity 37830Dhas a data type name “FollowUpMessageRequirementCode” 37834D. There isone 37832D RequirementCode entity 37830D for aFollowUpServiceAcknowledgementRequest entity 37826D.

The FollowUpInvoiceRequest entity 37836D includes a RequirementCodeentity 37840D and an EvaluatedReceiptSettlementIndicator 37846D at thefourth level 37808. There is zero or one 37838D FollowUpInvoiceRequestentity 37836D for each FollowUpMessage package 37804D. TheRequirementCode entity 37840D has a data type name“FollowUpMessageRequirementCode” 37844D. There is one 37842DRequirementCode entity 37840D for a FollowUpInvoiceRequest entity37836D.

The EvaluatedReceiptSettlementIndicator 37846D has a data type name“EvaluatedReceiptSettlementIndicator” 37850D. There is zero or one37848D EvaluatedReceiptSettlementIndicator 37846D for aFollowUpInvoiceRequest entity 37836D.

The Item package 37852D includes an Item entity 37854D at the thirdlevel 37806, a ProductInformation package 37888D, a PriceInformationpackage 37856E, a Party package 37884E, a Location package 37834F, aDeliveryInformation package 37848F, aBusinessTransactionDocumentReference package 37856F, an Attachmentpackage 37848G, a Description package 37862G, and a ScheduleLine package37876G. The Item entity 37854D has a data type name“PurchaseOrderInformationItem” 37858D. There is any number of 37856DItem entity 37854D for each Item package 37852D. The Item entity 37854Dincludes an ID entity 37860D, a ConfirmedInformationOutdatedIndicatorentity 37866D, and a HierarchyRelationship entity 37872D at the fourthlevel 37808. The ID entity 37860D has a data type name“BusinessTransactionDocumentItemID” 37864D. There is one 37862D IDentity 37860D for an Item entity 37854D. TheConfirmedInformationOutdatedIndicator entity 37866D has a data type name“InformationOutdatedIndicator” 37870D. There is zero or one 37868DConfirmedInformationOutdatedIndicator entity 37866D for an Item entity37854D.

The HierarchyRelationship entity 37872D includes a ParentItemID entity37876D and a TypeCode entity 37882D at the fifth level 37810. There iszero or one 37874D HierarchyRelationship entity 37872D for an Itementity 37854D. The ParentItemID entity 37876D has a data type name“BusinessTransactionDocumentItemID” 37880D. There is one 37878DParentItemID entity 37876D for a HierarchyRelationship entity 37872D.TheTypeCode entity 37882D has a data type name“BusinessTransactionDocumentItemHierarchyRelationshipTypeCode” 37886D.There is one 37884D TypeCode entity 37882D for a HierarchyRelationshipentity 37872D.

The ProductInformation package 37888D includes a Product entity 37890Dand a ProductCategory entity 37832E at the fourth level 37808. TheProduct entity 37890D has a data type name“BusinessTransactionDocumentProduct” 37894D. There is zero or one 37892DProduct entity 37890D for each ProductInformation package 37888D. TheProduct entity 37890D includes a StandardID entity 37896D, a BuyerIDentity 37802E, a SellerID entity 37808E, a ManufacturerID entity 37814E,a TypeCode entity 37820E, and a Note entity 37826E at the fifth level37810.

The StandardID entity 37896D has a data type name “ProductStandardID”37800E. There is any number of 37898D StandardID entity 37896D for aProduct entity 37890D. The BuyerID entity 37802E has a data type name“ProductPartyID” 37806E. There is zero or one 37804E BuyerID entity37802E for a Product entity 37890D. The SellerID entity 37808E has adata type name “ProductPartyID” 37812E. There is zero or one 37810ESellerID entity 37808E for a Product entity 37890D. The ManufacturerIDentity 37814E has a data type name “ProductPartyID” 37818E. There iszero or one 37816E ManufacturerID entity 37814E for a Product entity37890D. The TypeCode entity 37820E has a data type name“ProductTypeCode” 37824E. There is zero or one 37822E TypeCode entity37820E for a Product entity 37890D. The Note entity 37826E has a datatype name “Note” 37830E. There is zero or one 37828E Note entity 37826Efor a Product entity 37890D.

The ProductCategory entity 37832E has a data type name“BusinessTransactionDocumentProductCategory” 37836E. There is zero orone 37834E ProductCategory entity 37832E for each ProductInformationpackage 37888D. The ProductCategory entity 37832E includes a StandardIDentity 37838E, a BuyerID entity 37844E, and a SellerID entity 37850E atthe fifth level 37810. The StandardID entity 37838E has a data type name“ProductCategoryStandardID” 37842E. There is any number of 37840EStandardID entity 37838E for a ProductCategory entity 37832E. TheBuyerID entity 37844E has a data type name “ProductCategoryPartyID”37848E. There is zero or one 37846E BuyerID entity 37844E for aProductCategory entity 37832E. The SellerID entity 37850E has a datatype name “ProductCategoryPartyID” 37854E. There is zero or one 37852ESellerID entity 37850E for a ProductCategory entity 37832E.

The PriceInformation package 37856E includes a Price entity 37858E, aConfirmedPrice entity 37868E, and a ProcurementCostUpperLimit entity37878E at the fourth level 37808. The Price entity 37858E includes aNetUnitPrice entity 37862E at the fifth level 37810. There is zero orone 37860E Price entity 37858E for each PriceInformation package 37856E.The NetUnitPrice entity 37862E has a data type name “Price” 37866E.There is zero or one 37864E NetUnitPrice entity 37862E for a Priceentity 37858E.

The ConfirmedPrice entity 37868E includes a NetUnitPrice entity 37872Eat the fifth level 37810. There is zero or one 37870E Price entity37858E for each PriceInformation package 37856E. The NetUnitPrice entity37872E has a data type name “Price” 37876E. There is zero or one 37874ENetUnitPrice entity 37862E for a Price entity 37858E.

The ProcurementCostUpperLimit entity 37878E has a data type name“ProcurementCostUpperLimit” 37882E. There is zero or one 37880EProcurementCostUpperLimit entity 37878E for each PriceInformationpackage 37856E.

The Party package 37884E includes a BuyerParty entity 37886E, aSellerParty entity 37892E, a ProductRecipientParty entity 37898E, aVendorParty entity 37804F, a ManufacturerParty entity 37810F, aBillToParty entity 37816F, a PayerParty entity 37822F, and aCarrierParty entity 37828F at the fourth level 37808. The BuyerPartyentity 37886E has a data type name “BusinessTransactionDocumentParty”37890E. There is zero or one 37888E BuyerParty entity 37886E for eachParty package 37884E. The SellerParty entity 37892E has a data type name“BusinessTransactionDocumentParty” 37896E. There is zero or one 37894ESellerParty entity 37892E for each Party package 37884E. TheProductRecipientParty entity 37898E has a data type name“BusinessTransactionDocumentParty” 37802F. There is zero or one 37800FProductRecipientParty entity 37898E for each Party package 37884E. TheVendorParty entity 37804F has a data type name“BusinessTransactionDocumentParty” 37808F. There is zero or one 37806FVendorParty entity 37804F for each Party package 37884E. TheManufacturerParty entity 37810F has a data type name“BusinessTransactionDocumentParty” 37814F. There is zero or one 37812FManufacturerParty entity 37810F for each Party package 37884E. TheBillToParty entity 37816F has a data type name“BusinessTransactionDocumentParty” 37820F. There is zero or one 37818FBillToParty entity 37816F for each Party package 37884E. The PayerPartyentity 37822F has a data type name “BusinessTransactionDocumentParty”37826F. There is zero or one 37824F PayerParty entity 37822F for eachParty package 37884E. The CarrierParty entity 37828F has a data typename “BusinessTransactionDocumentParty” 37832F. There is zero or one37830F CarrierParty 37828F for each Party package 37884E.

The Location package 37834F includes a ShipToLocation entity 37836F anda ShipFromLocation entity 37842F at the fourth level 37808. TheShipToLocation entity 37836F has a data type name“BusinessTransactionDocumentLocation” 37840F. There is zero or one37838F ShipToLocation entity 37836F for each Location package 37834F.The ShipFromLocation entity 37842F has a data type name“BusinessTransactionDocumentLocation” 37846F. There is zero or one37844F ShipFromLocation entity 37842F for each Location package 37834F.

The DeliveryInformation package 37848F includes a DeliveryTerms entity37850F at the fourth level 37808. The DeliveryTerms entity 37850F has adata type name “DeliveryTerms” 37854F. There is zero or one 37852FDeliveryTerms entity 37850F for each DeliveryInformation package 37848F.

The BusinessTransactionDocumentReference package 37856F includes aQuoteReference entity 37858F, a PurchaseContractReference entity 37876F,an OriginPurchaseOrderReference entity 37894F, aBuyerProductCatalogReference entity 37812G, and aSellerProductCatalogReference entity 37830G at the fourth level 37808.The QuoteReference entity 37858F has a data type name“BusinessTransactionDocumentReference” 37862F. There is zero or one37860F QuoteReference entity 37858F for eachBusinessTransactionDocumentReference package 37856F. The QuoteReferenceentity 37858F includes an ID entity 37864F and an ItemID entity 37870Fat the fifth level 37810. The ID entity 37864F has a data type name“BusinessTransactionDocumentID” 37868F. There one 37866F ID entity37864F for a QuoteReference entity 37858F. The ItemID entity 37870F hasa data type name “BusinessTransactionDocumentItemID” 37874F. There isany number of 37872F ItemID entity 37870F for a QuoteReference entity37858F.

The PurchaseContractReference entity 37876F has a data type name“BusinessTransactionDocumentReference” 37880F. There is any number of37878F PurchaseContractReference entity 37876F for eachBusinessTransactionDocumentReference package 37856F. ThePurchaseContractReference entity 37876F includes an ID entity 37882F andan ItemID entity 37888F at the fifth level 37810. The ID entity 37882Fhas a data type name “BusinessTransactionDocumentID” 37886F. There one37884F ID entity 37882F for a PurchaseContractReference entity 37876F.The ItemID entity 37888F has a data type name“BusinessTransactionDocumentItemID” 37892F. There is any number of37890F ItemID entity 37888F for a PurchaseContractReference entity37876F.

The OriginPurchaseOrderReference entity 37894F has a data type name“BusinessTransactionDocumentReference” 37898F. There is zero or one37896F OriginPurchaseOrderReference entity 37894F for eachBusinessTransactionDocumentReference package 37856F. TheOriginPurchaseOrderReference entity 37894F includes an ID entity 37800Gand an ItemID entity 37806G at the fifth level 37810. The ID entity37800G has a data type name “BusinessTransactionDocumentID” 37804G.There one 37802G ID entity 37800G for an OriginPurchaseOrderReferenceentity 37894F. The ItemID entity 37806G has a data type name“BusinessTransactionDocumentItemID” 37810G. There is any number of37808G ItemID entity 37806G for an OriginPurchaseOrderReference entity37894F.

The BuyerProductCatalogReference entity 37812G has a data type name“CatalogReference” 37816G. There is zero or one 37814GBuyerProductCatalogReference entity 37812G for eachBusinessTransactionDocumentReference package 37856F. TheBuyerProductCatalogReference entity 37812G includes an ID entity 37818Gand an ItemID entity 37824G at the fifth level 37810. The ID entity37818G has a data type name “CatalogID” 37822G. There one 37820G IDentity 37818G for a BuyerProductCatalogReference entity 37812G. TheItemID entity 37824G has a data type name “CatalogItemID” 37828G. Thereis any number of 37826G ItemID entity 37824G for aBuyerProductCatalogReference entity 37812G.

The SellerProductCatalogReference entity 37830G has a data type name“CatalogReference” 37834G. There is zero or one 37832GSellerProductCatalogReference entity 37830G for eachBusinessTransactionDocumentReference package 37856F. TheSellerProductCatalogReference entity 37830G includes an ID entity 37836Gand an ItemID entity 37842G at the fifth level 37810. The ID entity37836G has a data type name “CatalogID” 37840G. There one 37838G IDentity 37836G for a SellerProductCatalogReference entity 37830G. TheItemID entity 37842G has a data type name “CatalogItemID” 37846G. Thereis any number of 37844G ItemID entity 37842G for aSellerProductCatalogReference entity 37830G.

The Attachment package 37848G includes an AttachmentWebAddress entity37850G and an InternalAttachmentWebAddress entity 37856G at the fourthlevel 37808. The AttachmentWebAddress entity 37850G has a data type name“WebAddress” 37854G. There is any number of 37852G AttachmentWebAddressentity 37850G for each Attachment package 37848G. TheInternalAttachmentWebAddress entity 37856G has a data type name“WebAddress” 37860G. There is any number of 37858GInternalAttachmentWebAddress entity 37856G for each Attachment package37848G.

The Description package 37862G includes a Description entity 37864G andan InternalDescription entity 37870G at the fourth level 37808. TheDescription entity 37864G has a data type name “Description” 37868G.There is zero or one 37866G Description entity 37864G for eachDescription package 37862G.

The InternalDescription entity 37870G has a data type name“InternalDescription” 37874G. There is zero or one 37872GInternalDescription entity 37870G for each Description package 37862G.

The ScheduleLine package 37876G includes a ScheduleLine entity 37878Gand a ConfirmedScheduleLine entity 37802H at the fourth level 37808. TheScheduleLine entity 37878G has a data type name“PurchaseOrderInformationItemScheduleLine” 37882G. There is any numberof 37880G ScheduleLine entity 37878G for each ScheduleLine package37876G. The ScheduleLine entity 37878G includes an ID entity 37884G, aDeliveryPeriod entity 37890G, and a Quantity entity 37896G at the fifthlevel 37810. The ID entity 37884G has a data type name“BusinessTransactionDocumentItemScheduleLineID” 37888G. There is zero orone 37886G ID entity 37884G for a ScheduleLine entity 37878G. TheDeliveryPeriod entity 37890G has a data type name “DateTimePeriod”37894G. There is one 37892G DeliveryPeriod entity 37890G for aScheduleLine entity 37878G. The Quantity entity 37896G has a data typename “Quantity” 37800H. There is zero or one 37898G Quantity entity37896G for a ScheduleLine entity 37878G.

The ConfirmedScheduleLine entity 37802H has a data type name“PurchaseOrderInformationItemScheduleLine” 37806H. There is any numberof 37804H ConfirmedScheduleLine entity 37802H for each ScheduleLinepackage 37876G.

(5) Message Data Type Purchase Order Legal Document Message

The message data type PurchaseOrderLegalDocumentMessage contains: theobject PurchaseOrder contained in the business document in the viewrequired for PurchaseOrderLegalDocument and the business informationthat is relevant for the sending of a business document in a message.The PurchaseOrderLegalDocument Message package contains a MessageHeaderpackage and a PurchaseOrder package (see above). The message data typePurchaseOrderLegalDocumentMessage can provide the structure for themessage type PurchaseOrderLegalDocument and the interfaces that arebased on it.

(a) MessageHeader Package

A message header package groups business information from theperspective of the sending application. In variations, this package isnot necessary, so, the package is empty or not included.

(b) PurchaseOrder Package

The PurchaseOrderPackage for the PurchaseOrderLegalDocument message issimilar the PurchaseOrder package for thePurchaseOrderInformationMessage, described above. Differences betweenthe message types can include that the InternalAttachmentWebAddress of aPurchaseOrderAttachment Package, InternalAttachmentWebAddress of aPurchaseOrderItemAttachment Package, and the InternalDescription of thePurchaseOrderDescription Package are not included in thePurchaseOrderLegalDocument message. This can be due to those entitiesnot being intended for transmission to Document Management.

(6) Message Data Type Element Structure

The message data type element structure for the Purchase Order LegalDocument message is depicted in FIG. 378AA-R. The element structure issimilar to the data model, but provides additional information regardingthe details of the interface. The element structure identifies thedifferent packages 378A00 in the interface, and represents the entitiesat various levels within the interface. As depicted in FIG. 378AA, theinterface for PurchaseOrderLegalDocumentMessage includes five levels378A02, 378A04, 378A06, 378A08, and 378A10. The outermost package ofthis interface is a PurchaseOrderLegalDocumentMessage package 378A16,which includes a PurchaseOrderLegalDocumentMessage entity 378A18 at thefirst level 378A02. The PurchaseOrderLegalDocumentMessage entity 378A18is of a type MDT 378A20 “PurchaseOrderLegalDocumentMessage” 378A22.

The PurchaseOrderLegalDocumentMessage package 378A16 includes aPurchaseOrderLegalDocument package 378A24. ThePurchaseOrderLegalDocument package 378A24 includes a PurchaseOrderentity 378A26 at the second level 378A04, a Party package 378A56, aLocation package 378A44A, a DeliveryInformation package 378A58A, aPaymentInformation package 378A26B, an Attachment package 378A72B, aDescription package 378A92B, a FollowUpMessage package 378A08C, and anItem package 378A56C.

The PurchaseOrder entity 378A26 has a data type name“PurchaseOrderInformation” 378A30. There is one 378A28 PurchaseOrderentity 378A26 for each PurchaseOrderLegalDocument package 378A24. ThePurchaseOrder entity 378A26 includes an ID entity 378A32, aPostingDateTime entity 378A38, a LastChangeDateTime entity 378A44, and aNote entity 378A50 at the third level 378A06. The ID entity 378A32 has adata type name “BusinessTransactionDocumentID” 378A36. There is one378A34 ID entity 378A32 for a PurchaseOrder entity 378A26. ThePostingDateTime entity 378A38 has a data type name “DateTime” 378A42.There is zero or one 378A40 PostingDateTime entity 378A38 for aPurchaseOrder entity 378A26. The LastChangeDateTime entity 378A44 has adata type name “DateTime” 378A48. There is zero or one 378A46LastChangeDateTime entity 378A44 for a PurchaseOrder entity 378A26. TheNote entity 378A50 has a data type name “Note” 378A54. There is zero orone 378A52 Note entity 378A50 for a PurchaseOrder entity 378A26.

The Party package 378A56 includes a BuyerParty entity 378A58, aSellerParty entity 378A02A, a ProductRecipientParty entity 378A08A, aVendorParty entity 378A14A, a ManufacturerParty entity 378A20A, aBillToParty entity 378A26A, a PayerParty entity 378A32A, and aCarrierParty entity CC38A at the third level 378A06.

The BuyerParty entity 378A58 has a data type name“BusinessTransactionDocumentParty” 378A62. There is zero or one 378A60BuyerParty entity 378A58 for each Party package 378A56. The BuyerPartyentity 378A58 includes an InternalID entity 378A64, a StandardID entity378A70, an Address entity 378A76, and a ContactPerson entity 378A82 atthe fourth level 378A08. The InternalID entity 378A64 has a data typename “PartyInternalID” 378A68. There is zero or one 378A66 InternalIDentity 378A64 for a BuyerParty entity 378A58. The StandardID entity378A70 has a data type name “PartyStandardID” 378A74. There is anynumber of 378A72 StandardID entity 378A70 for a BuyerParty entity378A58. The Address entity 378A76 has a data type name “Address” 378A80.There is zero or one 378A78 Address entity 378A76 for a BuyerPartyentity 378A58.

The ContactPerson entity 378A82 has a data type name “ContactPerson”378A86. There is zero or one 378A84 ContactPerson entity 378A82 for aBuyerParty entity 378A58. The ContactPerson entity 378A82 includes anInternalID entity 378A88 and an Address entity 378A94 at the fifth level378A10. The InternalID entity 378A88 has a data type name“ContactPersonID” 378A92. There is zero or one 378A90 InternalID entity378A88 for a ContactPerson entity 378A82. The Address entity 378A94 hasa data type name “Address” 378A98. There is zero or one 378A96 Addressentity 378A94 for a ContactPerson entity 378A82.

The SellerParty entity 378A02A has a data type name“BusinessTransactionDocumentParty” 378A06A. There is zero or one 378A04ASellerParty entity 378A02A for each Party package 378A56. TheProductRecipientParty entity 378A08A has a data type name“BusinessTransactionDocumentParty” 378A12A. There is zero or one 378A10AProductRecipientParty entity 378A08A for each Party package 378A56. TheVendorParty entity 378A14A has a data type name“BusinessTransactionDocumentParty” 378A18A. There is zero or one 378A16AVendorParty entity 378A14A for each Party package 378A56. TheManufacturerParty entity 378A20A has a data type name“BusinessTransactionDocumentParty” 378A24A. There is zero or one 378A22AManufacturerParty entity 378A20A for each Party package 378A56. TheBillToParty entity 378A26A has a data type name“BusinessTransactionDocumentParty” 378A30A. There is zero or one 378A28ABillToParty entity 378A26A for each Party package 378A56. The PayerPartyentity 378A32A has a data type name “BusinessTransactionDocumentParty”378A36A. There is zero or one 378A34A PayerParty entity 378A32A for eachParty package 378A56. The CarrierParty entity CC38A has a data type name“BusinessTransactionDocumentParty” 378A42A. There is zero or one 378A40ACarrierParty entity CC38A for each Party package 378A56.

The Location package 378A44A includes a ShipToLocation entity 378A46Aand a ShipFromLocation entity 378A52A at the third level 378A06. TheShipToLocation entity 378A46A has a data type name“BusinessTransactionDocumentShipToLocation” 378A50A. There is zero orone 378A48A ShipToLocation entity 378A46A for each Location package378A44A. The ShipFromLocation entity 378A52A has a data type name“BusinessTransactionDocumentShipFromLocation” 378A56A. There is zero orone 378A54A ShipFromLocation entity 378A52A for each Location package378A44A.

The DeliveryInformation package 378A58A includes a DeliveryTerms entity378A60A at the third level 378A06. The DeliveryTerms entity 378A60A hasa data type name “DeliveryTerms” 378A64A. There is zero or one 378A62ADeliveryTerms entity 378A60A for each DeliveryInformation package378A58A. The DeliveryTerms entity 378A60A includes a DeliveryItemGroupIDentity 378A66A, a DeliveryPriorityCode entity 378A72A, an Incotermsentity 378A78A, a PartialDelivery entity 378A84A, a QuantityToleranceentity 378A90A, a Transport entity 378A96A, and a Description entity378A20B at the fourth level 378A08. The DeliveryItemGroupID entity378A66A has a data type name “BusinessTransactionDocumentItemGroupID”378A70A. There is zero or one 378A68A DeliveryItemGroupID entity 378A66Afor a DeliveryTerms entity 378A60A. The DeliveryPriorityCode entity378A72A has a data type name “BusinessTransactionPriorityCode” 378A76A.There is zero or one 378A74A DeliveryPriorityCode entity 378A72A for aDeliveryTerms entity 378A60A. The Incoterms entity 378A78A has a datatype name “Incoterms” 378A82A. There is zero or one 378A80A Incotermsentity 378A78A for a DeliveryTerms entity 378A60A. The PartialDeliveryentity 378A84A has a data type name “PartialDelivery” 378A88A. There iszero or one 378A86A PartialDelivery entity 378A84A for a DeliveryTermsentity 378A60A. The QuantityTolerance entity 378A90A has a data typename “QuantityTolerance” 378A94A. There is zero or one 378A92AQuantityTolerance entity 378A90A for a DeliveryTerms entity 378A60A.

There is zero or one 378A98A Transport entity 378A96A for aDeliveryTerms entity 378A60A. The Transport entity 378A96A includes aServiceLevelCode entity 378A02B, a ModeCode entity 378A08B, and aMeansDescriptionCode entity 378A14B at the fifth level 378A10. TheServiceLevelCode entity 378A02B has a data type name“TransportServiceLevelCode” 378A06B. There is zero or one 378A04BServiceLevelCode entity 378A02B for a Transport entity 378A96A.TheModeCode entity 378A08B has a data type name “TransportModeCode”378A12B. There is zero or one 378A10B ModeCode entity 378A08B for aTransport entity 378A96A. The MeansDescriptionCode entity 378A14B has adata type name “TransportMeansDescriptionCode” 378A18B. There is zero orone 378A16B MeansDescriptionCode entity 378A14B for a Transport entity378A96A.

The Description entity 378A20B has a data type name “Description”378A24B. There is zero or one 378A22B Description entity 378A20B for aDeliveryTerms entity 378A60A.

The PaymentInformation package 378A26B includes a CashDiscountTermsentity 378A28B and a PaymentForm entity 378A56B at the third level378A06.

The CashDiscountTerms entity 378A28B has a data type name“CashDiscountTerms” 378A32B. There is zero or one 378A30BCashDiscountTerms entity 378A28B for each PaymentInformation package378A26B. The CashDiscountTerms entity 378A28B includes aPaymentBaselineDate entity 378A34B, a MaximumCashDiscount entity378A40B, a NormalCashDiscount entity 378A46B, and aFullPaymentDueDaysValue entity 378A52B at the fourth level 378A08. ThePaymentBaselineDate entity 378A34B has a data type name “Date” 378A38B.There is zero or one 378A36B PaymentBaselineDate entity 378A34B for aCashDiscountTerms entity 378A28B. The MaximumCashDiscount entity 378A40Bhas a data type name “CashDiscount” 378A44B. There is zero or one378A42B MaximumCashDiscount entity 378A40B for a CashDiscountTermsentity 378A28B. The NormalCashDiscount entity 378A46B has a data typename “CashDiscount” 378A50B. There is zero or one 378A48BNormalCashDiscount entity 378A46B for a CashDiscountTerms entity378A28B. There is zero or one 378A54B FullPaymentDueDaysValue entity378A52B for a CashDiscountTerms entity 378A28B.

The PaymentForm entity 378A56B includes a Code entity 378A60B and aPaymentCard entity 378A66B at the fourth level 378A08. There is zero orone 378A58B PaymentForm entity 378A56B for each PaymentInformationpackage 378A26B. The Code entity 378A60B has a data type name“PaymentFormCode” 378A64B. There is one 378A62B Code entity 378A60B fora PaymentForm entity 378A56B. The PaymentCard entity 378A66B has a datatype name “PaymentCard” 378A70B. There is zero or one 378A68BPaymentCard entity 378A66B for a PaymentForm entity 378A56B.

The Attachment package 378A72B includes an AttachmentWebAddress entity378A74B, an InternalAttachmentWebAddress entity 378A80B, and aLegalDocumentAttachment entity 378A86B at the third level 378A06. TheAttachmentWebAddress entity 378A74B has a data type name“AttachmentWebAddress” 378A78B. There is any number of 378A76BAttachmentWebAddress entity 378A74B for each Attachment package 378A72B.The InternalAttachmentWebAddress entity 378A80B has a data type name“AttachmentWebAddress” 378A84B. There is any number of 378A82BInternalAttachmentWebAddress entity 378A80B for each Attachment package378A72B. The LegalDocumentAttachment entity 378A86B has a data type name“Attachment” 378A90B. There is any number of 378A88BLegalDocumentAttachment entity 378A86B for each Attachment package378A72B.

The Description package 378A92B includes a Description entity 378A94Band an InternalDescription entity 378A02C at the third level 378A06. TheDescription entity 378A94B has a data type name “Description” 378A98B.There is zero or one 378A96B Description entity 378A94B for eachDescription package 378A92B. The InternalDescription entity 378A02C hasa data type name “Description” 378A06C. There is zero or one 378A04CInternalDescription entity 378A02C for each Description package 378A92B.

The FollowUpMessage package 378A08C includes aFollowUpPurchaseOrderConfirmation entity 378A10C, aFollowUpDespatchedDeliveryNotification entity 378A20C, aFollowUpServiceAcknowledgementRequest entity 378A30C, and aFollowUpInvoiceRequest entity 378A40C at the third level 378A06.

The FollowUpPurchaseOrderConfirmation entity 378A10C includes aRequirementCode entity 378A14C at the fourth level 378A08. There is zeroor one 378A12C FollowUpPurchaseOrderConfirmation entity 378A10C for eachFollowUpMessage package 378A08C. The RequirementCode entity 378A14C hasa data type name “FollowUpMessageRequirementCode” 378A18C. There is one378A16C RequirementCode entity 378A14C for aFollowUpPurchaseOrderConfirmation entity 378A10C.

The FollowUpDespatchedDeliveryNotification entity 378A20C includes aRequirementCode entity 378A24C at the fourth level 378A08. There is zeroor one 378A22C FollowUpDespatchedDeliveryNotification entity 378A20C foreach FollowUpMessage package 378A08C. The RequirementCode entity 378A24Chas a data type name “FollowUpMessageRequirementCode” 378A28C. There isone 378A26C RequirementCode entity 378A24C for aFollowUpDespatchedDeliveryNotification entity 378A20C.

The FollowUpServiceAcknowledgementRequest entity 378A30C includes aRequirementCode entity 378A34C at the fourth level 378A08. There is zeroor one 378A32C FollowUpServiceAcknowledgementRequest entity 378A30C foreach FollowUpMessage package 378A08C. The RequirementCode entity 378A34Chas a data type name “FollowUpMessageRequirementCode” 378A38C. There isone 378A36C RequirementCode entity 378A34C for aFollowUpServiceAcknowledgementRequest entity 378A30C.

The FollowUpInvoiceRequest entity 378A40C includes a RequirementCodeentity 378A34C and an EvaluatedReceiptSettlementIndicator entity 378A50Cat the fourth level 378A08. There is zero or one 378A42CFollowUpInvoiceRequest entity 378A40C for each FollowUpMessage package378A08C. The RequirementCode entity 378A44C has a data type name“FollowUpMessageRequirementCode” 378A48C. There is one 378A46CRequirementCode entity 378A44C for a FollowUpInvoiceRequest entity378A40C. The EvaluatedReceiptSettlementIndicator entity 378A50C has adata type name “EvaluatedReceiptSettlementIndicator” 378A54C. There iszero or one 378A52C EvaluatedReceiptSettlementIndicator entity 378A50Cfor a FollowUpInvoiceRequest entity 378A40C.

The Item package 378A56C includes an Item entity 378A58C at the thirdlevel 378A06, a ProductInformation package 378A86C, a PriceInformationpackage 378A44D, a Party package 378A72D, a Location package 378A24E, aDeliveryInformation package 378A38E, a BusinessDocumentObjectReferencepackage 378A46E, an Attachment package 378A22F, a Description package378A36F, and a ScheduleLine package 378A50F.

The Item entity 378A58C has a data type name“PurchaseOrderInformationItem” 378A62C. There is any number of 378A60CItem entity 378A58C for each Item package 378A56C. The Item entity378A58C includes an ID entity 378A64C, a HierarchyRelationship entity378A70C, a ParentItemID entity 378A74C, and a TypeCode entity 378A80C atthe fourth level 378A08. The ID entity 378A64C has a data type name“BusinessTransactionDocumentItemID” 378A68C. There is one ID entity378A64C for an Item entity 378A58C. There is zero or one 378A72CHierarchyRelationship entity 378A70C for an Item entity 378A58C. TheParentItemID entity 378A74C has a data type name“BusinessTransactionDocumentItemID” 378A78C. There is one 378A76CParentItemID entity 378A74C for an Item entity 378A58C. The TypeCodeentity 378A80C has a data type name“BusinessTransactionDocumentItemHierarchyRelationshipTypeCode” 378A84C.There is one 378A82C TypeCode entity 378A80C for an Item entity 378A58C.

The ProductInformation package 378A86C includes a Product entity 378A88Cand a ProductCategory entity 378A26D at the fourth level 378A08.

The Product entity 378A88C has a data type name“BusinessTransactionDocumentProduct” 378A92C. There is zero or one378A90C Product entity 378A88C for each ProductInformation package378A86C. The Product entity 378A88C includes an InternalID entity378A94C, a StandardID entity 378A02D, a ManufacturerID entity 378A08D, aTypeCode entity 378A14D, and a Note entity 378A20D at the fifth level378A10. The InternalID entity 378A94C has a data type name“ProductInternalID” 378A98C. There is zero or one 378A96C InternalIDentity 378A94C for a Product entity 378A88C. The StandardID entity378A02D has a data type name “ProductStandardID” 378A06D. There is anynumber of 378A04D StandardID entity 378A02D for a Product entity378A88C. The ManufacturerID entity 378A08D has a data type name“ProductPartyID” 378A12D. There is zero or one 378A10D ManufacturerIDentity 378A08D for a Product entity 378A88C. The TypeCode entity 378A14Dhas a data type name “ProductTypeCode” 378A18D. There is zero or one378A16D TypeCode entity 378A14D for a Product entity 378A88C. The Noteentity 378A20D has a data type name “Note” 378A24D. There is zero or one378A22D Note entity 378A20D for a Product entity 378A88C.

The ProductCategory entity 378A26D has a data type name“BusinessTransactionDocumentProductCategory” 378A30D. There is zero orone 378A28D ProductCategory entity 378A26D for each ProductInformationpackage 378A86C. The ProductCategory entity 378A26D includes anInternalID entity 378A32D and a StandardID entity 378A38D at the fifthlevel 378A10. The InternalID entity 378A32D has a data type name“ProductCategoryInternalID” 378A36D. There is zero or one 378A34DInternalID entity 378A32D for a ProductCategory entity 378A26D. TheStandardID entity 378A38D has a data type name“ProductCategoryStandardID” 378A42D. There is any number of 378A40DStandardID entity 378A38D for a ProductCategory entity 378A26D.

The PriceInformation package 378A44D includes a Price entity 378A46D, aConfirmedPrice entity 378A56D, and a ProcurementCostUpperLimit entity378A66D at the fourth level 378A08. The Price entity 378A46D includes aNetUnitPrice entity 378A50D at the fifth level 378A10. There is zero orone 378A48D Price entity 378A46D for each PriceInformation package378A44D. The NetUnitPrice entity 378A50D has a data type name “Price”378A54D. There is zero or one 378A52D NetUnitPrice entity 378A50D for aPrice entity 378A46D. The ConfirmedPrice entity 378A56D includes aNetUnitPrice entity 378A60D at the fifth level 378A10. There is zero orone 378A58D ConfirmedPrice entity 378A56D for each PriceInformationpackage 378A44D. The NetUnitPrice entity 378A60D has a data type name“Price” 378A64D. There is zero or one 378A62D NetUnitPrice entity378A60D for a ConfirmedPrice entity 378A56D. TheProcurementCostUpperLimit entity 378A66D has a data type name“ProcurementCostUpperLimit” 378A70D. There is zero or one 378A68DProcurementCostUpperLimit entity 378A66D for each PriceInformationpackage 378A44D.

The Party package 378A72D includes a BuyerParty entity 378A74D, aSellerParty entity 378A80D, a ProductRecipientParty entity 378A86D, aVendorParty entity 378A92D, a ManufacturerParty entity 378A98D, aBillToParty entity 378A06E, a PayerParty entity 378A12E, and aCarrierParty entity 378A18E at the fourth level 378A08. The BuyerPartyentity 378A74D has a data type name “BusinessTransactionDocumentParty”378A78D. There is zero or one 378A76D BuyerParty entity 378A74D for eachParty package 378A72D. The SellerParty entity 378A80D has a data typename “BusinessTransactionDocumentParty” 378A84D. There is zero or one378A82D SellerParty entity 378A80D for each Party package 378A72D. TheProductRecipientParty entity 378A86D has a data type name“BusinessTransactionDocumentParty” 378A90D. There is zero or one 378A88DProductRecipientParty entity 378A86D for each Party package 378A72D. TheVendorParty entity 378A92D has a data type name“BusinessTransactionDocumentParty” 378A96D. There is zero or one 378A94DVendorParty entity 378A92D for each Party package 378A72D. TheManufacturerParty entity 378A98D has a data type name“BusinessTransactionDocumentParty” 378A04E. There is zero or one 378A02EManufacturerParty entity 378A98D for each Party package 378A72D. TheBillToParty entity 378A06E has a data type name“BusinessTransactionDocumentParty” 378A10E. There is zero or one 378A08EBillToParty entity 378A06E for each Party package 378A72D. ThePayerParty entity 378A12E has a data type name“BusinessTransactionDocumentParty” 378A16E. There is zero or one 378A14EPayerParty entity 378A12E for each Party package 378A72D. TheCarrierParty entity 378A18E has a data type name“BusinessTransactionDocumentParty” 378A22E. There is zero or one 378A20ECarrierParty entity 378A18E for each Party package 378A72D.

The Location package 378A24E includes a ShipToLocation entity 378A26Eand a ShipFromLocation entity 378A32E at the fourth level 378A08. TheShiptoLocation entity 378A26E has a data type name“BusinessTransactionDocumentShipToLocation” 378A30E. There is zero orone 378A28E ShiptoLocation entity 378A26E for each Location package378A24E. The ShipFromLocation entity 378A32E has a data type name“BusinessTransactionDocumentShipFromLocation” 378A36E. There is zero orone 378A34E ShipFromLocation entity 378A32E for each Location package378A24E.

The DeliveryInformation package 378A38E includes a DeliveryTerms entity378A40E at the fourth level 378A08. The DeliveryTerms entity 378A40E hasa data type name “DeliveryTerms” 378A44E. There is zero or one 378A42EDeliveryTerms entity 378A40E for each DeliveryInformation package378A38E.

The BusinessDocumentObjectReference package 378A46E includes aQuoteReference entity 378A48E, a PurchaseContractReference entity378A66E, an OriginPurchaseOrderReference entity 378A84E, and aBuyerProductCatalogueReference entity 378A04F at the fourth level378A08. The QuoteReference entity 378A48E has a data type name“BusinessTransactionDocumentReference” 378A52E. There is zero or one378A50E QuoteReference entity 378A48E for eachBusinessDocumentObjectReference package 378A46E. The QuoteReferenceentity 378A48E includes an ID entity 378A54E and an ItemID entity378A60E at the fifth level 378A10. The ID entity 378A54E has a data typename “BusinessTransactionDocumentID” 378A58E. There is one 378A56E IDentity 378A54E for a QuoteReference entity 378A48E. The ItemID entity378A60E has a data type name “BusinessTransactionDocumentItemID”378A64E. There is any number of 378A62E ItemID entity 378A60E for aQuoteReference entity 378A48E.

The PurchaseContractReference entity 378A66E has a data type name“BusinessTransactionDocumentReference” 378A70E. There is any number of378A68E PurchaseContractReference entity 378A66E for eachBusinessDocumentObjectReference package 378A46E. ThePurchaseContractReference entity 378A66E includes an ID entity 378A72Eand an ItemID entity 378A78E at the fifth level 378A10. The ID entity378A72E has a data type name “BusinessTransactionDocumentID” 378A76E.There is one 378A74E ID entity 378A72E for a PurchaseContractReferenceentity 378A66E. The ItemID entity 378A78E has a data type name“BusinessTransactionDocumentItemID” 378A82E. There is any number of378A80E ItemID entity 378A78E for a PurchaseContractReference entity378A66E.

The OriginPurchaseOrderReference entity 378A84E has a data type name“BusinessTransactionDocumentReference” 378A88E. There is zero or one378A86E OriginPurchaseOrderReference entity 378A84E for eachBusinessDocumentObjectReference package 378A46E. TheOriginPurchaseOrderReference entity 378A84E includes an ID entity378A90E and an ItemID entity 378A96E at the fifth level 378A10. The IDentity 378A90E has a data type name “BusinessTransactionDocumentID”378A94E. There is one 378A92E ID entity 378A90E for anOriginPurchaseOrderReference entity 378A84E. The ItemID entity 378A96Ehas a data type name “BusinessTransactionDocumentItemID” 378A02F. Thereis any number of 378A98E ItemID entity 378A96E for anOriginPurchaseOrderReference entity 378A84E.

The BuyerProductCatalogueReference entity 378A04F has a data type name“CatalogueReference” 378A08F. There is zero or one 378A06FBuyerProductCatalogueReference entity 378A04F for eachBusinessDocumentObjectReference package 378A46E. TheBuyerProductCatalogueReference entity 378A04F includes an ID entity378A10F and an ItemID entity 378A16F at the fifth level 378A10. The IDentity 378A10F has a data type name “CatalogueID” 378A14F. There is one378A12F ID entity 378A10F for a BuyerProductCatalogueReference entity378A04F. The ItemID entity 378A16F has a data type name“CatalogueItemID” 378A20F. There is any number of 378A1 8F ItemID entity378A16F for a BuyerProductCatalogueReference entity 378A04F.

The Attachment package 378A22F includes an AttachmentWebAddress entity378A24F and an InternalAttachmentWebAddress entity 378A30F at the fourthlevel 378A08. The AttachmentWebAddress entity 378A24F has a data typename “AttachmentWebAddress” 378A28F. There is any number of 378A26FAttachmentWebAddress entity 378A24F for each Attachment package 378A22F.The InternalAttachmentWebAddress entity 378A30F has a data type name“AttachmentWebAddress” 378A34F. There is any number of 378A32FInternalAttachmentWebAddress entity 378A30F for each Attachment package378A22F.

The Description package 378A36F includes a Description entity 378A38Fand an InternalDescription entity 378A44F at the fourth level 378A08.The Description entity 378A38F has a data type name “Description”378A42F. There is zero or one 378A40F Description entity 378A38F foreach Description package 378A36F. The InternalDescription entity 378A44Fhas a data type name “Description” 378A48F. There is zero or one 378A46FInternalDescription entity 378A44F for each Description package 378A36F.

The ScheduleLine package 378A50F includes a ScheduleLine entity 378A52Fand a ConfirmedScheduleLine entity 378A76F at the fourth level 378A08.The ScheduleLine entity 378A52F has a data type name“PurchaseOrderInformationItemScheduleLine” 378A56F. There is any numberof 378A54F ScheduleLine entity 378A52F for each ScheduleLine package378A50F. The ScheduleLine entity 378A52F includes an ID entity 378A58F,a DeliveryPeriod entity 378A64F, and a Quantity entity 378A70F at thefifth level 378A10. The ID entity 378A58F has a data type name“BusinessTransactionDucomentItemScheduleLineID” 378A62F. There is zeroor one 378A60F ID entity 378A58F for a ScheduleLine entity 378A52F. TheDeliveryPeriod entity 378A64F has a data type name “DateTimePeriod”378A68F. There is one 378A66F DeliveryPeriod entity 378A64F for aScheduleLine entity 378A52F. The Quantity entity 378A70F has a data typename “Quantity” 378A74F. There is zero or one 378A72F Quantity entity378A70F for a ScheduleLine entity 378A52F. The ConfirmedScheduleLineentity 378A76F has a data type name“PurchaseOrderInformationItemScheduleLine” 378A80F. There is any numberof 378A78F ConfirmedScheduleLine entity 378A76F for each ScheduleLinepackage 378A50F.

h) Tax Due Notification Interface

A TaxDueNotification interface is an interface that is used to transferinformation about the tax that is due in a company to a tax register.The tax register collects the company's receivables and payablesvis-a-vis the tax authorities (tax offices) responsible. Tax is declaredand the process of paying taxes triggered from the tax register inaccordance with legal time limits and requirements.

In the business scenarios SFS (Sale From Stock) and PTS (Procure ToStock), goods are sold to customers and goods are bought from suppliers.Depending on the country concerned, the outgoing invoices sent andincoming invoices received during this process identify the sales tax orsimilar tax that is transferred to the tax-register. From a taxperspective, credit memos are handled in the same way as invoices. Legalrequirements may also stipulate how a discount taken by the payer istreated for tax purposes. In accordance with methods and systemsconsistent with the subject matter described herein, a correction forthe outgoing or incoming payment may be transferred to the tax register.

(1) Message Type Tax Due Notification

Both the TaxDueNotification message and the TaxDueCancellationRequestare implemented or instantiated based on the message data typeTaxDueMessage.

(2) Message Choreography

FIG. 378 depicts the message choreography for a TaxDueNotificationinterface. The choreography involves two business entities: a taxdetermination or calculation entity 37802 and a tax register entity37804. The tax calculations entity 37802 and the tax register entity37804 each may be a department of a company, a separate business entityengaged by the company, or tax authorities (tax offices) that determineand calculate a company's taxes.

In the implementation shown in FIG. 378, the tax calculation entity37802 sends a “TaxDueNotification” message 37806 to the tax registerentity 37804 to transfer the data relevant for tax reports and taxpayments to the tax register 37804 of the company. The tax calculationentity 37802 may also send a “TaxDueCancellationRequest” message 37808to the tax register entity 37804 to transfer cancellations of invoices,credit memos, and payments previously sent to the tax register 37804 aspart of a TaxDueNotification message 37806.

(3) Message Data Type Tax Due Message

The data model for the message data type TaxDueMessage used to implementa TaxDueNotification message 37806 and a TaxDueCancellationRequestmessage 37808 is depicted in FIGS. 380. The message data typeTaxDueMessage includes a TaxDueMessage package 38000. The TaxDueMessagepackage 38000 includes a MessageHeader package 38002, a TaxDue package38004, and a TaxDueMessage object or entity 38006, which may be includedin the business document and the business information that is relevantfor sending a business document in a message.

(a) Message Header Package

A MessageHeader package 38002 groups the business information that isrelevant for sending a business document in a message. The MessageHeaderpackage 38002 is not required to implement the TaxDueNotificationmessage 37806. In one implementation, an invoice or credit memo may betransferred via a TaxDueNotification message 37806 to the tax register37804 once. In this implementation, a message ID in a Message Header isnot required, since the reference can be established with the ID of theinvoice or credit memo. In this implementation, the sender is known bythe “System ID.” Without a ReferenceID in the Message Header, therecipient of the TaxDueNotification message may not be identified withinthe associated Message Header. However, Invoice and Billing entities(e.g., Tax Calculation entities 37802) recognize that this message is tobe sent to the Tax Register 37804.

(b) Tax Due Package

The TaxDue package 38004 includes the summary of the information from abusiness document that is required for reporting or paying tax due tothe tax authorities. The TaxDue package 38004 includes a Party Package38008, a Tax Package 38010, an Item Package 38012, and a TaxDue entity38014. There is a 1:1 relationship 38016 between the TaxDueMessageentity 38006 and the TaxDue entity 38014.

(i) Tax Due

The TaxDue is the information from a business document that is requiredto report or pay due tax to the tax authorities. The TaxDue entity 38014includes information about the business partners subject to tax, the taxevents based to which the business partners are subject to tax/taxexempt, and about the type and amount of tax due.

As further described below, the TaxDue entity 38014 includes aBaseBusinessTransactionDocumentID, aBaseBusinessTransactionDocumentTypeCode, aBaseBusinessTransactionDocumentDate, and a ProductTaxEventTypeCode. TheBaseBusinessTransactionDocumentID is the identifier for the basebusiness document for the tax due date. TheBaseBusinessTransactionDocumentID also may be used for auditingpurposes, and is of type GDT: BusinessTransactionDocumentID. TheBaseBusinessTransactionDocumentTypeCode identifies the type of basebusiness document for the tax due date. Examples of such types of basebusiness documents include incoming and outgoing invoices, incoming andoutgoing credit memos, incoming and outgoing payments, and cancellationsof the types specified. The BaseBusinessTransactionDocumentTypeCode isof type GDT: BusinessTransactionDocumentTypeCode. TheBaseBusinessTransactionDocumentDate identifies the date of the basebusiness document for the tax due date. TheBaseBusinessTransactionDocumentDate depends on the type of businessdocument. For example, if the business document is an incoming invoiceor an outgoing invoice, the BaseBusinessTransactionDocumentDate is theinvoice date. If the business document is an incoming credit memo or anoutgoing credit memo, the BaseBusinessTransactionDocumentDate is thecredit memo date. If the business document is an Incoming payment, theBaseBusinessTransactionDocumentDate is the date of the incoming payment.Finally, if the business document is an outgoing payment, theBaseBusinessTransactionDocumentDate is date of the outgoing payment. TheBaseBusinessTransactionDocumentDate is of type GDT: Date. TheProductTaxEventTypeCode identifies the type of tax event thatcharacterizes the circumstances of the purchase, sale, or consumption ofa product. The ProductTaxEventTypeCode is based on country-specific taxlaws, such as the German turnover tax law (UStG), and is of type GDT:ProductTaxEventTypeCode.

(ii) Party Package

The Party Package 38008 groups together the business partners that aresubject to a tax or tax exemption because of their function in the taxevent. The Party Package 38008 includes a BuyerParty entity 38018, aSellerParty entity 38020, a ProductRecipientParty entity 38022, aVendorParty entity 38024, a DebitorParty entity 38020, and aCreditorParty entity 38028. The partners that represent the serviceprovider and the service recipient from a tax point of view may bespecified. In an invoice, the SellerParty typically identifies theservice provider and the BuyerParty typically identifies the servicerecipient. In a payment, the CreditorParty typically identifies theservice provider, and the DebitorParty typically identifies the servicerecipient. The attributes required for a tax report may be derived fromthe information about the business partners included in the PartyPackage 38008. These attributes are the VAT registration numbers andsimilar tax-relevant identification numbers for the business partners.

(a) Buyer Party

The BuyerParty identifies a company or a person that purchases goods orservices. The BuyerParty entity 38018 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38030between the TaxDue entity 38014 and the BuyerParty entity 38018. If aBuyerParty entity 38018 is not specified in an invoice, theProductRecipientParty entity 38022 may be considered to be the servicerecipient from a tax point of view and may therefore be specified.

(b) Seller Party

The SellerParty identifies a company or a person that sells goods orservices. The SellerParty entity 38020 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38032between the TaxDue entity 38014 and the SellerParty entity 38020. If aSellerParty entity 38020 is not specified in an invoice, the VendorPartyentity 38024 may be considered to be the service provider from a taxpoint of view and may therefore be specified.

(c) Product Recipient Party

The ProductRecipientParty identifies a company or a person to whom goodsare delivered or for whom services are provided. TheProductRecipientParty entity 38022 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38034between the TaxDue entity 38014 and the ProductRecipientParty entity38022.

(d) Vendor Party

The VendorParty identifies a company or a person that delivers goods orprovides services. The VendorParty entity 38024 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38036between the TaxDue entity 38014 and the VendorParty entity 38024.

(e) Debitor Party

The DebitorParty identifies a company or a person who owes money forgoods or services provided. The Debitorparty entity 38026 is of typeGDT: BusinessTransactionDocumentParty. There is a 1:c relationship 38038between the TaxDue entity 38014 and the DebitorParty entity 38026. In apayment, the DebitorParty entity 38026 may be considered to be theservice recipient from a tax point of view and may therefore bespecified.

(f) Creditor Party

The CreditorParty entity 38028 is a company or a person to whom money isowing for goods or services provided. The Creditorparty entity 38028 isof type GDT: BusinessTransactionDocumentParty. There is a 1:crelationship 38040 between the TaxDue entity 38014 and the CreditorPartyentity 38028. In a payment, the Creditorparty entity 38028 may beconsidered to be the service provider from a tax point of view and maytherefore be specified.

(iii) Tax Package

The Tax Package 38010 includes a summary of the information about typesand totals amounts of the tax in the base business document for the taxdue. The Tax Package 38010 includes a ProductTax entity 38042. TheProductTax entity 38042 is of type GDT: ProductTax. There is a 1:cnrelationship 38044 between the TaxDue entity 38014 and the ProductTaxentity 38042.

The ProductTax includes a description of the tax that is incurred whenproducts are purchased, sold, and consumed. If a ProductTax entity 38042is specified, the ProductTax entity 38042 represents totals of the taxbase amount and the tax amount, which are shown for specific countriesfor each tax type and tax rate. If total amounts are required by law,they are specified at the TaxDue entity 38014 level. Otherwise, theinformation about the tax due at the item entity level described belowis sufficient. The specified country (CountryCode) and jurisdiction code(JurisdictionCode) (usually required for the United States, Canada, andBrazil) also may apply at the item level of the TaxDueNotificationmessage. NonDeductibleAmount and NonDeductiblePercentage are filled if,in the case of incoming invoices and incoming credit memos, the entiretax amount cannot be claimed from the tax authorities (input taxdeduction). This is relevant for particular countries and tax types(VAT—value added tax). Triangulationindicator specifies whetherintra-community triangulation exists, as described under § 25b UStG (orunder the relevant paragraphs for the other member states of theEuropean Union).

In one implementation, the currency communicated in the ProductTaxentity 38042 entity from the tax calculation entity to the tax registerentity is the reporting currency. Thus, in this implementation, the taxcalculation entity determines the reporting currency.

(iv) Tax Due Item Package

The TaxDueItem (“Item”) package 38012 includes a summary of theinformation about tax due from the items in the base business documentfor the TaxDueNotification message. The Item package 38012 includes aTaxDueItemParty package 38046, a TaxDueItemTax package 38048, and aTaxDueItem entity 38050.

(a) Tax Due Item

The TaxDueItem identifies information from an item of a businessdocument that is required to report or pay due tax to the taxauthorities. The TaxDueItem entity 38050 includes information about thebusiness partners subject to tax, the tax events based on which thebusiness partners are subject to tax/tax exempt, and about the type andamount of tax due. There is a 1:cn relationship 38052 between the TaxDueentity 38014 and the TaxDueItem entity 38050.

The TaxDueItem entity 38050 includes aBaseBusinessTransactionDocumentItemID, aBaseBusinessTransactionDocumentItemTypeCode, aBaseBusinessTransactionDocumentItemDeliveryDate, and aProductTaxEventTypeCode as described herein. TheBaseBusinessTransactionDocumentItemID is the identifier for the item inthe base business document for the specified item in theTaxDueNotification message, and is of type GDT:BusinessTransactionDocumentItemID. TheBaseBusinessTransactionDocumentItemTypeCode identifies the type of itemspecified in the business document, and is of type GDT:BusinessTransactionDocumentItemTypeCode. TheBaseBusinessTransactionDocumentItemDeliveryDate identifies the date onwhich the invoiced quantity of a product was delivered, according to theitem in the base business document, and is of type GDT: Date.

When values are transferred at the item level in accordance with methodsand systems consistent with the subject matter described herein, the taxregister entity will then aggregate the data in line with legalrequirements. Aggregated data may be transferred at the document levelif permitted by legal requirements. TheBaseBusinessTransactionDocumentItemTypeCode may be specified if it has adifferent type to that of the base business document, for example, whenan invoice includes a credit memo item. In one implementation, theItemDeliveryDate is filled when required by law, such as in Germany,where the date on which the taxes are due to be paid to the tax officeis derived from the ItemDeliveryDate. In one implementation, theProductTaxEventTypeCode is filled when the tax event at item level isnot the “main” tax event specified above.

For each item in the base business document that is relevant for taxpurposes, there are one or more TaxDueItem entities 38050. For example,there may be several items if several tax types are due or if taxes aredue in several jurisdictions, as in the United States.

(b) Tax Due Item Party Package

Similar to the Party Package 38008, the TaxDueItemParty Package 38046includes a BuyerParty entity 38054, a SellerParty entity 38056, aProductRecipientParty entity 38058, a VendorParty entity 38060, aDebitorParty entity 38062, and a CreditorParty entity 38064. TheTaxDueItemParty package 38046 groups together the business partners thatdiffer from the business partners grouped together in the Party Package38008.

(c) Buyer Party

The BuyerParty entity 38054 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38066between the TaxDueItem entity 38050 and the BuyerParty entity 38054.

(d) Seller Party

The SellerParty entity 38056 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38068between the TaxDueItem entity 38050 and the SellerParty entity 38056.

(e) Product Recipient Party

The ProductRecipientParty entity 38058 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38070between the TaxDueItem entity 38050 and the ProductRecipientParty entity38058.

(f) Vendor Party

The VendorParty entity 38060 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38072between the TaxDueItem entity 38050 and the VendorParty entity 38060.

(g) Debitor Party

The DebitorParty entity 38062 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38074between the TaxDueItem entity 38050 and the DebitorParty entity 38062

(h) Creditor Party

The CreditorParty entity 38064 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 38076between the TaxDueItem entity 38050 and the CreditorParty entity 38064.

(i) Tax Due Item Tax Package

Similar to the Tax Package 38010, the TaxDueItemTax Package 38048includes a ProductTax entity 38078. The ProductTax entity 38078 is oftype GDT: ProductTax. There is a 1:n relationship 38080 between theTaxDueItem entity 38050 and the ProductTax entity 38078.

(4) Message Data Type Element Structure

FIGS. 381 A-D depict the element structure for a TaxDueNotification anda TaxDueCancellationRequest. The element structure is similar to theabove described data model of the message data type TaxDueMessage asreflected in FIG. 380, but provides additional information regarding thedetails for interfacing with or implementing a TaxDueMessage, such as aTaxDueNotification. As shown in FIGS. 381A-D, the element structureidentifies the different packages 38100 that may be in a respectiveTaxDueNotification and a TaxDueCancellationRequest. The elementstructure for the TaxDueNotification and a TaxDueCancellationRequestincludes four levels 38102, 38104, 38106, and 38108, each of which isassociated with a respective package 38100. The element structureidentifies the cardinality or occurrence 38110 and the data type 38112information for the elements at the respective levels 38102, 38104,38106, and 38108 in the respective package 38100.

The outermost package of this interface is a TaxDueMessage package38114, which includes a TaxDueMessage entity 38116 at the first level38102. The TaxDueMessage entity 38116 is of type GDT: TaxDueMessage38118.

The TaxDueMessage package 38114 also includes a TaxDue Package 38120.The TaxDue Package 38120 includes a TaxDue entity 38122. There is one38124 TaxDue entity 38122 for each The TaxDueMessage entity 38116. TheTaxDue entity 38122 is of type GDT: TaxDue 38126.

The TaxDue entity 38122 includes a BaseBusinessTransactionDocumentID38128, a BaseBusinessTransactionDocumentTypeCode 38134, aBaseBusinessTransactionDocumentDate 38140, and a ProductTaxEventTypeCode38146. The BaseBusinessTransactionDocumentID 38128 is of type GDT:BusinessTransactionDocumentID 38132. TheBaseBusinessTransactionDocumentTypeCode 38134 is of type GDT:BusinessTransactionDocumentTypeCode 38138. TheBaseBusinessTransactionDocumentDate 38140 is of type GDT: Date 38144.The ProductTaxEventTypeCode 38146 is of type GDT:ProductTaxEventTypeCode 38150. There is one 38130BaseBusinessTransactionDocumentID 38128 for each TaxDue entity 38122.There is one 38136 BaseBusinessTransactionDocumentTypeCode 38134 foreach TaxDue entity 38122. There is one 38142BaseBusinessTransactionDocumentDate 38140 for each TaxDue entity 38122.There is zero or one 38148 ProductTaxEventTypeCode 38146 for each TaxDueentity 38122.

The TaxDue package 38120 also includes a Party package 38152, a Taxpackage 38154, and an Item package 38156.

The Party package 38152 includes a BuyerParty entity 38158, aSellerParty entity 38164, a ProductRecipientParty entity 38170, aVendorParty entity 38176, a DebitorParty entity 38182, and aCreditorParty entity 38188. The BuyerParty entity 38158 is of type GDT:BusinessTransactionDocumentParty 38162. There is one or zero 38160BuyerParty entity 38158 for each TaxDue entity 38122. The SellerPartyentity 38164 is of type GDT: BusinessTransactionDocumentParty 38168.There is one or zero 38166 SellerParty entity 38164 for each TaxDueentity 38122. The ProductRecipientParty entity 38170 is of type GDT:BusinessTransactionDocumentParty 38174. There is one or zero 38172ProductRecipientParty entity 38170 for each TaxDue entity 38122. TheVendorParty entity 38176 is of type GDT:BusinessTransactionDocumentParty 38180. There is one or zero 38178VendorParty entity 38176 for each TaxDue entity 38122. The DebitorPartyentity 38182 is of type GDT: BusinessTransactionDocumentParty 38186.There is one or zero 38184 DebitorParty entity 38182 for each TaxDueentity 38122. The CreditorParty entity 38188 is of type GDT:BusinessTransactionDocumentParty 38192. There is one or zero 38190CreditorParty entity 38188 for each TaxDue entity 38122.

The Tax package 38154 includes a ProductTax entity 38194. The ProductTaxentity 38194 is of type GDT: ProductTax 38198. There is one ormore 38190ProductTax entities 38194 for each TaxDue entity 38122.

The Item package 38156 includes an Item entity 38100A. The Item entity38100A is of type GDT: TaxDueItem 38104A. There is one or more 38102AItem entities 38100A for each TaxDue entity 38122.

The Item entity 38100A includes a BaseBusinessTransactionDocumentItemID38106A, a BaseBusinessTransactionDocumentItemTypeCode 38112A, aBaseBusinessTransactionDocumentDeliveryDate 38118A, and aProductTaxEventTypeCode 38124A. TheBaseBusinessTransactionDocumentItemID 38106A is of type GDT:BusinessTransactionDocumentItemID 38110A. TheBaseBusinessTransactionDocumentItemTypeCode 38112A is of type GDT:BusinessTransactionDocumentItemTypeCode 38116A. TheBaseBusinessTransactionDocumentDeliveryDate 38118A is of type GDT: Date38122A. The ProductTaxEventTypeCode 38124A is of type GDT:ProductTaxEventTypeCode 38128A. There is one 38108ABaseBusinessTransactionDocumentItemID 38106A for each Item entity38100A. There is one or zero 38114ABaseBusinessTransactionDocumentItemTypeCode 38112A for each Item entity38100A. There is one or zero 38120ABaseBusinessTransactionDocumentDeliveryDate 38118A for each Item entity38100A. There is zero or one 38126A ProductTaxEventTypeCode 38124A foreach Item entity 38100A.

The Item package 38156 also includes a Party package 38130A (i.e., aTaxDueItemParty package) and a Tax package 38132A (e.g., aTaxDueItemParty package).

Similar to the Party package 38152 in the TaxDue package 38120, theTaxDueItemParty package 38130A includes a BuyerParty entity 38134A, aSellerParty entity 38140A, a ProductRecipientParty entity 38146A, aVendorParty entity 38152A, a DebitorParty entity 38158A, and aCreditorParty entity 38164A. The BuyerParty entity 38134A is of typeGDT: BusinessTransactionDocumentParty 38138A. There is one or zero38136A BuyerParty entity 38134A for each Item entity 38100A. TheSellerParty entity 38140A is of type GDT:BusinessTransactionDocumentParty 38144A. There is one or zero 38142ASellerParty entity 38140A for each Item entity 38100A. TheProductRecipientParty entity 38146A is of type GDT:BusinessTransactionDocumentParty 38150A. There is one or zero 38148AProductRecipientParty entity 38146A for each Item entity 38100A. TheVendorParty entity 38152A is of type GDT:BusinessTransactionDocumentParty 38156A. There is one or zero 38154AVendorParty entity 38152A for each Item entity 38100A. The DebitorPartyentity 38158A is of type GDT: BusinessTransactionDocumentParty 38162A.There is one or zero 38160A DebitorParty entity 38158A for each Itementity 38100A. The CreditorParty entity 38164A is of type GDT:BusinessTransactionDocumentParty 38168A. There is one or zero 38166ACreditorParty entity 38164A for each Item entity 38100A.

Similar to the Tax package 38154 in the TaxDue package 38120, theTaxDueItemTax package 38132A includes a ProductTax entity 38170A. TheProductTax entity 38170A is of type GDT: ProductTax 38174A. There is oneor more 38172A ProductTax entities 38170A for each Item entity 38100A.

i) Delivery Information

A DeliveryInformation provides information about the (planned) executionand execution status of an outbound delivery or an inbound delivery. Itcan result from a (confirmed) sales order, a (confirmed) purchase order,a (confirmed) forecast delivery schedule, or a shipping notification,and contains the deadlines to be defined, such as delivery creation,processing completion in the warehouse, goods movement posting, and soon. In this Interface, the term “delivery” refers to both inbound andoutbound deliveries, that is, the direction in which the goods flow isnot relevant for the interface structure described.

The motivating business scenarios for the DeliveryInformation interfaceare the “SellFromStock” and “ProcureToStock” scenarios. In the“SellFromStock” scenario, goods purchase orders are accepted by thecustomer and generate a request to Logistics to fulfill the order. Inthis scenario, the order is fulfilled by delivering the ordered goods tothe customer from a warehouse. A delivery request to the relevantwarehouse is generated, which results in a delivery to be executed. Theplanning system, for example, is informed about this delivery to beexecuted. At a certain point, delivery execution begins and the deliveryto be executed becomes the actual delivery, along with its variousprocessing stages. At various stages, information about the deliveryprocessing status is provided for the benefit of the applicationsinvolved (such as the sales order system or planning system). In thisway, for example, customers can use the sales order system to find outthe current status of their delivery and the best possible planneddelivery date on the basis of the latest data.

In the “ProcureToStock” scenario, goods are ordered from a vendor. Thepurchase order or confirmation of the purchase order by the vendorgenerates a request to Logistics to receive the goods on the required orconfirmed date and place them in storage. By sending a shipping noticevia the vendor, the request to the warehouse regarding quantities anddeadlines can be finalized further. Planning, for example, is informedabout this pending delivery. At a certain time, the goods arrive at thewarehouse and the pending delivery becomes the actual delivery, alongwith its various processing stages. At various stages, information aboutthe delivery processing status is provided for the benefit of theapplications involved (such as the planning system). It is possible touse the SAP Inventory Collaboration Hub (SAP ICH) to provide a vendorwith the current delivery status based on the most recent information.

DeliveryInformation is information about the (planned) execution and theexecution status of a delivery. The message type DeliveryInformation isbased on the message data type DeliveryInformationMessage. TheDeliveryInformation covers the entire delivery process. For example, thefollowing delivery statuses can be published: removed fromstorage/placed in storage; packed/unpacked; loaded/unloaded; and goodsissue posted/goods receipt posted. Methods and systems consistent withthe subject matter described herein use the package template for aBusinessTransactionDocument for an SCM Master Data depicted in FIG. 270Bto derive the DeliveryInformation interface.

(1) Message Choreography

FIG. 382 depicts a message choreography that describes a logicalsequence of messages that can be used to realize a scenario betweenSales (“CRM”) 38200, Fulfillment Coordination (“FC”) 38202, Supply ChainPlanning (“SCP”) 38204 and Supply Chain Execution (“SCE”) 38206. CRM38200 initially sends a SalesOrderFulfillmentRequest 38208 to FC 38202.The FC 38202 then sends a DeliveryExecutionRequest 38210 to SCE 38206.In response, SCE 38206 sends DeliveryInformation 38212 to FC 38202. FC38202 then sends DeliveryInformation 38214 to SCP 38204, and sendsDeliveryInformation 38216 to CRM 38200. The basis for the deliverycreation can be an external delivery request (MessageDeliveryRequest), ashipping notification (Message DespatchedDeliveryNotification) or themanual creation of a delivery. Information about the (planned) deliveryexecution and status is provided in messages of typeDeliveryInformation.

(2) Message Data Type Data Model

FIG. 383 depicts the data model for the DeliveryInformationMessage. Themessage data type DeliveryInformationMessage includes aDeliveryInformationMessage package 38300, which includes aDeliveryInformationMessage entity 38302. The DeliveryInformationMessagepackage 38300 also includes a MessageHeader package 38304 and a Deliverypackage 38306. The message data type DeliveryInformationMessage makesthe structure available for the message type DeliveryInformation andrelevant interfaces.

There is a 1:c relationship between entities in this Interface unlessotherwise noted herein or indicated in the Figures.

(a) Message Header Package

The MessageHeader package 38304 groups together the business informationthat is relevant for sending a business document in a message. It mayinclude a MessageHeader entity 38308, which groups together the businessinformation from the viewppoint of the sending application to identifythe business document in a message, information about the sender, andinformation about the recipient. The MessageHeader entity 38308 may bedivided up into a SenderParty 38310 and a RecipientParty 38312, and isof type GDT: BusinessDocumentMessageHeaderParty. The MessageHeaderentity 38308 may also include an ID, which is identification of thebusiness document in the technical message, and a CreationDateTime,which is creation date of the business document in the technicalmessage. A MessageHeader is optional.

(b) Delivery Package

The Delivery package 38306 groups together a Delivery entity 38314 andits packages: a DeliveryBusinessTransactionDocumentationReferencepackage 38316, a DeliveryParty package 38318; a DeliveryLocation package38320; a DeliveryExecution package 38322, a DeliveryTransportInformationpackage 38324, a DeliveryInformation package 38326, a DeliveryAttachmentpackage 38328, an DeliveryLog package 38330, a DeliveryItem package38332, and a DeliveryHandlingUnit package 38334. There is a 1:1relationship between the DeliveryInformationMessage entity 38302 and theDelivery entity 38314.

A Delivery is a planned or physical combination of goods that is to bemade available for transportation and, after transportation, receivedfor further use within a company. The Delivery entity 38314 is dividedinto delivery items (DeliveryItems), which describe the execution statusand performance period for delivering a quantity of a product or batch.References to relevant business documents can be specified for adelivery item. For the delivery as a whole, the ship-from/to location,transportation details, and any references to relevant businessdocuments can be specified alongside the delivering party, recipient,and transporting party.

A Delivery entity 38314 includes the attribute ActionCode and thefollowing elements: an ID, a VendorID, a TypeCode, a CreationDateTime, aLastChangeDateTime, a ThirdPartyDealIndicator, a ReturnesIndicator, aProductRecipientInitiatedActionIndicator, a GrossWeightMeasure, aNetWeightMeasure, a GrossVolumeMeasure, a GroupID, a WayBillID, aFreightInvoiceID, a DangerousGoodsIndicator, and a Note.

The ActionCode is a coded representation of an instruction to themessage recipient as to how he or she should process the deliverydocument electronically (new creation, change, or deletion). Only thestrict semantic with the ActionCodes “01” (Create), “02” (Change), and“03” (Delete) are supported. It might be necessary to change a deliverydue to quantity changes during picking, for example. The ActionCode isof type GDT: ActionCode.

The ID is a unique ID for a delivery assigned by the goods recipient andis of type GDT: BusinessTransactionDocumentID. The VendorID is a uniqueID for a delivery assigned by the vendor and is of a type GDT:BusinessTransactionDocumentID. The TypeCode is the type of delivery(inbound/outbound) and is of type GDT:BusinessTransactionDocumentTypeCode. The CreationDateTime is the date onwhich the delivery was created and is of type GDT: DateTime. TheLastChangeDateTime is the date on which the delivery was changed and isof type GDT: DateTime. The ThirdPartyDealIndicator is a display todenote that the delivery is part of a third-party scenerio and is oftype GDT: BusinessTransactionDocumentThirdPartyDealIndicator. TheReturnesIndicator specifies whether the delivery is a return delivery ornot and is of type GDT: ReturnsIndicator. TheProductRecipientInitiatedActionIndicator is specifies whether the actionspecified in the delivery was triggered by the goods recipient or not,and is of type GDT: PartyInitiatedActionIndicator. TheGrossWeightMeasure is the gross total weight of the delivery, and is oftype GDT: Measure. The NetWeightMeasure is the net total weight of thedelivery, and is of type GDT: Measure. The GrossVolumeMeasure is thegross total volume of the delivery, and is of type GDT: Measure. TheGroupID is the ID of the group to which the delivery belongs and is oftype GDT: BusinessTransactionDocumentGroupID. Deliveries with the samedelivery group can be processed together in subsequent processes, whichcan result in a display of deliveries that have been grouped together inone shipment. The WayBillID is a unique identifier for the bill oflading and is of type GDT: BusinessTransactionDocumentID. A bill oflading can be understood as a document that provides evidence ofcompletion of a freight contract by means of transportation of goodsfrom the Vendor to the ProductRecipient. The FreightInvoiceID is aunique ID of the freight invoice and is of type GDT:BusinessTransactionDocumentID. A freight invoice can be understood as aninvoice for the certified transportation of goods from Vendor toGoodsRecipient as specified in the bill of lading. TheDangerousGoodsIndicator is a specification as to whether or not thedelivery contains dangerous goods and is of type GDT:DangerousGoodsIndicator. The Note is a note for delivery and is of typeGDT: Note.

The values “Inbound Delivery” and “Outbound Delivery” are permitted asthe TypeCode. If the DeletedIndicator is set, the items do not have tobe transferred; they are implicitly classified as deleted.

(i) Delivery Businesss Transaction Document Reference package

The DeliveryBusinesssTransactionDocumentReference package 38316 groupstogether all business document references that can occur in the deliveryprocess. It includes an OutboundDeliveryReference entity 38336, anInboundDeliveryReference entity 38338 and a ShipmentReference entity38340.

An OutboundDeliveryReference 38336 is the reference to an outbounddelivery. The OutboundDeliveryReference 38336 is of type GDT:BusinessTransactionDocumentReference; however, only the ID is used. Invariations, the OutboundDeliveryReference 38336 is only specified in thecase of outbound deliveries if the predecessor document of the currentdelivery is also an outbound delivery. This can occur in the case of adelivery split.

An InboundDeliveryReference entity 38338 is the reference to an inbounddelivery. The InboundDeliveryReference entity 38338 is of type GDT:BusinessTransactionDocumentReference; however, only the ID is used. TheInboundDeliveryReference entity 38338 is only specified in the case ofinbound deliveries if the predecessor document of the current deliveryis also an inbound delivery. This occurs in particular in the case of ashipping notification that was previously sent by the vendor, or in thecase of a delivery split.

A ShipmentReference entity 38340 is the reference to a shipment. TheShipmentReference entity 38340 is of type GDT:BusinessTransactionDocumentReference. Shipment refers to the quantity ofgoods consolidated by the vendor at a shipping location that aretransported together on the delivery date to the recipient and unloadedat the point of destination.

(ii) Delivery Party Package

The DeliveryParty package 38318 groups together the business partnersthat can be involved in a business delivery process. The DeliveryPartypackage 38318 includes a BuyerParty entity 38342, a VendorParty entity38344, a ProductRecipientParty entity 38346, a CarrierParty entity38348, and a BillToParty entity 38350. The DeliveryParty package 38318may also include a SellerParty entity, a PayerParty entity, aBillFromParty entity, and a PayeeParty entity for deliveries without areference for an order. This data is normally entered or determined inthe base order and is not relevant for delivery processing. Inparticular, it cannot be changed while the delivery is being processed.

The BuyerParty entity 38342 is the company or person that/who bought theproducts specified in the delivery. The BuyerParty 38342 is type GDT:BusinessTransactionDocumentParty, whereby only the InternalID, theStandardID, and Address are used. Either the InternalID or the StandardID can be used; however, one of these IDs must be used. Due to variousoptions for ID use, all ID elements of the particular “Party” areoptional.

The VendorParty 38344 is the company or person who is to deliver goodsand is of type GDT: BusinessTransactionDocumentParty, whereby theInternalID, the StandardID, and Address are used. Either the InternalIDor the Standard ID can be used; however, one of these IDs must be used.Due to various options for ID use, all ID elements of the particular“Party” are optional. In a delivery process in supply chain execution,the address of the VendorParty 38344 is not intended to be used as theoutbound delivery address. The ShipFromLocation is intended for this. Animportant part of the VendorParty 38344 in the delivery process,however, is the specified contact person for any queries relating to adelivery.

The ProductRecipientParty 38346 is the company or person to which goodsare to be delivered and is of type GDT:BusinessTransactionDocumentParty, whereby the InternalID, theStandardID, and Address are used. Either the InternalID or the StandardID can be used; however, one of these IDs must be used. Due to variousoptions for ID use, all ID elements of the particular “Party” areoptional. In a delivery process in supply chain execution, the addressof the ProductRecipientParty entity 38346 is not intended to be used asthe delivery address. The ShipToLocation is provided for this purpose.

The CarrierParty 38348 is the company or person who transports the goodsand is of type GDT: BusinessTransactionDocumentParty, whereby theInternalID, the StandardID, and Address are used. Either the InternalIDor the Standard ID can be used; however, in some implementations, one ofthese IDs must be used. Due to various options for ID use, all IDelements of the particular “Party” are optional.

The BillToParty 38350 is the company or the person to whom the invoicefor the deliverd products is sent and is of type GDT:BusinessTransactionDocumentParty, whereby the InternalID, theStandardID, and Address are used.

(iii) Delivery Location Package

The DeliveryLocation package 38320 groups together the locations thatcan occur in a delivery process. It includes a ShipFromLocation entity38352, a TransshipmentLocation entity 38354 and a ShipToLocation entity38356. There is a 1:1 relationship between the Delivery entity 38314 andthe ShipFromLocation entity 38352. There is a 1:1 relationship betweenthe Delivery entity 38314 and the ShipToLocation entity 38356. TheShipFromLocation, TransshipmentLocation, and the ShipToLocation can beused to provide a detailed description of the flow of goods (between theship-from and ship-to location).

The ShipFromLocation is the place from which goods are shipped. TheShipFromLocation entity 38352 is of type GDT:BusinessTransactionDocumentLocation, whereby the InternalID, theStandardID, LoadingLocation, and Address are used. Either the InternalDor the Standard ID can be used. However, one of these IDs must be used.Due to the various options for ID use, all ID elements of the particular“Location” are optional.

The TransshipmentLocation is the location at which the deliveredproducts are transshipped on their way to the product recipient. TheTransshipmentLocation entity 38354 is type GDT:BusinessTransactionDocumentTransshipmentLocation, and the InternalID,the StandardID, UnLoadingLocation, LoadingLocation and Address are used.Either the InternalID or the Standard ID can be used. However, one ofthese IDs must be used. Due to the various options for ID use, all IDelements of the particular “Location” are optional.

The ShipToLocation is the location to which goods are shipped. TheShipToLocation entity 38356 is of type GDT:BusinessTransactionDocumentLocation, and the InternalID, the StandardID,UnloadingLocation, and Address are used. Either the InternalID or theStandard ID can be used. However, one of these IDs must be used. Due tothe various options for ID use, all ID elements of the particular“Location” are optional.

(iv) Delivery Execution Information Package

The DeliveryExecutionInformation package 38322 groups togetherinformation abou the (planned and actual) delivery execution. TheDeliveryExecutionInformation package 38322 includes a PlannedExecutionentity 38358 and ActualExecution entity 38360.

The PlannedExecution entity 38358 specifies information about theplanned period in which a certain delivery process is to be executed.The PlannedExecution entity 38358 contains the following elements:IssuePeriod, CarrierHandoverPeriod, and ArrivalPeriod. The IssuePeriodis the planned issue period of the delivery and is of type GDTDateTimePeriod. The CarrierHandoverPeriod is the planned period for thehandover of goods to the carrier is of type GDT DateTimePeriod. TheArrivalPeriod is the planned arrival period of delivery is of type GDTDateTimePeriod. In the case of an inbound delivery, the planned periodcan be based on the specifications of a vendor, for example, which havebeen transferred with the help of a shipping notification (MessageDespatchedDeliveryNotification).

The ActualExecution entity 38360 refers to information about the actualperiod or time in which a certain delivery process was executed. TheActualExecution entity 38360 contains the following elements:IssuePeriod, PickingPeriod, PackingPeriod, LoadingPeriod,YardDepartureDateTime, ShippingPeriod, YardArrivaIDateTime,UnloadingPeriod, UnpackingPeriod, PutawayPeriod, and ReceiptPeriod.

The IssuePeriod is the issue period for the complete delivery and is oftype CDT DateTimePeriod. The PickingPeriod is the picking period for thecomplete delivery and is of type GDT DateTimePeriod. The PackingPeriodis the packing period for the complete delivery and is of type GDTDateTimePeriod. The LoadingPeriod is the loading period for the completedelivery and is of type GDT DateTimePeriod. The YardDepartureDateTime isthe time of departure from an exclusive area outside of the warehousewhere vehicles are processed, are ready for processing, or are ready tobe picked up by an external carrier. The YardDepartureDateTime is oftype GDT: DateTime. The ShippingPeriod is the period in which goods areshipped (between ship-from location, ship-to location, and possiblytransshipment location) and is of type GDT: DateTimePeriod. TheYardArrivaIDateTime is the time of arrival at an exclusive area outsideof the warehouse where vehicles are processed, are ready for processing,or are ready to be picked up by an external carrier and is of type GDT:DateTime. The UnloadingPeriod is the unloading period for the completedelivery and is of type GDT DateTimePeriod. The UnpackingPeriod is theunpacking period for the complete delivery and is of type GDTDateTimePeriod. The PutawayPeriod is the putaway period for the completedelivery and is of type GDT DateTimePeriod. The ReceiptPeriod is thereceipt period for the complete delivery and is of type GDTDateTimePeriod.

As the times specified may only be valid for the complete delivery,periods can be specified. If, for example, one item is put away at 10o'clock, and a second item at 12 o'clock, the putaway period for thecomplete delivery is from 10 until 12 o'clock.

(v) Delivery Transport Information Package

The DeliveryTransportInformation package 38324 groups together thetransport information for a delivery. The DeliveryTransportInformationpackage 38324 includes a TransportMeans entity 38362 and aTransportTracking entity 38364.

The TransportMeans entity 38362 is the description of a means oftransport and can also include information for a more detailedidentification and is of type GDT: TransportMeans.

The TransportTracking entity 38364 delivers transport-relatedinformation that can be used for tracking deliveries, for example, ingoods deliveries and is of type GDT: TransportTracking.

(vi) Delivery Information Package

The DeliveryInformation package 38326 groups together all deliveryconditions that might be relevant in the context of the shippingnotification. The DeliveryInformation package 38326 includes a Incotermsentity 38366. Incoterms are commercial contract formulae for thedelivery conditions that correspond with the rules compiled by theInternational Chamber of Commerce (ICC). The Incoterms entity 38366 isof type GDT: Incoterms.

(vii) Deliverty Attachment Package

The DeliveryAttachment package 38328 groups together all the Attachmentinformation relating to the delivery. The DeliveryAttachment package38328 includes the AttachmentWebAddress entity 38368. TheAttachmentWebAddress entity 38368 is a reference to an Attachment and isof type GDT: WebAddress. There is a 1:cn relationship between theAttachmentWebAddress entity 38368 and the Delivery item 38314.

(viii) Delivery Log Package

The DeliveryLog Package 38330 groups together all the logs relating tothe delivery. The DeliveryLog Package 38330 includes the Validation Logentity 38370. The ValidationLog is a log for the logistics planning orlogistics execution process check. This checks the consistency of thedelivery data. The ValidationLog entity 38370 is of type GDT: Log.

(ix) Delivery Item Package

The DeliveryItem package 38332 groups together all the data thatdescribes the item of the delivery using a quantity of a product or abatch. It includes a DeliveryBusinessTransactionDocumentReferencepackage 38372, a DeliveryParty package 38374, aDeliveryProductInformation package 38376, a DeliveryBatch package 38378,DeliveryExecutionInformation package 38380, a DeliveryInformationpackage 38382, a DeliveryAttachment package 38384, and a DeliveryLogpackage 38386. The DeliveryItem package 38332 also includes aDeliveryItem entity 38388.

The DeliveryItem entity 38388 is a quantity of a product in the deliverythat contains additional information about its delivery processingstatus and any references to previous business documents. There is a 1:nrelationship between the Delivery entity 38314 and the DeliveryItementity 38388. The DeliveryItem entity 38388 includes an ID, a VendorID,a CreationDateTime, a LastChangeDateTime, a ConsignmentIndicator, aProductRecipientInitiatedActionIndicator, a CompletedIndicator, aShippedQuantityAccumulation, a ReceivedQuantityAccumulation, a GroupID,a PackingListID, a GrossWeightMeasure, a NetWeightMeasure, aGrossVolumeMeasure, a Quantity, optionally a variance of Quantity(includind a QuantityDiscrepancyCode), SalesOrderQuantity, aPurchaseOrderQuantity, an InventoryQuantity, a ReceivedQuantity,Dangerous Goods, and a Note.

The ID is a unique ID for a delivery item assigned by the goodsrecipient and is of type GDT: BusinessTransactionDocumentItemID. TheVendorID is a unique ID for a delivery item assigned by the vendor andis of type GDT: BusinessTransactionDocumentID. The CreationDateTime—thedate on which a delivery item was created and is of type GDT: DateTime.The LastChangeDateTime is the change date of a delivery item and is ofGDT: DateTime. The ConsignmentIndicator is the specification as towhether the item is or is not intended for the consignment stock and isof the type GDT: ConsignmentIndicator. TheProductRecipientInitiatedActionIndicator specifies whether the actionspecified in the delivery was triggered by the goods recipient or notand is of type GDT: PartyInitiatedActionIndicator. TheCompletedIndicator specifies whether the delivery item has beencompleted or not and is of type GDT: CompletedIndicator. Thisinformation can be used to find out, for example, if no more goodsreceipts are expected although only one part of the ordered quantity hasbeen notified or delivered. The ShippedQuantityAccumulation isinformation about cumulated shipped quantities of the product describedin the delivery item and is of type GDT: ShippedQuantityAccumulation.ShippedQuantityAccumulation may only be used for deliveries withinforecast delivery schedule scenarios. For this reason, references toscheduling agreement items must be made usingSchedulingAgreementReference. The ReceivedQuantityAccumulation isinformation about cumulated received quantities of the product describedin the delivery item and is of type GDT: ReceivedQuantityAccumulation.ReceivedQuantityAccumulation may only be used for deliveries withinforecast delivery schedule scenarios. For this reason, references toscheduling agreement items must be made usingSchedulingAgreementReference. The GroupID is the ID of the deliverygroup to which the delivery item belongs and is of type GDT:BusinessTransactionDocumentItemGroupID. Delivery items with the samedelivery group can be processed together in subsequent processes. It isthus possible to display delivery items that have been grouped togetherin one shipment. The PackingListID is a unique ID for the packing listwith the packing specifications for the products from one or moredelivery items and is of type GDT: PackingListID. More than one packinglist can exist for each delivery. However, only packing-relevantdelivery items must be listed in the packing lists. TheGrossWeightMeasure is the gross weight of products in the delivery itemand is of type GDT: Measure. The NetWeightMeasure is the net weight ofproducts in the delivery item and is of type GDT: Measure. TheGrossVolumeMeasure is the gross volume of products in the delivery itemis of type GDT: Measure. The Quantity is the delivery quantity indelivery unit of measure and is of type GDT: Quantity. TheSalesOrderQuantity is the delivery quantity in sales unit of measure andis of type GDT: Quantity The PurchaseOrderQuantity is the deliveryquantity in purchase unit of measure and is of type GDT: Quantity. TheInventoryQuantity the delivery quantity in inventory unit of measure andis of type GDT: Quantity. The ReceivedQuantity is the delivery quantityposted in goods receipt in delivery unit of measure and is of type GDT:Quantity. The Dangerous Goods is a classification of dangerous goods inthe delivery item and is of type GDT: DangerousGoods. The Note is a notefor item of the delivery and is of the type GDT: Note.

Optionally, a Variance exists for Quantity. The Variance includes thefollowing elements: Quantity and QuantityDiscrepancyCode. The Quantityis the quantity deviation from the shipping notification (difference)and is of type GDT: Quantity. This is specified without a plus/minussign. One can tell whether too much or too little was delivered from thefollowing QuantityDiscrepancyCode. The QuantityDiscrepancyCode is acoded representation of the type of and reason for the discrepancy forthe received product, and is of the type GDT: QuantityDiscrepancyCode.

The DeliveryItemBusinessTransactionDocumentReference package 38372groups together all the business document references that can occur inthe delivery process for a delivery item or product that has beendelivered. The DeliveryItemBusinessTransactionDocumentReference package38372 includes a PurchaseOrderReference entity 38390, aOriginPurchaseOrderReference entity 38392, aSchedulingAgreementReference entity 38394, a SalesOrderReference entity38396, and a ShipmentReference entity 38398.

A PurchaseOrderReference entity 38390 is the reference to a purchaseorder or an item in a purchase order and is of type GDT:BusinessTransactionDocumentReference. The PurchaseOrderReference entity38390 contains the purchase order number and purchase order item numberspecified by the purchaser or purchasing system. ThePurchaseOrderReference entity 38390 contains the reference to the basepurchase order item to which the delivery item refers. This reference(if it exists) must always be unique. For this reason, theSalesOrderReference entity 38396 must not be filled when thePurchaseOrderReference entity 38390 is specified.

An OriginPurchaseOrderReference entity 38392 is the reference to theoriginal purchase order or to an item within the original purchase orderand is of type GDT: BusinessTransactionDocumentReference. TheOriginPurchaseOrderReference entity 38392 may only be used forthird-party purchase orders. The OriginPurchaseOrderReference entity38392 is used in all the purchase orders in a third-party deal, so thatthe seller or vendor can reference the original purchase order of theProductRecipientParty entity 38346 with the OriginPurchaseOrderReferenceentity 38392 when the delivery is made.

A SchedulingAgreementReference entity 38394 is the reference to anoutline agreement item and is of type GDT:BusinessTransactionDocumentReference. According to the rules of theoutline agreement, products are procured on predefined dates within atime period.

A SalesOrderReference entity 38396 is the reference to an item in asales order and is of type GDT: BusinessTransactionDocumentReference.The SalesOrderReference entity 38396 contains the unique order numberassigned by the seller or sales system. The SalesOrderReference entity38396 contains the reference to the base order item to which thedelivery item refers. This reference (if it exists) must always beunique. For this reason, the PurchaseOrderReference entity 38390 mustnot be filled when the SalesOrderReference entity 38396 is specified.

A ShipmentReference entity 38398 is the reference to a shipment and isof type GDT: BusinessTransactionDocumentReference. If the items in adelivery can be assigned to the items in a shipment, the correspondingreference is specified only at this point and not in theDeliveryInformation package 38326 in the Delivery package 38306.

The DeliveryItemParty package 38374 groups together the businesspartners that might be relevant in a delivery item. TheDeliveryItemParty package 38374 includes a BuyerParty entity 38300A.

A BuyerParty entity 38300A is the company or person that bought theproduct specified in the delivery item and is type GDT:BusinessTransactionDocumentParty, whereby the InternalID, theStandardID, and Address are used. Either the InternalD or the StandardID can be used. However, one of these IDs must be used. Due to thevarious options for ID use, all ID elements of the particular “Party”are optional. In the case of BuyerParty entity 38300A, a default logicexists at header level for the items. This means that the BuyerPartyentity 38300A specified at header level is valid for all items as longas the information specified at item level does not contradict this.

The DeliveryItemProductInformation package 38376 groups together all theinformation for identifying and describing a product in a delivery item.The DeliveryItemProductInformation package 38376 includes a Productentity 38302A. The Product entity 38302A identifies and describes theproduct that is to be delivered/that has already been delivered and isof type GDT: BusinessTransactionDocumentProduct, whereby the InternalID,the StandardID, and the ChangeID are used. Either the InternalID or theStandard ID can be used. However, one of these IDs must be used. Due tothe various options for ID use, both of the ID elements in “Product” areoptional. There is a 1:1 relationship between a Product entity 38302Aand a DeliveryItem entity 38388.

The DeliveryItemBatch package 38378 groups together all the informationthat identifies and describes a batch in a delivery item. TheDeliveryItemBatch package 38378 includes a Batch entity 38304A.

A Batch entity 38304A is a batch in the delivery item and includes thefollowing elements: an InternalID, a ManufacturingDate, aBestBeforeDate, and an OriginCountryCode. The InternalID is aproprietary identifier for the batch and is of type GDT: BatchID. TheManufacturingDate is the date of manufacture of the batch and is of typeGDT: Date. The BestBeforeDate is the best-before date of the batch andis of type GDT: Date. The OriginCountryCode is a coded representation ofcountry of origin of the batch and is of type GDT: CountryCode.

The DeliveryInformation package 38382 is the summary of deliveryinformation about a product. The DeliveryInformation package 38382includes a Variance entity 38308A. The Variance entity 38308A describesa variance in the received quantity of a product and the type of andreason for the variance.

The Variance entity 38308A includes the following elements: Quantity andQuantityDiscrepancyCode. The Quantity is the quantity deviation from theshipping notification (difference) is of type GDT: Quantity. This isspecified without a plus/minus sign. One can tell whether too much ortoo little was delivered from the following QuantityDiscrepancyCode. TheQuantityDiscrepancyCode is the coded representation of the type of andreason for the discrepancy for the received product and is of type GDT:QuantityDiscrepancyCode.

A DeliveryItemExecution package 38380 groups together information aboutthe (planned and actual) execution of a delivery item. TheDeliveryItemExecution package 38380 includes an ActualExecution entity38306A.The ActualExecution entity 38306A refers to information about theactual period or time in which a certain process of a delivery item wasexecuted.

The ActualExecution entity 38306A contains the following elements:IssuePeriod, PickingPeriod, PackingPeriod, LoadingPeriod,UnloadingPeriod, UnpackingPeriod, PutawayPeriod, and RecipientPeriod.The IssuePeriod is the issue time/period for the delivery item and is oftype GDT DateTimePeriod. The PickingPeriod is the picking period for thedelivery item and is of type GDT DateTimePeriod. The PackingPeriod isthe packing period for the delivery item and is of type GDTDateTimePeriod. The LoadingPeriod is the loading period for the deliveryitem and is of type GDT DateTimePeriod. The UnloadingPeriod is theunloading period for the delivery item and is of type GDTDateTimePeriod. The UnpackingPeriod is the unpacking period for thedelivery item and is of type GDT DateTimePeriod. The PutawayPeriod isthe putaway period for the delivery item and is of type GDTDateTimePeriod. The ReceiptPeriod is the receipt time/period for thedelivery item and is of type GDT DateTimePeriod.

As the times specified may only be valid for the complete delivery item,periods and not times can be partly specified here. If, for example, ahandling unit for an item is put away at 10 o'clock, and a second at 12o'clock, the putaway period for the complete delivery item is from 10until 12 o'clock.

The DeliveryItemAttachment package 38384 groups together Attachmentinformation relating to the delivery item. The DeliveryItemAttachmentpackage 38384 includes an AttachmentWebAddress entity 38310A. TheAttachmentWebAddress entity 38310A is a reference to an Attachment andis of type GDT: WebAddress. There is a 1:cn relationship between theAttachmentWebAddress entity 38310A and a DeliveryItem entity 38388.

The DeliveryItemLog package 38386 groups together logs relating to adelivery item. The DeliveryItemLog package 38386 includes aValidationLog entity 38312A.

The ValidationLog is a log for the process of the logistics planning orlogistics execution check of a delivery item and is of type GDT: Log.

(x) Delivery Handling Unit Package

The DeliveryHandlingUnit package entity 38334 groups together theinformation that characterizes in detail how the delivery is packed oris to be packed. The DeliveryHandlingUnit package entity 38334 includesa HandlingUnit entity 38314A.

A HandlingUnit entity 38314A is a physical unit of packaging materials(load carrier, additional packaging materials) and the packaged products(of type “material”) and is of type GDT: HandlingUnit. There is a 1:cnrelationship between HandlingUnit entity 38314A and a DeliveryItementity 38388.

(3) Element Structure of Delivery Information Message

The message data type element structure for the delivery informationmessage is depicted in FIG. 384A-K. The element structure is similar tothe data model, but provides additional information regarding thedetails of the interface. The element structure identifies the differentpackages 38400 in the interface, and represents the entities at variouslevels within the interface. The interface loan contract create requestmessage includes six five 38402, 38404, 38406, 38408, and 38410. Asdepicted in 384A, the outermost package of this interface is aDeliveryInformationMessage 38416 package 38418, which includes aDelivery Information Message 38418 at the first level with the nameDelivery Information 38420. A MessageHeader package 38422 is alsoincluded at the second level. The MessageHeader package 38422 includes aMessageHeader entity 38426 with a cardinality of zero or one 38428, andthe name MessageHeader 38430. The MessageHeader entity 38426 includes anID entity 38440E, a CreationDate Time entity 38446E, and a SenderPartyentity 38452E. The ID entity 38440E has a cardinality of one 38442E, andthe name is MessageID 38444E. The CreationDate Time entity 38446E has acardinality of one 38448E, and the name is DateTime 38450E. TheSenderParty entity 38452E has a cardinality of zero or one 38454E, andthe name is BusinessDocumentMessageHeaderParty 38456E. The SenderPartyentity 38452E includes an InternalID entity 38458E and a StandardIDentity 38464E. The InternalID entity 38458E has a cardinality of zero orone 38460E, and the name is PartyInternalID 38462E. The StandardIDentity38464E has a cardinality of zero or one 38466E, and the name isPartyStandardID 38468E. The MessageHeader package 38422 also includes aRecipientParty entity 38470E at the third level 38406 with thecardinality of zero or one 38472E and the nameBusinessDocumentMessageHeaderParty 38474E. The RecipientParty entity38470E includes an InternalID entity 38476E and a StandardID entity38482E at the fourth level 38408. The InternalID entity 38476E has acardinality of zero or one 38478E and the name is PartyInternalID38480E. The StandardID entity 38482E has a cardinality of zero or one38484E and the name is PartyStandardID 38486E.

As depicted in FIG. 384B, the DeliveryInformationMessage package 38416includes a Delivery package 38424. The Delivery package 38424 includes aDelivery entity 38432 at the first level 38402 with a cardinality of one38434. The Delivery entity 38432 includes an actionCodeID entity 38448,an ID entity 38436, a VendorID entity 38488E, a TypeCode entity 38442, aCreationDateTime entity 38454, a LastChangeDateTime entity 38460, aThirdPartyDealIndicator entity 38488E, and a ReturnsIndicator entity38494E. The actionCodeID entity 38448 has a cardinality of zero or one38450, and the name is ActionCode 38452. The ID entity 38436 has acardinality of one 38438, and the name is BusinessTransaction DocumentID38440. The VendorID entity 38488Ehas a cardinality of zero or one38490E, and the name is BusinessTransaction DocumentID 38492E. TheTypeCode entity 38442 has a cardinality of one 38444, and the name isBusinessTransaction DocumentTypeCode 38446. The CreationDateTime entity38454 has a cardinality of one 38456, and the name is DateTime 38458.The LastChangeDateTime entity 38460 has a cardinality of zero or one38462, and the name is DateTime 38464. The ThirdPartyDealIndicatorentity 38488E has a cardinality of zero or one 38490E, and the name isBusinessTransactionDocumentThirdPartyDealIndicator 38492E. TheReturnsIndicator entity 38494E has a cardinality of zero or one 38496E,and the name is ReturnsIndicator 38498E.

As depicted in FIG. 384C, the Delivery package 38424 also includes aVendorIndicatedActionIndicator entity 38460, a GroupID entity 38466, aGrossWeightMeasure entity 38472, a NetWeightMeasure entity 38478, aGrossVolumeMeasure entity entity 38484, a WayBillID entity 38400F, aFreightInvoiceID entity 38406F, a DangerousGoodsIndicator entity 38412F,and a Note 38400H. The VendorlndicatedActionIndicator entity 38460 has acardinality of zero or one 38462 and the name is PartyInitiatedActionIndicator 38464. The GroupID entity 38466 has a cardinality of zero orone 38468 and the nameis BusinessTransaction DocumentGroupID 38470. TheGrossWeightMeasure entity 38472 has a cardinality of zero or one 38474and the name is Measure 38476. The NetWeightMeasure entity 38478 has acardinality of zero or one 38480 and the name is Measure 38482. TheGrossVolumeMeasure entity 38484 has a cardinality of zero or one 38486and the name is Measure 38488. The WayBillID entity 38400F has acardinality of zero or one 38402F and the name is BusinessTransactionDocumentID 38404F. The FreightInvoiceID entity 38406F has a cardinalityof zero or one 38408F and the name is BusinessTransaction DocumentID38410F. The DangerousGoodsIndicator entity 38412F has a cardinality ofzero or one 38414F and the name is DangerousGoodsIndicator 38416F. TheNote 38400H has a cardinality of zero or one 38402H and the name is Note38404H.

As depicted in FIG. 384D, the DeliveryInformationMessage 38416 includesa PlannedExecution entity 38406A at the third level 38406 with acardinality of zero or one 38408A. The PlannedExecution entity 38406Aincludes an IssuePeriod entity 38410A, a CarrierHandoverPeriod entity38416A, an ArrivalPeriod entity 38422A, and a ReceiptExecutionStatusCode entity 38434A. The IssuePeriod entity 38410A has acardinality of zero or one 38412A and the name is DateTimePeriod 38414A.The CarrierHandoverPeriod entity 38416A has a cardinality of zero or one38418A and the name is DateTimePeriod 38420A. The ArrivalPeriod entity38422A has a cardinality of zero or one 38424A and the name isDateTimePeriod 38426A.

The DeliveryInformationMessage 38416 also includes an ActualExecutionentity 38440A at the third level 38406 with a cardinality of zero or one38442A. The ActualExecution entity 38440A includes a PickingPeriodentity 38444A, an IssuePeriod entity 38450A, a PackingPeriod entity38456A, a PutawayPeriod entity 38462A, and a ReceiptPeriod entity38468A. The PickingPeriod entity 38444A has a cardinality of zero or one38446A and the name is DateTimePeriod 38448A. The IssuePeriod entity38450A has a cardinality of zero or one 38452A and the name isDateTimePeriod 38454A. The PackingPeriod entity 38456A has a cardinalityof zero or one 38458A and the name is DateTimePeriod 38460A. ThePutawayPeriod entity 38462A has a cardinality of zero or one 38464A andthe name is DateTimePeriod 38466A. The ReceiptPeriod entity 38468A has acardinality of zero or one 38470A and the name is DateTimePeriod 38472A.

As depicted in FIG. 384E, the DeliveryInformationMessage package 38416includes an Execution Information package 38490. The ExecutionInformation package 38490 includes a LoadingPeriod entity 38418F, aYardDepartureDateTime entity 38424F, a ShippingPeriod entity 38430F, aYardArrivaIDateTime entity 38436F, an UnloadingPeriod entity 38442F andan UnpackingPeriod entity 38448F. The LoadingPeriod entity 38418F has acardinality of zero or one 38420F and the name is DateTimePeriod 38422F.The YardDepartureDateTime 38424F has a cardinality of zero or one 38426Fand the name is DateTimePeriod 38428F. The ShippingPeriod 38430F has acardinality of zero or one 38432F and the name is DateTimePeriod 38434F.The YardArrivaIDateTime 38436F has a cardinality of zero or one 38438Fand the name is DateTimePeriod 38440F. The UnloadingPeriod 38442F has acardinality of zero or one 38444F and the name is DateTimePeriod 38446F.The UnpackingPeriod 38448F has a cardinality of zero or one 38450F andthe name is DateTimePeriod 38452F.

As depicted in FIG. 384F, the DeliveryInformationMessage package 38416includes a Party package 38492. The Party package 38492 includes aBuyerParty entity 38474A with a cardinality of zero or one 38476A andthe name BusinessTransactionDocumentParty 38478A. The BuyerParty entity38474A includes an InternalID entity 38480A, an Address entity 38486A,and a StandardID entity 38492A. The InternalID entity 38480A has acardinality of zero or one 38482A and the name is PartyInternalID38484A. The Address 38486A has a cardinality of zero or one 38488A andthe name is Address 38490A. The StandardID 38492A has a cardinality ofzero or one 38494A and the name is PartyStandardID 38496A.

The Party package 38492 also includes a VendorParty entity 38410B with acardinality of zero or one 38414B and the nameBusinessTransactionDocumentParty 38416B. The VendorParty 38410B includesan InternalID entity 38498A, an Address entity 38404B, and a StandardIDentity 38412A. The InternalID entity 38498A has a cardinality of zero orone 38400B and the name is PartyInternalID 38402B. The Address entity38404B has a cardinality of zero or one 38406B and the name is Address38408B. The StandardID entity 38412A has a cardinality of zero or one38430F and the name is PartyStandardID 38432F. The Party package 38492also includes a ProductRecipientParty entity 38434F, a CarrierPartyentity 38442F, and a BillToParty 38450F. The ProductRecipientPartyentity 38434F has a cardinality of zero or one 38438F and the name isBusinessTransactionDocumentParty 38440F. The CarrierParty entity 38442Fhas a cardinality of zero or one 38446F and the name isBusinessTransactionDocumentParty 38448F. The BillToParty entity 38450Fhas a cardinality of zero or one 38454F and the name isBusinessTransactionDocumentParty 38456F.

As depicted in FIG. 384G, the DeliveryInformationMessage package 38416includes a Location package 38494. The Location package 38494 includes aShipFromLocation entity 38426B at the third level 38406 with acardinality of zero or one 38428B and the nameBusinessTransactionDocumentLocation 38430B. The ShipFromLocation entity38426B includes an InternalID entity 38432B, a StandardID entity 38458F,a LoadingLocation entity 38464F, and an Address entity 38438B. TheInternalID entity 38432B has a cardinality of zero or one 38434B and thename is LocationInternalID 38436B. The StandardID entity 38458F has acardinality of zero or one 38460F and the name is LocationInternalID38462F. The LoadingLocation entity 38464F has a cardinality of zero orone 38466F. The LocationInternalID entity 38462F includes an InternalIDentity 38468F and a StandardID entity 38474F. The InternalID entity38468F has a cardinality of zero or one 38470F and the name isLocationInternalID 38472F. The StandardID entity 38474F has acardinality of zero or one 38476F and the name is LocationInternalID38478F. The Address entity 38438B has a cardinality of zero or one38440B and the name is Address 38442B.

The Location package 38494 also includes a TransshipmentLocation entity38444B and a ShipToLocation entity 38450B. The TransshipmentLocationentity 38444B has a cardinality of zero or one 38448B and the name isBusinessTransaction DocumentLocation 38480F. The ShipToLocation 38450Bhas a cardinality of zero or one 38454B and the name isBusinessTransaction DocumentLocation 38456B.

As depicted in FIG. 384H, the Delivery package 38424 includes aTransportation Information package 38496, aBusinessTrans-actionDocumentReference package 38498, an Attachmentpackage 38400A, a Log package 38402A, a HandlingUnit package 38408G, anda DeliveryInformation package 38404A. The Transportation Informationpackage 38496 includes a TransportMeans entity 38458B and aTransportTracking entity 38480G. The TransportMeans entity 38458B has acardinality of zero or one 38460B and the name is TransportMeans 38462B.The TransportTracking entity 38480G has a cardinality of zero or one38480H and the name is TransportTracking 38480I. TheBusinessTrans-actionDocumentReference 38498 includes anOutboundDeliveryReference entity 38464B, an InboundDeliveryReferenceentity 38482F, and a ShipmentReference entity 38470B. TheOutboundDeliveryReference entity 38464B has a cardinality of zero or one38466B and the name is BusinessTransaction DocumentReference 38468B. TheInboundDeliveryReference entity 38482F has a cardinality of zero or one38484F and the name is BusinessTransaction DocumentReference 38486F. TheShipmentReference entity 38470B has a cardinality of zero or one 38472Band the name is BusinessTransactionDocumentReference 38474B. TheAttachmentWebAddress entity 38476B may have any number 38478B ofAttachmentWebAddress entities 38476B for a Delivery package 38424 andthe name is WebAddress 38480B. The ValidationLog entity 38482B may haveany number 38484B of ValidationLog entities 38482B for a Deliverypackage 38424 and the name is Log 38486B. The HandlingUnit entity 38410Gmay have any number 384712G of HandlingUnit entities 38410G for aDelivery package 38424 and the name is HandlingUnit 38414G. TheIncoTerms entity 38488B has a cardinality of zero or one 38490B and thename is IncoTerms 38488F.

As depicted in FIG. 384I, the Delivery package 38424 includes aDeliveryItem package 38404A. The DeliveryItem package 38404A includes anItem entity 38490F with a cardinality of any number 38492F of Itementities 38490 for a Delivery Item and named DeliveryItem_Information38494F. The Item entity 38490F includes an ID entity 38492B, aCreationDateTime entity 38404C, a LastChangeDateTime entity 38410C, aConsignmentIndicator entity 38498B, a VendorInitiatedActionIndicatorentity 38404C, a CompletedIndicator entity 38496F,aShippedQuantityAccumulation entity 38402G, and aReceivedQuantityAccumulation entity 38406G. The ID entity 38492B has acardinality of one 38494B and the name isBusinessTransactionDocumentItemID 38496B. The CreationDateTime entity38404C has a cardinality of one 38406C and the name is DateTime 38408C.The LastChangeDateTime entity 38410C has a cardinality of zero or one38412C and the name is DateTime 38414C. The ConsignmentIndicator entity38498B has a cardinality of zero or one 38400C and the name isConsigmnentIndicator 38402C. The VendorInitiatedActionIndicator entity38404C has a cardinality of one 38406C and the name isPartyInitiatedActionIndicator 38408C. The CompletedIndicator entity38496F has a cardinality of zero or one 38498F and the name isCompletedIndicator 38400G. The ShippedQuantityAccumulation entity 38402Ghas a cardinality of zero or one 38404G. TheReceivedQuantityAccumulation entity 38406G has a cardinality of zero orone 38408G.

As depicted in FIG. 384J, the DeliveryItem package 38404A includes aGroupID 38416C, a PackingListID 38414G, a GrossWeightMeasure 38420G, aNetWeightMeasure 38426G, a GrossVolumeMeasure 38432G, a Quantity 38438G,a SalesOrderQuantity 38444G, a PurchaseOrderQuantity 38450G, anInventoryQuantity 38456G, and a ReceivedQuantity 38462C. The GroupID38416C has a cardinality of zero or one 38418C and the name isBusinessTransactionDocumentItemGroupID 38420C. The PackingListID 38414Ghas a cardinality of zero or one 38416G and the name is PackingListID38418G. The GrossWeightMeasure 38420G has a cardinality of zero or one38422G and the name is Measure 38424G. The NetWeightMeasure 38426G has acardinality of zero or one 38428G and the name is Measure 38430G. TheGrossVolumeMeasure 38432G has a cardinality of zero or one 38434G andthe name is Measure 38436G. The Quantity 38438G has a cardinality of one38440G and the name is Quantity 38442G. The SalesOrderQuantity 38444Ghas a cardinality of zero or one 38446G and the name is Quantity 38448G.The PurchaseOrderQuantity 38450G has a cardinality of zero or one 38452Gand the name is Quantity 38454G. The InventoryQuantity 38456G has acardinality of zero or one 38458G and the name is Quantity 38460G. TheReceivedQuantity 38462C has a cardinality of zero or one 38464C and thename is Quantity 38466C.

As depicted in FIG. 384K, the DeliveryInformationMessage package 38416includes an Execution Information package 38468C. The ExecutionInformation package 38468C includes an ActualExecution entity 38480Cwith a cardinality of zero or one 38482C. The ActualExecution entity38480C includes an IssuePeriod 38484C, a PickingPeriod 38490C, aPackingPeriod 38496C, a LoadingPeriod 38402D, a YardDepartureDateTime38408D, a ShippingPeriod 38414D, a YardArrivaIDateTime 38418D, and anUnloadingPeriod 38424D. The IssuePeriod 38484C has a cardinality of zeroor one 38486C and the name is DateTimePeriod 38488C. The PickingPeriod38490C has a cardinality of zero or one 38492C and the name isDateTimePeriod 38494C. The PackingPeriod 38496C has a cardinality ofzero or one 38498C and the name is DateTimePeriod 38400D. TheLoadingPeriod 38402D has a cardinality of zero or one 38404D and thename is DateTimePeriod 38406D. The YardDepartureDateTime 38408D has acardinality of zero or one 38410D and the name is DateTimePeriod 38412D.The ShippingPeriod 38414D has a cardinality of zero or one 38416D andthe name is DateTimePeriod 38416G. The YardArrivaIDateTime 38418D has acardinality of zero or one 38420D and the name is DateTimePeriod 38422D.The UnloadingPeriod 38424D has a cardinality of zero or one 38426D andthe name is DateTimePeriod 38428D.

As depicted in FIG. 384L, the DeliveryItem package 38404A includes anExecution Information package 38468C. The Execution Information package38468C includes an UnpackingPeriod 38442D with the cardinality of zeroor one 38444D and the name DateTimePeriod 38446D; a ReceiptPeriod 38430Dwith the cardinality of zero or one 38432D and the name DateTimePeriod38434D; a PutawayPeriod 38436D with the cardinality of zero or one38438D and the name DateTimePeriod 38440D.

The DeliveryInformation package 38424G includes a Variance entity 38426Gwith the acardinality of zero or one 38428G. The Variance entity 38426Gincludes a Quantity 38430G with the cardinality of one 38432G and thename Quantity 38434G. The QuantityDiscrepancyCode 38436G has acardinality of one 38438G and the name is QuantityDiscrepancyCode38440G. A Product Information package 38470C includes a Product entity38448D with a cardinality of one 38450D and the nameBusinessTransactionDocument Product 38452D. The Product entity 38448Dincludes an InternalID 38454D, a StandardID 38460D, and a ChangeID38466D. The InternalID 38454D has a cardinaliiy of zero or one 38456Dand the name is ProductInternalID 38458D. The StandardID 38460D has acardinality of zero or one 38462D and the name is ProductStandardID38464D. The ChangeID 38466D has a cardinality of zero or one 38468D andthe name is ProductChangeID 38470D.

As depicted in FIG. 384M, the Party package 38418G includes a BuyerPartyentity 38420G that has a cardinality of zero or one 38422G and the nameis BusinessTransactionDocumentParty 38424G. The BuyerParty entity 38420Gincludes an InternalID 38426G, a StandardID 38432G, and an Address38438G. The InternalID 38426G has a cardinality of zero or one 38428Gand the name is PartyInternalID 38430G. The StandardID 38432G has acardinality of zero or one 38434G and the name is PartyStandardID38436G. The Address 38438G has a cardinality of zero or one 38440G andthe name is Address 38442G.

The Party package 38418G also includes a Batch package 38472C. The Batchpackage 38472C includes a Batch entity 38483D. The Batch entity 38483Dincludes a ManufacturingDate 38472D, a BestBeforeDate 38478D, anOriginCountryCode 38418G, and an InternalID 38490D. TheManufacturingDate 38472D has a cardinality of zero or one 38474D and thename is Date 38476D. The BestBeforeDate 38478D has a cardinality of zeroor one 38480D and the name is Date 38482D. The OriginCountryCode 38418Ghas a cardinality of zero or one 38420G and the name is CountryCode38422G. The InternalID 38490D has a cardinality of zero or one 38492Dand the name is BatchID 38494D.

The DeliveryItem package 38404A includes aBusinessTransactionDocumentReference package 38474C. TheBusinessTransactionDocumentReference package 38474C includes aPurchaseOrderReference 38496D, a SalesOrderReference 38402E, anOriginPurchaseOrderReference 38408E, a SchedulingAgreementReference38414E, and a ShipmentReference 38420E. The PurchaseOrderReference38496D has a cardinality of zero or one 38498D and the name isBusinessTransactionDocument Reference 38400E. The SalesOrderReference38402E has a cardinality of zero or one 38404E and the name isBusinessTransactionDocument Reference 38406E. TheOriginPurchaseOrderReference 38408E has any number 38410E ofOriginPurchaseOrderReference entities 38408E for aBusinessTransactionDocumentReference package 38474C. The name isBusinessTransactionDocument Reference 38412E. TheSchedulingAgreementReference 38414E has a cardinality of zero or one38416E and the name is BusinessTransactionDocument Reference 38418E. TheShipmentReference 38420E has a cardinality of zero or one 38422E and thename is BusinessTransactionDocument Reference 38424E.

The Attachment package 38476C includes an AttachmentWebAddress 38426Ethat has a cardinality of any number 38428E of AttachmentWebAddress38426E for an Attachment package 38476C. The name is WebAddress 38430E.The Log package 38478C includes a ValidationLog 38432E with acardinality of zero or one 38434E, and the name is Log 38436E.

j) Personnel Time Sheet Information Interface

The “Personnel Time Recording” scenario is the motivating businessscenario for the PersonnelTimeSheetInformation interface. The scenariocomprises the recording of personnel times and personnel time events,and the transfer of this data to target components. Data can be recordedin a Personnel Time Management system or in a standalone Personnel TimeRecording system. In the latter case, data is transferred to PersonnelTime Management using the PersonnelTimeSheetInfomnation interface.

(1) Message Type Personnel Time Sheet Information

PersonnelTimeSheetInformation is a message used to transfer recordedpersonnel times and personnel time events from a standalone PersonnelTime Recording system to Personnel Time Management. The structure of thePersonnelTimeSheetInformation message is described by the message datatype PersonnelTimeSheetInformationMessage. This message type correspondsto the Timecard standard of the HR-XML consortium.

(2) Message Choreography

FIG. 385 depicts the Message Choreography for thePersonalTimesheetInformation interface established between thePersonnelTimeRecording application 38502 and the PersonnelTimeManagementapplication 38504. The PersonnelTimeRecording 38502 sends aPersonnelTimesheetInformation 38506 to the PersonnelTimeManagementapplication 38504. Personnel Time Recording uses thePersonnelTimeSheetInformation to post the recorded personnel times andpersonnel time events to Personnel Time Management.

(3) Message Type Personnel Time Sheet Message

The PersonnelTimeSheetMessage is a message regarding recorded personneltimes and personnel time events that is sent to Personnel TimeManagement. The PersonnelTimeSheetMessage includes aPersonnelTimeSheetMessage package 38602, which includes a MessageHeaderpackage 38604, a PersonnelTimeSheet package 38606, and aPersonnelTimeSheetMessage entity 38608. The PersonnelTimeSheetMessageentity 38608 is of type GDT: PersonnelTimeSheetMessage.

(a) Message Header Package

The MessageHeader Package 38604 groups non-technical, administrativedata for a PersonnelTimeSheetMessage. It includes a MessageHeader entity38610. There is a 1:c relationship 38612 between thePersonnelTimeSheetMessage entity 38608 and the MessageHeader entity38610.

(i) Message Header

The MessageHeader identifies a set of non-technical, administrativeinformation in a PersonnelTimeSheetMessage. The MessageHeader entity38610 includes a SenderParty entity 38614 and a RecipientParty entity38616. There is a 1:c relationship 38618 between the MessageHeaderentity 38610 and the SenderParty entity 38614, and a 1:c relationship38620 between the MessageHeader entity 38610 and the RecipientPartyentity 38616.

The MessageHeader entity 38610 also includes a MessageID and aCreationDateTime. The MessageID is the message ID is a unique ID of theBusinessDocument, and is of type GDT: MessageID. The CreationDateTimerefers to the time at which the BusinessDocument was created, and is oftype GDT: DateTime. The MessageID is typically set by the sendingapplication.

(ii) Sender Party

The SenderParty is the business sender of a message. The SenderPartyentity 38614 is of type GDT: BusinessDocumentMessageHeaderParty. TheSenderParty entity 38614 can be filled by the sender application to namea contact person for any problems that occur with the message. This isparticularly useful if an additional infrastructure, such as amarketplace, is located between the sender and the recipient. TheSenderParty entity 38614 may be used to transfer the message and may beignored by the receiving application. It should be filled by the senderif the PersonnelTimeSheet package is not used to transfer theparticipating partners. The SenderParty entity 38614 includes thestandard information included with parties, as denoted by ellipses38622.

(iii) Recipient Party

The RecipientParty is the business recipient of a message. TheRecipientParty entity 38616 is of type GDT:BusinessDocumentMessageHeaderParty. The RecipientParty entity 38616 canbe filled by the sender application to name a contact person for anyproblems that occur with the message. This is particularly useful if anadditional infrastructure, such as a marketplace, is located between thesender and the recipient. The RecipientParty entity 38616 may be used totransfer the message and may be ignored by the receiving application. Itshould be filled by the sender if the PersonnelTimeSheet package is notused to transfer the participating partners. The RecipientParty entity38616 includes the standard information included with parties, asdenoted by ellipses 38624.

(b) Personnel Time Sheet Package

The PersonnelTimeSheet package 38606 groups together the personnel timesor personnel time events recorded for a personnel resource. ThePersonnelTimeSheet package 38606 includes a PersonnelTimeSubsheetpackage 38626 and a PersonnelTimeSheet entity 38628. There is a 1:1relationship 38630 between the PersonnelTimeSheetMessage entity 38608and the PersonnelTimeSheet entity 38628.

(i) Personnel Time Sheet

The PersonnelTimeSheet groups together the personnel times or personneltime events recorded for a personnel resource. The PersonnelTimeSheetentity 38628 includes a PersonnelResourceID, which is a unique ID of thepersonnel resource for which the included personnel times and personneltime events have been recorded. A personnel resource identifies a personor a group of persons (such as a department) that contributes to theexecution of services at an enterprise. The PersonnelResourceID is oftype GDT: PartyInternalID.

(ii) Personnel Time Subsheet Package

The PersonnelTimeSubsheet package 38626 includes the personnel times andpersonnel time events recorded for a work agreement. ThePersonnelTimeSubsheet package 38626 includes a PersonnelTimeSubsheetentity 38632. There is a 1:n relationship 38634 between thePersonnelTimeSheet entity 38628 and the PersonnelTimeSubsheet entity38632.

(a) Personnel Time Subsheet

The PersonnelTimeSubsheet is a set of personnel times and personnel timeevents that have been recorded during a particular period for apersonnel resource regarding a work agreement. The PersonnelTimeSubsheetentity 38632 includes a Period and a WorkAgreementID. The Period is theperiod of the PersonnelTimeSubsheet specifies the period for whichpersonnel times and personnel time events exist, and is of type GDT:DatePeriod. The WorkAgreementID is an ID of the work agreement accordingto which the personnel times and personnel time events have beenrecorded. An ID may not be needed if the personnel resource has one workagreement. In this case, the work agreement can be derived from theresource. A work agreement is an agreement between an employee and anemployer. The employee agrees to perform work and the employer agrees toprovide remuneration for the work performed. A work agreement comprisesnumerous other obligations, in addition to the main obligation(remuneration for work), including loyalty, reporting, and benefits.Examples of work agreements include employment contracts, placementcontracts, traineeships, and training contracts. The WorkAgreementID isof type GDT: WorkAgreementID.

The PersonnelTimeSubsheet entity 38632 includes a PersonnelTime entity38636 and a PersonnelTimeEvent entity 38638. There is a 1:cnrelationship 38640 between the PersonnelTimeSubsheet entity 38632 andthe PersonnelTime entity 38636, and a 1:cn relationship 38642 betweenthe PersonnelTimeSubsheet entity 38632 and the PersonnelTimeEvent entity38638. The period of each personnel time occurs within the period of theTimeSubsheet. The time of each personnel time event also occurs withinthis period. In one implementation, at least one PersonnelTime entity38636 or PersonnelTimeEvent entity 38638 is specified.

(b) Personnel Time

The PersonnelTime is a period of a personnel resource that ischaracterized by business, pay scale, or legal criteria. The period canbe entered as a duration (such as 8 hours on Nov. 10, 2003) or as clocktimes (such as 8:10 to 17:30 on Nov. 10, 2003). The PersonnelTime entity38636 is characterized by a personnel time type (such as “working time,”“leave,” “overtime,” “availability for work,” “illness” or “workbreak”).

The PersonnelTime entity 38636 includes an ID, a PersonnelTimeTypeID, aDateTimePeriod, a DatePeriod, a Duration, and a EvaluationRelevantDate.The ID is a unique ID for this personnel time. This entry is optionaland exists if the standalone recording system assigns an ID. The ID isof type GDT: PersonnelTimeID. The PersonnelTimeTypeID is the ID for thepersonnel time type. A personnel time type is a classification ofpersonnel times according to enterprise-specific, pay scale, or legalcriteria. Depending on whether the employee is at work or absent, thisclassification can be made according to payment-relevant or furtherpersonnel time management criteria. Examples include “working time,”“leave,” “overtime, “availability for work,” “illness” or “work break.”The PersonnelTimeTypeID is of type GDT: PersonnelTimeTypeID. TheDateTimePeriod is the period of this personnel time as an interval basedon a specific time. This entry is optional. The DateTimePeriod is oftype GDT: DateTimePeriod. The DatePeriod is the period of this personneltime as a date. This entry is optional. The DatePeriod is of type GDT:DatePeriod. The Duration is the duration of this personnel time. Itspecifies the duration between a clock time or date period. Examples(including period) are: “10 hours on Oct. 1, 2003” or “30 minutesbetween 10 and 11 o'clock on Oct. 1, 2003.” If no duration is entered,the duration between the clock times or dates applies. The Duration isof type GDT: Duration. The EvaluationRelevantDate identifies a date thatis relevant for the valuation of the personnel time. This entry may berequired if, for valuation purposes, a personnel time is to be assignedto a different day than the calendar day to which it currently belongs.For example, to generate a Sunday bonus, a time in the early hours ofMonday morning is to be assigned to the previous Sunday. The assignmentdictates that other rules are used for the valuation and the results maybe assigned to different days. The date for the valuation may need to beentered if the business logic cannot derive this automatically based onthe calendar entries. The EvaluationRelevantDate is of type GDT: Date.

In one implementation, a period is specified. The entry can comprise twoclock times (GDT DateTimePeriod) or two dates (GDT DatePeriod). If aduration is specified, it may not exceed the period between the clocktimes or dates.

(c) Personnel Time Event

The PersonnelTimeEvent identifies a change in the execution of servicesof a personnel resource with which one personnel time ends and anotherpersonnel time begins. Such changes can include, for example, the startof work, interruption of work, or end of work. The PersonnelTimeEvententity 38638 is characterized by a type such as “clock-in entry,”“clock-out entry,” or “start of break.”

The PersonnelTimeEvent entity 38638 includes an ID, aPersonnelTimeEventTypeID, a DateTime, and an EvaluationRelevantDate. TheID is a unique ID for this personnel time event. This entry is optionaland exists if the standalone recording system assigns an ID. The ID isof type GDT: PersonnelTimeEventID. The PersonnelTimeEventTypeID is theID for the type of personnel time event. A personnel time event type isa classification of personnel time events according to personnel timemanagement criteria. A typical criterion is whether the employee is atwork or absent. Examples are “clock-in entry,” “clock-out entry” or“start of break.” The PersonnelTimeEventTypeID is of type GDT:PersonnelTimeEventTypeID. The DateTime is the time at which thispersonnel time event occurs, and is of type GDT: DateTime. TheEvaluationRelevantDate identifies a date to which a personnel time eventis assigned for the valuation (see personnel time), and is of type GDT:Date.

(4) Message Data Type Element Structure

FIGS. 387A-C depict the element structure for PersonnelTimesheetMessage.The element structure is similar to the data model, but providesadditional information regarding the details of the interface. Theelement structure identifies the different packages 38700 in theinterface, and represents the entities at various levels within theinterface. The interface for PersonnelTimesheetMessage includes fivelevels 38702, 38704, 38706, 38708, and 38710. The element structureidentifies the cardinality or occurrence 38714 between the entities orelements, and provides information such as the data type 38714 thatprovides the basis for the entity or element.

The outermost package of this interface is a PersonnelTimesheetMessagepackage 38722, which includes a PersonnelTimesheetMessage entity 38724at the first level 38702. The PersonnelTimesheetMessage entity 38724 isof type GDT PersonnelTimeSheetMessage 38726.

The PersonnelTimesheetMessage package 38722 also includes aMessageHeader package 38734 and a PersonnelTimesheet package 38736. TheMessageHeader package 38734 includes a MessageHeader entity 38738, whichis of type GDT BusinessDocumentMessageHeader 38742. There is zero or one38740 MessageHeader entity 38738 for each PersonnelTimesheetMessageentity 38724.

The MessageHeader entity 38738 includes a MessageID 38744 and aCreationDateTime 38754. The MessageID 38744 is of type GDT MessageID38748, and there is one 38746 MessageID 38744 for each MessageHeaderentity 38738. The CreationDateTime 38754 is of type GDT DateTime 38758,and there is one 38756 CreationDateTime 38754 for each MessageHeaderentity 38738.

The MessageHeader entity 38738 also includes a SenderParty entity 38766and a RecipientParty entity 38778. The SenderParty entity 38766 is oftype GDT BusinessDocumentMessageHeaderParty 38770, and there is zero orone 38768 SenderParty entity 38766 for each MessageHeader entity 38738.The RecipientParty entity 38778 is of type GDTBusinessDocumentMessageHeaderParty 38782, and there is zero or one 38780RecipientParty entity 38778 for each MessageHeader entity 38738.

The PersonnelTimesheet package 38736 includes a PersonnelTimesheetentity 38786. There is one 38788 PersonnelTimesheet entity 38786 foreach PersonnelTimesheetMessage entity 38724. The PersonnelTimesheetentity 38786 is of type GDT PersonnelTimeSheet 38790. ThePersonnelTimesheet entity 38786 includes a PersonnelResourceID 38798.There is one 38700A PersonnelResourceID 38798 for eachPersonnelTimesheet entity 38786. The PersonnelResourceID 38798 is oftype GDT PartyInternalID 38702A.

The PersonnelTimeSubsheet package 38708A includes aPersonnelTimeSubsheet entity 38710A. There is at least one 38712APersonnelTimeSubsheet entity 38710A for each PersonnelTimeSheet entity38786. The PersonnelTimeSubsheet entity 38710A includes a Period 38722A,a WorkAgreementID 38734A, a PersonnelTime 38746A, and PersonnelTimeEvent38728B. The Period 38722A has one occurrence 38724A, and is of type GDTDatePeriod 38726A. The WorkAgreementID 38734A has one or zerooccurrences 38736A, and is of type GDT WorkAgreementID 38738A. ThePersonnelTime 38746A has any number of occurrences 38748A, and is oftype GDT PersonnelTime 38750A. The PersonnelTimeEvent 38728B has anynumber of occurrences 38730B, and is of type GDT PersonnelTimeEvent38732B.

The PersonnelTime 38746A includes an ID 38758A, a TypeID 38768A, aDateTimePeriod 38780A, a DatePeriod 38782A, a Duration 38704B, and aDateForEvaluation 38716B. The ID 38758A has one or zero occurrences38760A, and is of type GDT PersonnelTimeID 38762A. The TypeID 38768A hasone occurrence 38770A, and is of type GDT PersonnelTimeTypeID 38772A.The DateTimePeriod 38780A has one or zero occurrences 38782A, and is oftype GDT TimePeriod 38784A. The DataPeriod 38792A has one or zerooccurrences 38794A, and is of type GDT DataPeriod 38796A. The Duration38704B is of type GDT Duration 38708B, and has one or zero occurrences38706B. The DataForEvaluation 38716B is of type of GDT Date 38720B, andhas zero or one occurrences 38718B.

The PersonnelTimeEvent 38728B includes an ID 38740B, a TypeID 38750B, aDateTime 38762B, and a DateForEvaluation 38774B. The ID 38740B has oneor zero occurrences 38742B, and is of type GDT PersonnelTimeEventID38744B. TypeID 38750B has one occurrence 38752B, and is of type GDTPersonnelTimeEventTypeID 38754B. DateTime 38762B has one occurrence38764B, and is of type GDT DataTime 38766B. DataForEvaluation 38774B hasone or zero occurrences 38776B, and is of type GDT Data 38778B.

k) Credit Worthiness Interface

CreditWorthiness interfaces are used to request information about thecreditworthiness of a party. The CreditWorthiness interfaces are basedon a CreditWorthinessQuery message type and a CreditWorthinessResponsemessage type. The CreditWorthinessQuery provides the structure for themessage requesting the creditworthiness of a party. TheCreditWorthinessResponse provides the structure for the reply messagethat includes the details required about the creditworthiness (score andcredit limit) of the party.

The credit management of a company is responsible for checking thecreditworthiness of a party and for real-time monitoring of the totalliability of parties using dynamic credit limits. The tasks of a creditmanager include the final acceptance or refusal of a request (creditdecision) and the procurement and management of collateral that reducesthe risk of losses on receivables from the party. Creditworthinesschecks are carried out using both internal and external information. Theinformation about the creditworthiness can be provided on request fromcredit management (CreditWorthinessQuery & CreditWorthinessResponse) oras an unsolicited notification to credit management based on internalcompany rules (CreditWorthinessChangeInformation). Therefore, the basesfor the creditworthiness checks include: (1) Credit information about aparty provided by information providers (CreditAgencyReportQuery &CreditAgencyReportResponse); (2) information about existing paymentobligations of the party, which can be obtained actively by CreditManagement (CreditCommitmentQuery & CreditCommitmentResponse) or CreditManagement may receive it, for example, from Sales according to internalcompany rules (CreditCommitmentRecordNotification); and (3)notifications about the payment behavior of parties that CreditManagement receives from Payment (CreditPaymentRecordNotification).Credit Management can also provide information internally on requestabout parties whose creditworthiness is classified as critical(CreditWorthinessCriticalPartiesQuery &CreditWorthinessCriticalPartiesResponse).

The interfaces CreditWorthinessQuery and CreditWorthinessResponse aremotivated by the business scenario Credit Check. An application thatwould request information regarding the creditworthiness of a party (forexample, Financials or Sales) sends a query to Credit Management. CreditManagement then provides information such as the score and recommendedcredit limit for the party. This information can, for example, influencethe decision as to whether business transactions should take place withthis party.

(1) Message Types

(a) Credit Worthiness Query

A CreditWorthinessQuery is a query to Credit Management about thecreditworthiness of a party. The message type CreditWorthinessQuery isbased on the message data type CreditWorthinessQueryMessage.

(b) Credit Worthiness Response

A CreditWorthinessResponse is a response from Credit Management to thequery about the creditworthiness of a party. The message typeCreditWorthinessResponse is based on the message data typeCreditWorthinessMessage.

FIG. 388 depicts the Message Choreography for the CreditWorthinessinterfaces within a context of communication between five applications:Payment/Accounting 38802, Sales or Financials 38804, Billing System38806, Credit Management 38808, and Credit Agency 38814. In thiscontext, an application that wants to know about the creditworthiness ofa party (for example, financials or sales) can send a query in aCreditWorthinessQuery to Credit Management; and Credit Management canthen provide the information requested in a CreditWorthinessResponse.For example, Credit Management 38808 can send a CreditAgencyReportQueryto the Credit Agency 38810. In response, the Credit Agency 38810 sends aCreditAgencyReportResponse 38814 to Credit Management 38808. Anapplication that requests information about the creditworthiness of aparty (for Payment/Accounting, Sales/Financials, or a Billing system)sends a query (CreditWorthinessQuery) to Credit Management. CreditManagement then provides the requested details(CreditWorthinessResponse). A serialization of the messages is notnecessary.

(2) Message Data Type Credit Worthiness Query Message The message datatype CreditWorthinessQueryMessage groups the business information thatis relevant for sending a business document in a message and the objectCreditWorthinessQuery included in the business document. As depicted inFIG. 389, the CreditWorthinessQueryMessage includes aCreditWorthinessQueryMessage package 38902, which includes aMessageHeader package 38904, a CreditWorthinessQuery package 38906, anda CreditWorthinessQueryMessage entity 38908. The message data typeCreditWorthinessQueryMessage provides the structure for the message typeCreditWorthinessQuery.

(a) Message Header Package

The MessageHeader package 38904 groups the business information that isrelevant for sending a business document in a message. The MessageHeader38904 is optional.

(b) Credit Worthiness Query Package

The CreditWorthinessQuery package 38906 includes a Party package 38910,a Product package 38912, and a CreditWorthinessQuery entity 38914. Thereis a 1:1 relationship 38916 between the CreditWorthinessQueryMessageentity 38908 and the CreditWorthinessQuery entity 38914.

The CreditWorthinessQuery entity 38914 identifies the query regardingthe creditworthiness of a business party, and includes aCreditSegmentInternalID, a CheckedAmount, a CheckingRuleCode, aCheckingSeverityCode, and aCreditAgencyReportRetrievalPermissionIndicator. TheCreditSegmentInternalID is the proprietary identifier of the creditsegment to which the creditworthiness query relates. The credit segmentis a unit of the business of a company from the viewpoint of creditassignment and credit control. One of the uses of the credit segment isto monitor the credit limits of parties. CreditSegmentInternalID is oftype GDT: CreditSegmentInternalID. The CheckedAmount is the amount to bechecked (for example, order value), and is of type GDT: Amount. TheCheckingRuleCode is an encoded representation of the procedure to beused for determining the creditworthiness, and is of type GDT:CreditWorthinessCheckingRuleCode. The CheckingSeverityCode is an encodedrepresentation of the strength of the check procedure to be applied, andis of type GDT: CreditWorthinessCheckingSeverityCode. TheCreditAgencyReportRetrievalPermissionIndicator is the specification ofwhether the party has given consent for credit information to beobtained about him or her, and is of type GDT:CreditAgencyReportRetrievalPermissionIndicator.

These elements can be used to make the creditworthiness query moreprecise. The CreditSegmentInternalID is used when both the sender andthe recipient can access shared master data for the credit segment. Ifthis is not the case, the credit segment is derived from other elements(for example, the CreditorParty, the SellerParty, or theProductCategory, discussed below).

(i) Credit Worthiness Query Party Package

The CreditWorthinessQueryParty package 38910 includes a DebtorPartyentity 38918, a CreditorParty entity 38920, and a SellerParty entity38922. There is a 1:1 relationship 38924 between theCreditWorthinessQuery entity 38914 and the DebtorParty entity 38918.There is a 1:c relationship 38926 between the CreditWorthinessQueryentity 38914 and the CreditParty entity 38920. There is also a 1:crelationship 38928 between the CreditWorthinessQuery entity 38914 andthe SellerParty entity 38922.

The DebtorParty identifies the party about whom creditworthinessinformation is to be provided, i.e., the debtor party. The DebtorPartyentity 38918 is of type GDT BusinessTransactionDocumentParty, where theelement InternalID is used. The DebtorParty entity 38918 is typicallyspecified.

The CreditorParty identifies the party that owns a receivable due fromthe debtor party. The CreditorParty entity 38920 is of type GDTBusinessTransactionDocumentParty, where, in one implementation, theelement InternalID is used. The CreditorParty entity 38920 determinesthe credit segment and is not required if the credit segment isspecified via the CreditSegmentInternalID or determined from theProductCategory.

The SellerParty identifies the party that sells a product, or plans to,to the debtor party. The SellerParty entity 38922 is of type GDTBusinessTransactionDocumentParty, where, in one implementation, theelement InternalID is used. The SellerParty entity 38922 determines thecredit segment and is not required if the credit segment is specifiedvia the CreditSegmentInternalID or determined from the ProductCategory.

(ii) Credit Worthiness Query Product Information Package

The CreditWorthinessQueryProductInformation package 38912 includes aProductCategory entity 38930. There is a 1:c relationship 38932 betweenthe CreditWorthinessQuery entity 38914 and the ProductCategory entity38930. The ProductCategory identifies the product category of theproduct sold to, or to be sold to, the debtor party. The ProductCategoryentity 38930 is of type GDT BusinessTransactionDocumentProductCategory,where, in one implementation, the element InternalID is used. TheProductCategory entity 38930 determines the credit segment and is notrequired if the credit segment is specified via theCreditSegmentInternalID or determined using the CreditorParty 38920 orSellerParty 38922.

(3) Message Data Type Credit Worthiness Message

The message data type CreditWorthinessMessage groups the businessinformation that is relevant for sending a business document in amessage and the object CreditWorthiness included in the businessdocument. It includes a CreditWorthinessMessage package 39002, whichincludes a MessageHeader package 39004, a CreditWorthinessQuery package39006, and a CreditWorthinessMessage entity 39008. The message data typeCreditWorthinessQueryMessage provides the structure for the message typeCreditWorthinessQuery.

(a) Message Header Package

A MessageHeader package 39004 groups the business information that isrelevant for sending a business document in a message. The MessageHeader39004 is optional.

(b) Credit Worthiness Package

The CreditWorthiness package 39006 includes a Party package 39010, aProductInformation package 39012, an Information package 39014, and aCreditWorthiness entity 39016. There is a 1:1 relationship 39018 betweenthe CreditWorthinessMessage entity 39008 and the CreditWorthiness entity39016.

The CreditWorthiness 16 identifies the creditworthiness of a party, andincludes details of the score, risk class, and credit limit, ifrequired. The CreditWorthiness entity 39016 includes an Indicator, aCheckingDescription, and a CreditSegmentInternalID. The Indicatorspecifies whether the creditworthiness of the party exists for the queryparameters, and is of type GDT: CreditWorthinessIndicator. TheCheckingDescription includes a description of the process of thecreditworthiness check, and is of type GDT: Description. TheCheckingDescription is optional. The CreditSegmentInternalID is theproprietary identifier of the credit segment for which thecreditworthiness check is carried out. A credit segment is a unit of thebusiness of a company from the viewpoint of credit assignment and creditcontrol. One of the uses of a credit segment is to monitor the creditlimits of parties. The CreditSegmentInternalID is of type GDT:CreditSegmentInternalID.

The CreditSegmentInternalID is used when both the sender and therecipient can access shared master data for the credit segment. If thisis not the case, the credit segment is derived from other elements (forexample, CreditorParty, SellerParty, or ProductCategory). The mostimportant information about the creditworthiness of a party is retainedin the element CreditWorthinessIndicator and in the entity Rating in theCreditWorthinessInformation package.

(i) Credit Worthiness Party Package

The CreditWorthinessParty package 39010 includes a DebtorParty entity39020, a CreditorParty entity 39022, and a SellerParty entity 39024.There is a 1:1 relationship 39026 between the CreditWorthiness entity39016 and the DebtorParty entity 39020. There is a 1:c relationship39028 between the CreditWorthiness entity 39016 and the CreditorPartyentity 39022. There is also a 1:c relationship 39030 between theCreditWorthiness entity 39016 and the SellerParty entity 39024.

The DebtorParty identifies the party whose creditworthiness wasdetermined (i.e., the Debtor Party). The DebtorParty entity 39020 is oftype GDT BusinessTransactionDocumentParty; where the element InternalIDis used. The Debtor Party is typically specified.

The CreditorParty identifies the party that owns a receivable due fromthe Debtor Party. The CreditorParty entity 39022 is of type GDTBusinessTransactionDocumentParty; where the element InternalID is used.Parties that are assigned to the credit segment in which thecreditworthiness was determined are typically specified.

The SellerParty identifies a party that can sell a product to a DebtorParty. The SellerParty entity 39024 is of type GDTBusinessTransactionDocumentParty; where, in one implementation, theelement InternalID is used. Parties that are assigned to the creditsegment in which the creditworthiness was determined are specified.

(ii) Credit Worthiness Query Product Information Package

The CreditWorthinessQueryProductInformation package 39012 includes aProductCategory entity 39032, which identifies the product category ofthe product sold to, or to be sold to, the Debtor Party. There is a 1:crelationship 39034 between the CreditWorthiness entity 39016 and theProductCategory entity 39032.

The ProductCategory entity 39032 is of type GDTBusinessTransactionDocumentProductCategory; where, in oneimplementation, the element InternalID is used. Product categories thatare assigned to the credit segment in which the creditworthiness wasdetermined are specified.

(iii) Credit Worthiness Information Package

The CreditWorthinessInformation package 39014 includes a summary ofdetails of the creditworthiness determined for a party, and includes aCreditRating entity 39036, a CreditRiskClass entity 39038, a CreditLimitentity 39040, and a CreditExposure entity 39041. There is a 1:1relationship 39042 between the CreditWorthiness entity 39016 and theCreditRating entity 39036. There is a 1:c relationship 39044 between theCreditWorthiness entity 39016 and the CreditRiskClass entity 39038.There is also a 1:c relationship 39046 between the CreditWorthinessentity 39016 and the CreditLimit entity 39040. There is a 1:crelationship 39047 between the CreditExposure entity 39041 and theCreditRiskClass entity 39038.

The CreditRating identifies the score of a business party determined byCredit Management, which is valid for a specific period. TheCreditRating entity 39036 includes a Code and a ValidityPeriod. The Codeis the encoded representation of the score value, and is of type GDT:CreditRatingCode. The ValidityPeriod is the validity period for thecredit score, and is of type GDT: DateTimePeriod, where the element“Duration” is not used. Credit Management provides the list of possibleCreditRatingCodes. “CreditRating” and “Rating” are used interchangeably.

The CreditRiskClass identifies the risk of non-payment determined byCredit Management, which is valid for a specific period, and may belinked to a business contract. The CreditRiskClass entity 39038 includesa RiskClass and a ValidityPeriod. The RiskClass is the encodedrepresentation of the risk class, and is of type GDT:CreditRiskClassCode. The ValidityPeriod is the validity period for thecredit risk class, and is of type GDT: DateTimePeriod, where the element“Duration” is not used. Credit Management provides the list ofCreditRiskClassCodes. “CreditRiskClass” and “RiskClass” are usedinterchangeably.

The CreditLimit identifies the credit limit valid for a business partyfor a specific period. The CreditLimit entity 39040 includes an Amountand a ValidityPeriod. The Amount is the amount of the credit limit, andis of type GDT: Amount. The ValidityPeriod is the validity period forthe credit limit, and is of type GDT: DateTimePeriod, where the element“Duration” is not used.

The CreditExposure entity 39041 describes how much of the credit limitfor the credit account is already consumed. The Credit Exposure entity39041 contains the element: Amount. Amount of the credit exposure GDT:Amount.

(4) Message Data Type Element Structure

(a) CreditWorthiness Query

FIG. 391 depict the element structure for CreditWorthinessQuery. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 39100 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIGS. 391A-B, the interface for CreditWorthinessQueryincludes four levels 39102, 39104, 39106, and 39108. The elementstructure identifies the cardinality or occurrence 39110 between theentities of the interface, and provides information such as the datatype 39112 that provides the basis for the entity or element. Theoutermost package 39100 of this interface is anCreditWorthinessQueryMessage package 39114, which includes aCreditWorthinessQueryMessage entity 39116 at the first level 39102. TheCreditWorthinessQueryMessage entity 39116 is of type message data type(“MDT”) 391 CreditWorthinessQueryMessage 39118.

The CreditWorthinessQueryMessage package 39114 includes aCreditWorthinessQuery package 39120. The CreditWorthinessQuery package39120 includes a CreditWorthinessQuery entity 39122. There is one 39124CreditWorthinessQuery entity 39122 for each CreditWorthinessQueryMessageentity 39116. The CreditWorthinessQuery entity 39122 is of type AGDTCreditWorthinessQuery 39126. The CreditWorthinessQuery entity 39122includes a CreditSegmentInternalID 39128, a CheckedAmount 39134, aCheckingRuleCode 39140, a CheckingSeverityCode 39146, and aCreditAgencyReportRetrievalPermissionIndicator 39152.

There is zero or one 39130 CreditSegmentInternalID 39128 for eachCreditWorthinessQuery entity 39122. The CreditSegmentInternalID 39128 isof type GDT CreditSegmentInternalID 39132. A CheckedAmount 39134 haszero or one occurrences 39136 for each CreditWorthinessQuery entity39122, and is of type GDT Amount 39138. CheckingRuleCode 39140 has zeroor one occurrences 39142 for each CreditWorthinessQuery entity 39122,and is of type GDT CreditWorthinessCheckingRuleCode 39144.CheckingSeverityCode 39146 has zero or one occurrences 39148 for eachCreditWorthinessQuery entity 39122, and is of type GDTCreditWorthinessSeverityCode 39150.CreditAgencyReportRetrievalPermissionIndicator 39152 has one occurrence39154 for each CreditWorthinessQuery entity 39122, and is of type GDTCreditAgencyReportRetrievalPermissionIndicator 39156.

The CreditWorthinessQuery package 39120 also includes a Party package39158 and a ProductInformation package 39160. The Party package 39158includes a DebtorParty entity 39162, a CreditorParty entity 39174, and aSellerParty entity 39186. The DebtorParty entity 39162 is of type GDTBusinessTransactionDocumentParty 39166. There is one 39164 DebtorPartyentity 39162 for each CreditWorthinessQuery entity 39122. TheCreditorParty entity 39174 is of type GDTBusinessTransactionDocumentParty 39178. There is zero or one 39176CreditorParty entity 39174 for each CreditWorthinessQuery entity 39122.The SellerParty entity 39186 is of type GDTBusinessTransactionDocumentParty 39190. There is zero or one 39188SellerParty entity 39186 for each CreditWorthinessQuery entity 39122.The DebtorParty entity 39162 includes an InternalID 39168 that has one39170 occurrence for each DebtorParty entity 39162, and is of type GDTPartyInternalID 39172. The CreditorParty entity 39174 includes anInternalID 39180 that has one 39182 occurrence for each CreditorPartyentity 39174, and is of type GDT PartyInternalID 39184. The.SellerPartyentity 39186 includes an InternalID 39192 that has one 39194 occurrencefor each SellerParty entity 39186, and is of type GDT PartyInternalID39190.

The ProductInformation package 39160 includes a ProductCategory entity39198. The ProductCategory entity 39198 is of type GDTBusinessTransactionDocumentProductCategory 39102A. There is zero or one39100A ProductCategory entity 39198 for each CreditWorthinessQueryentity 39122. The ProductCategory entity 39198 includes an InternalID39104A having one 39106A occurrence for each ProductCategory entity39198, and a data type of GDT ProductCategoryInternalID 39108A.

(b) CreditWorthiness Response

FIG. 390 depict the element structure for CreditWorthinessResponse. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 39200 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIGS. 392A-C, the interface for CreditWorthinessResponseincludes four levels 39202, 39204, 39206, and 39208. The elementstructure identifies the cardinality or occurrence 39210 between theentities and/or elements of the interface, and provides information suchas the data type 39212 that provides the basis for the entity orelement. The outermost package of this interface is aCreditWorthinessMessage package 39214, which includes anCreditWorthinessMessage entity 39216 at the first level 39202. TheCreditWorthinessMessage entity 39216 is of type message data type(“MDT”) CreditWorthinessMessage 39218.

The CreditWorthinessMessage package 39214 includes a CreditWorthinesspackage 39220. The CreditWorthiness package 39220 includes aCreditWorthiness entity 39222, a Party package 39246, a ProductInformation package 39248, a CreditworthinessInformation package 39250,a DebtorPartyBlockedIndicator, and aDebtorPartySpecialAttentionRequiredIndicator 39251. There is one 39224CreditWorthiness entity 39222 for each CreditWorthinessMessage entity39216. The CreditWorthiness entity 39222 is of type AGDTCreditWorthiness 39226. The CreditWorthiness entity 39222 includes aCreditSegmentInternalID 39228, an Indicator 39234, and aCheckingDescription 39240.

There is zero or one 39230 CreditSegmentInternalID 39228 for eachCreditWorthiness entity 39222. The CreditSegmentInternalID 39228 is oftype GDT CreditSegmentInternalID 39232. An Indicator 39234 has zero orone 39236 occurrences for each CreditWorthiness entity 39222, and is oftype GDT CreditWorthinessIndicator 39238. CheckingDescription 39240 hasany number of occurrences 39242, and is of type GDT Description 39244.The DebtorPartyBlockedIndicator 39245 has a cardinality of zero or one39247, and the type is CDT 39249. TheDebtorPartySpecialAttentionRequiredIndicator 39251 has a cardinality ofzero or one 39253, and the type is CDT 39255.

The Party package 39246 includes a DebtorParty entity 39252, aCreditorParty entity 39264, and a SellerParty entity 39276. TheDebtorParty entity 39252 is of type GDT BusinessTransactionDocumentParty39256. There is one 39254 DebtorParty entity 39252 for eachCreditWorthiness entity 39222. The CreditorParty entity 39264 is of typeGDT BusinessTransactionDocumentParty 39268. There is any number ofoccurrances 39266 of the CreditorParty 39264 for each CreditWorthinessentity 39222. The SellerParty entity 39276 is of type GDTBusinessTransactionDocumentParty 39280. There is any number ofoccurrences 39278 of the SellerParty entity 39276 for eachCreditWorthiness entity 39222. The DebtorParty entity 39252 includes anInternalID 39258 that has one 39260 occurrence for each DebtorPartyentity 39252. The InternalID 39258 is of type GDT PartyInternalID 39262.The CreditorParty entity 39264 includes an InternalID 39270 that has one39272 occurrence for each CreditorParty entity 39264. The InternalID39270 is of type GDT PartyInternalID 39274. The SellerParty entity 39276includes an InternalID 39282 that has one 39284 occurrence for eachSellerParty entity 39276. The InternalID 39282 is of type GDTPartyInternalID 39286.

The ProductInformation package 39248 includes a ProductCategory entity39288. The ProductCategory entity 39288 is of type GDTBusinessTransactionDocumentProductCategory 39292. There is any number ofoccurrances 39290 of ProductCategory entities 39288 for eachCreditWorthiness entity 39222. The ProductCategory entity 39288 includesan InternalID 39294 having one 39296 occurrence. The InternalID 39294 isof type GDT ProductCategoryInternalID 39298.

The CreditworthinessInformation package 39250 includes a CreditRating39200A, CreditRiskClass 39216A, CreditLimit 39232A, and a CreditExposurepackage 39248A The CreditRating 39200A has one 39202A occurrence andincludes a Code 39204A and a Validity Period 39210A. The Code 39204A hasone occurrence 39206A for each CreditRating 39200A, and is of type GDTCreditRatingCode 39208A. The ValidityPeriod 39210A has one or zerooccurrences 39212A for each CreditRating 39200A, and is of type GDTDateTimePeriod 39214A. The CreditRiskClass entity 39216A has one or zerooccurrences 39218A and includes a Code 39220A and a Validity Period39226A. The Code 39220A has one occurrence 22A, and is of type GDTCreditRiskClassCode 39224A. The ValidityPeriod 39226A has one or zerooccurrences 28A, and is of type GDT DateTimePeriod 39230A. TheCreditLimit entity 39232A has one or zero occurrences 39234A, andincludes an Amount 39236A and a ValidityPeriod 39242A. The Amount 39236Ahas one occurrence 39238A for each CreditLimit entity 39232A, and is oftype GDT Amount 39240A. The ValidityPeriod 39242A has one or zerooccurrences 39244A, and is of type GDT DateTimePeriod 39246A. TheCreditExposure package 39248A has one zero occurances 39250A. The Amount39252A has one occuence 39254A, and is of type GDT 39256A.

l) Credit Agency Report Interfaces

CreditAgencyReport interfaces are used to request credit informationabout a party from a credit agency. An agency provides businessinformation about private or business relationships of other parties,particularly with regard to their creditworthiness (for example, Dun &Bradstreet or Schufa). With the information received about thecreditworthiness assessment, about payment reliability, and otherfinancial information, a company can then determine a creditworthinessscore for the party. The CreditAgencyReport interfaces are based on twomessage types: (1) the CreditAgencyReportQuery structures the messagefor requesting credit information; and (2) theCreditAgencyReportResponse structures the response message that includesthe required credit information.

In a company, credit management is responsible for checking thecreditworthiness of parties and for real-time monitoring of the totalliability of parties using dynamic credit limits. The tasks of a creditmanager include the final acceptance or refusal of requests (creditdecision) and the procurement and management of collateral that reducesthe risk of losses on receivables from parties. Creditworthiness checksare carried out using both internal and external information. Theinformation about the creditworthiness can be provided on request fromcredit management (CreditWorthinessQuery & CreditWorthinessResponse) oras an unsolicited notification to credit management based on internalcompany rules (CreditWorthinessChangeInformation).

Creditworthiness checks therefore are based on: (1) credit informationabout parties provided by information providers (CreditAgencyReportQuery& CreditAgencyReportResponse); (2) information about existing paymentobligations of the party; this information can be obtained actively byCredit Management (CreditCommitmentQuery & CreditCommitmentResponse) orCredit Management receives it, for example, from Sales according tointernal company rules (CreditCommitmentRecordNotification); and (3)notifications about the payment behavior of parties that CreditManagement receives from Payment (CreditPaymentRecordNotification).Credit Management also can provide information internally on requestabout parties whose creditworthiness is classified as critical(CreditWorthinessCriticalPartiesQuery &CreditWorthinessCriticalPartiesResponse).

Credit Management sends a query about a party to the Web server of anagency; the agency determines the information required (for example,based on industry, size of company) and returns it. This information isprocessed further in the “Credit Rules Engine.” A score and an internalcredit limit are determined as the result of a series of flexible rulesthat are based on a company's own experience with the party and thecreditworthiness data from the agency.

(1) Message Types

(a) Credit Agency Report Query

The CreditAgencyReportQuery is an inquiry to a credit agency for creditinformation about a party. The message type CreditAgencyReportQuery isbased on the message data type CreditAgencyReportQueryMessage. The B2BCreditAgencyReportQuery is transformed into the query format of therespective credit agency within the Exchange Infrastructure.

(b) Credit Agency Report Response

The CreditAgencyReportResponse is the response from a credit agency tothe inquiry for credit information about a party. The message typeCreditAgencyReportResponse is based on the message data typeCreditAgencyReportMessage. The response message of the credit agency istransformed into the format of the B2B CreditAgencyReportResponse withinthe Exchange Infrastructure.

(2) Message Choreography

FIG. 393 depicts the message choreography for an exemplary credit agencyreport and query process. The choreography involves two businessentities: a CreditManagement entity of a company 39302 and aCreditManagement entity 39304, which may be an agency separate from thecompany. The CreditManagement entity 39302 may periodically receivenotifications from other departments of the company, e.g.,Payment/Accounting 39306, Sales/Financials 39308, or Billing Systems39310, about the existing payment obligations of parties or aboutpayments received from these parties. The CreditManagement entity 39302uses this information to answer queries from various company areas aboutthe creditworthiness of parties, taking into account, in somecircumstances, credit information from external credit agencies andquerying current payment obligations. CreditManagement 39302 may alsoactively provide information about changes to the creditworthiness ofparties or, on request, name parties whose creditworthiness isclassified as critical.

As shown in FIG. 393, the CreditManagement entity 39302 sends aCreditAgencyReportQuery 39314 to the CreditAgency entity 39304 based onpayment obligations of parties or about payments received from theseparties received from the other company department. In response, theCreditAgency entity 39304 sends a CreditAgencyReportResponse 39316 tothe CreditManagement entity 39302. In one implementation, thetransmission of the messages takes place synchronously. Serialization ofthe message is not necessary.

(3) Message Data Type Credit Agency Report Query Message

FIG. 394 depicts the data model for theMessageDataTypeCreditAgencyReportQueryMessage used to implement aCreditAgencyReportQuery message 39314. The message data typeCreditAgencyReportQueryMessage groups the business information that isrelevant for sending a business document in a message and the objectCreditAgencyReportQuery included in the business document. The messagedata type CreditAgencyReportQueryMessage includes aCreditAgencyReportQueryMessage package 39400. TheCreditAgencyReportQueryMessage package 39400 includes a MessageHeaderpackage 39402, a CreditAgencyReportQueryPackage 39404, and aCreditAgencyReportQueryMessage entity 39406.

(a) Message Header Package

The MessageHeader package 39402 groups the business information that isrelevant for sending a business document in a message. The MessageHeader39402 package includes a MessageHeader entity 39408, a SenderPartyentity 39410 and a RecipientParty entity 39412. The MessageHeader entity39408 groups business information from the viewpoint of the sendingapplication to identify the business document in a message, informationabout the sender, and information about the recipient. The MessageHeaderentity 39408 is of the type GDT: BusinessDocumentMessageHeader. There isa 1:c relationship 39414 between the CreditAgencyReportQueryMessageentity 39406 and the MessageHeader entity 39408. There is a 1:crelationship 39416 between the MessageHeader entity 39408 and theSenderParty entity 39410. There is a 1:cn relationship 39418 between theMessageHeader entity 39408 and the RecipientParty entity 39412.

The MessageHeader entity 39408 includes an ID and a CreationDateTime.The ID is a unique identifier for the message, and is of type GDT:MessageID. The CreationDateTime is the creation date and time of themessage, and is of type GDT: DateTime The SenderParty entity 39410identifies the party responsible for sending a business document at thebusiness application level. The SenderParty entity 39410 is of type GDT:BusinessDocumentMessageHeaderParty. The InternalID of the data type isused.

The RecipientParty entity 39412 identifies the party responsible forreceiving a business document at the business application level. TheRecipientParty entity 39412 is of type GDT:BusinessDocumentMessageHeaderParty and may include an InternalID of typeGDT: Party Internal ID.

(b) Credit Agency Report Query Package

The CreditAgencyReportQuery Package 39404 includes aCreditAgencyReportQueryParty or Party package 39420, aCreditAgencyReportQueryService or service package 39422, and aCreditAgencyReportQuery entity 39424. The CreditAgencyReportQuery entity39424 identifies the query to a credit agency for credit informationabout a party. The CreditAgencyReportQuery entity 39424 includes detailsabout the party for whom credit information is required, together with aspecification of the service required by the agency. TheCreditAgencyReportQuery entity 39424 includes a ReasonCode, which is areason for the query to the credit agency, and is of type GDT:CreditAgencyReportQueryReasonCode. There is a 1:1 relationship 39426between the CreditAgencyReportQueryMessage entity 39406 and theCreditAgencyReportQuery entity 39424.

(i) Credit Agency Report Query Party Package

The CreditAgencyReportQueryParty Package 39420 includes a DebtorPartyentity 39428, which identifies the party about whom credit informationis to be provided. There is a 1:1 relationship 39430 between theCreditAgencyReportQuery entity 39424 and the DebtorParty entity 39428.The DebtorParty entity 39428 includes a StandardID, a CreditAgencyID, anAddress, an IncorporationDate, and a BirthDate. The StandardID is thestandardized identifier of the party to be checked, and is of type GDT:PartyStandardID. The CreditAgencyID is the identifier given by thecredit agency for the party to be checked, and is of type GDT:PartyPartyID. The Address is the address of the party to be checked, andis of type GDT: Address, where FunctionalTitleName, DepartmentName,Office, TaxJurisdictionCode, TimeZoneDifferenceValue, and GeoCoordinatesneed not be used. The IncorporationDate is the incorporation date of acompany, if the party to be checked is a company, and is of type GDT:Date. The BirthDate is the date of birth of a natural person, if theparty to be checked is a natural person, and is of type GDT: Date. Theelements IncorporationDate and BirthDate need not be used together.

As many details as possible are given about a party so that it can beuniquely identified by the credit agency. Data protection considerationsare pushed into the background because, firstly, the party has givenconsent for credit information to be obtained, and secondly, the creditagency is obliged to handle data transmitted confidentially. Inaddition, it is part of the service in some credit agencies (forexample, Schufa) to check the details of a party (address, bank details,credit card number, and so on).

(c) Credit Agency Report Query Service Package

The CreditAgencyReportQueryService package 39422 includes a summary ofall information about the type and scope of the service required fromthe credit agency, and includes a Service entity 39432, which specifiesthe type and scope of the service required from the credit agency. Thereis a 1:1 relationship 39434 between the CreditAgencyReportQuery entity39424 and the Service entity 39422. The Service entity 39422 includes aCreditAgencyID and a LanguageCode. The CreditAgencyID is the identifierprovided by the credit agency for the service required (according to theagency service catalog), and is of type GDT: ProductPartyID. TheLanguageCode is the language in which the results of the servicerequired are to be provided, and is of type GDT: LanguageCode.

(4) Message Data Type Credit Agency Report Message

FIGS. 395A and B depict the data model for a message data typeCreditAgencyReportResponse used to implement aCreditAgencyReportResponse message 39316. The message data typeCreditAgencyReportResponse includes a CreditAgencyReportMessage package39500. The CreditAgencyReportMessage package 39500 groups the businessinformation that is relevant for sending a business document in amessage and the object CreditAgencyReport included in the businessdocument. The CreditAgencyReportMessage package 39500 includes aMessageHeader package 39502, a CreditAgencyReport package 39504, and aCreditAgencyReportMessage entity 39506.

(a) Message Header Package

The MessageHeader package 39502 groups the business information that isrelevant for sending a business document in a message. It includes aMessageHeader entity 39508, which groups together the businessinformation from the point of view of the sending application toidentify the business document in a message, information about thesender, and information about the recipient. There is a 1:c relationship39510 between the MessageHeader entity 39508 and theCreditAgencyReportMessage entity 39506. The MessageHeader is of typeGDT: BusinessDocumentMessageHeader. It includes an ID, a ReferenceID,and a CreationDateTime. The ID is a unique identifier for the message,and is of type GDT: MessageID. The ReferenceID is a unique identifierfor the message for the request resulting in theCreditAgencyReportResponse, and is of type GDT: MessageID. TheCreationDateTime is the creation date and time of message, and is oftype GDT: DateTime.

(b) Credit Agency Report Package

The CreditAgencyReport package 39504 includes aCreditAgencyReportCreationLog or Log package 39512, aCreditAgencyReportParty or party package 39514, aCreditWorthinessInformation package 39516, a LegalInformation package39518, and a CreditAgencyReport entity 39520. There is a 1:1relationship 39522 between CreditAgencyReportMessage entity 39506 andthe CreditAgencyReport entity 39520.

(i) Credit Agency Report

The CreditAgencyReport entity 39520 identifies the credit informationissued by the credit agency for a party. The CreditAgencyReport entity39520 includes the credit information required about a party, withdetails about the creation of this information.

(ii) Credit Agency Report Creation Log

The CreditAgencyReportCreationLog package 39512 includes a CreationLogentity 39524, which includes a sequence of log messages about thecreation of credit information. The CreationLog entity 39524 includes anItem entity 39526. There is a 1:c relationship 39528 between theCreditAgencyReport entity 39520 and the CreationLog entity 39524. Thereis a 1:n relationship 39530 between the CreationLog entity 39524 and theItem entity 39526.

The Item entity 39526 includes a log message about the creation ofcredit information, and is of type GDT: LogItem. It includes a TypeID, aSeverityCode, and a Note. The TypeID is a unique identification of thetype of a log entry (within the application that created the log). TheSeverityCode is a coded representation of the severity of the logmessage, and is of type GDT: LogItemSeverityCode. The Note is text ofthe log message, and is of type GDT: Note.

(iii) Credit Agency Report Party Package

The CreditAgencyReportParty package 39514 includes a DebtorParty entity39532, which identifies the party about whom credit information is to beprovided. There is a 1:c relationship 39534 between theCreditAgencyReport entity 39520 and the DebtorParty entity 39532. TheDebtorParty entity 39532 includes a StandardID, a CreditAgencyID, anAddress, an IncorporationDate, and a BirthDate. The StandardID is thestandardized identifier of the party to be checked, and is of type GDT:PartyStandardID. The CreditAgencyID is the identifier given by thecredit agency for the party to be checked, and is of type GDT:PartyPartyID. The Address is the address of the party to be checked, andis of type GDT: Address, where FunctionalTitleName, DepartmentName,Office, TaxJurisdictionCode, TimeZoneDifferenceValue, GeoCoordinatesneed not be used. The IncorporationDate is the incorporation date of acompany, if the party to be checked is a company, and is of type GDT:Date. The BirthDate is the date of birth of a natural person, if theparty to be checked is a natural person, and is of type GDT: Date. Theelements IncorporationDate and BirthDate need not be used together.

(iv) Credit Agency Report Credit Worthiness Information Package

The CreditAgencyReportCreditWorthinessInformation package 39516 includesa summary of the details regarding the creditworthiness of a party incredit information. The CreditAgencyReportCreditWorthinessInformationpackage 39516 includes a CreditRating entity 39536, a CreditRiskClassentity 39538, a Scoring entity 39540, and a CreditLimit entity 39542.There is a 1:1 relationship 39544 between the CreditAgencyReport entity39520 and the CreditRating entity 39536. There is a 1:c relationship39546 between the CreditAgencyReport entity 39520 and theCreditRiskClass entity 39538. There is a 1:cn relationship 39548 betweenthe CreditAgencyReport entity 39520 and the Scoring entity 39540. Thereis a 1:cn relationship 39550 between the CreditAgencyReport entity 39520and the CreditLimit entity 39542.

The CreditRating entity 39536 includes the score of a business partydetermined by the credit agency, which is valid for a specific period.The CreditRating entity 39536 includes a Code and a ValidityPeriod. TheCode is the coded representation of the score value, and is of type GDT:CreditRatingCode. The ValidityPeriod is the validity period for thescore value, and is of type GDT: DatePeriod.

The CreditRiskClass entity 39538 identifies the risk class of a partydetermined by the credit agency, which is valid for a specific period.The CreditRiskClass entity 39538 includes a Code and a ValidityPeriod.The Code is the coded representation of the risk class, and is of typeGDT: CreditRiskClassCode. The ValidityPeriod is the validity period forthe risk class, and is of type GDT: DatePeriod.

The Scoring entity 39540 identifies the result of the rating of a partywith regard to their creditworthiness using a scorecard specified by acredit agency. The scorecard is a schema for rating a party usingdifferent characteristics. The Scoring entity 39540 is of type GDT:CreditAgencyReportScoring. Individual or few characteristics areexamined for each scorecard; i.e., several scorecards or severalscorings are necessary for a comprehensive rating.

The CreditLimit entity 39542 identifies the credit limit valid for aparty for a specific period. The CreditLimit entity 39542 includes anAmount and a ValidityPeriod.

The Amount is the amount of the credit limit, and is of type GDT:Amount. The ValidityPeriod is the validity period for the credit limit,and is of type GDT: DatePeriod.

Due to the different validity periods, there may be more than one creditlimit for a party.

(v) Credit Agency Report Legal Information Package

The CreditAgencyReportLegalInformation package 39518 includes a summaryof the details regarding the legal facts related to the creditinformation. The CreditAgencyReportLegalInformation package 39518includes a LegalEvent entity 39552, which identifies a legal event thataffects the creditworthiness of a party. There is a 1:cn relationship39554 between the CreditAgencyReport entity 39520 and the LegalEvententity 39552. The LegalEvent entity 39552 includes a TypeCode, a Dateand a Description. The TypeCode is the coded representation of the legalevent, and is of type GDT: LegalEventTypeCode. The Date is the date ofthe legal event, and is of type GDT: Date. The Description is thedescription of the legal event, and is of type GDT: Description. Theremay be several legal events for one party. Examples of legal eventsinclude affidavits, warrants, insolvencies, and seizures.

(5) Message Data Type Element Structure

FIGS. 396A-E depict the element structure for CreditAgencyReportQuery.The element structure is similar to the above-described data model ofthe message data type CreditAgencyReportQuery in FIG. 394, but providesadditional information regarding the details for interfacing with orimplementing a CreditAgencyReportQuery. The element structure identifiesthe different packages 39600 in the interface, and represents theentities at various levels within the interface. As shown in FIG. 396A,the interface for a CreditAgencyReportQuery includes four levels 39602,39604, 39606, and 39608 each of which is associated with a respectivepackage 39600. The element structure identifies the cardinality oroccurrences 39610 of each element and provides a data type name 39612for each element.

The outermost package of this interface is CreditAgencyReportQuerypackage 39614, which includes a CreditAgencyReportQueryMessage entity39616 at the first level 39602. The CreditAgencyReportQueryMessageentity 39616 is of data type MDT: CreditAgencyReportQueryMessage 39618.

The CreditAgencyReportQueryMessage package 39614 includes aMessageHeader package 39620, which includes a MessageHeader entity39624. The MessageHeader entity 39624 is of data type GDT: MessageHeader39628. There is one 39626 MessageHeader entity 39624 for eachCreditAgencyReportQueryMessage entity 39616.

The MessageHeader entity 39624 includes an ID 39630, a Reference ID39636, a CreationDateTime 39642, a Sender Party entity 39648 and aRecipient Party entity 39660. The ID 39630 is of data type GDT:BusinessDocumentMessageID 39634. There is one 39632 ID 39630 for eachMessageHeader entity 39624. The ReferenceID 39636 is of data type GDT:BusinessDocumentMessageID 39640. There is one or zero 39638 ReferenceID39636 for each MessageHeader entity 39624. The CreationDateTime 39642 isof data type GDT: DateTime 39646. There is one 39644 CreationTimeData39642 for each MessageHeader 39624. The SenderParty entity 39648includes one 39656 InternalID 39654 of the GDT: PartyInternalID 39652and is of type of GDT: BusinessDocumentMessageHeaderParty 39652. Thereis one or zero 39650 SenderPartyEntity 39648 for each MessageHeaderentity 39624. The RecipientParty entity 39660 includes one 39648InternalID 39666 of type GDT: PartyInternalID 39670 and is of data typeGDT: BusinessDocumentMessageHeaderParty 39664. There is any number 39662of RecipientParty entities 39660 for each MessageHeader entity 39624.

The CreditAgencyReportQueryMessage package 39614 also includes aCreditAgencyReportQuery package 39622, which includes aCreditAgencyReportQuery entity 39672, a Party package 39684, and aService package 39686. The CreditAgencyReportQuery entity 39672 is ofdata type AGDT: Item 39676. In one implementation, there is one 39674CreditAgencyReportQuery entity for eachCreditAgencyReportQueryMessageEntity 39616.

The CreditAgencyReportQuery entity 39672 includes a Reason entity 39678,which has one occurrence 39680 for each entity 39672 and has a data typeGDT: CreditAgencyReportQueryReasonCode 39682.

The Party package 39684 includes a DebtorParty entity 39688 of type GDT:BusinessTransactionDocumentParty 39692. The DebtorParty entity 39688incudes a StandardID 39694, a Credit AgencyID 39600A, an Address 39606A,an IncorporationDate 39612A, and a BirthDate 39618A. The StandardID39694 is of type GDT: PartyStandardID 39698. The CreditAgencyID 39600Ais of type of GDT: PartyPartyID 39604A. The Address 39606A is of typeGDT: Address 39610A. The IncorporationDate 39612A is of type GDT: Date.The BirthDate 39618A is of type DT: Date 39622A. In one implementation,for each DebtorParty 39688, there is one or zero 39696 StandardID 39694,one or zero 39602A CreditAgencyID 39600A, one or zero 39608A Address39606A, one or zero 39614A IncorporationDate 39612A, and one or zero39620A BirthDate 39618A.

The Service package 39686 includes a Service entity 39624A. There is one39626A Service entity 39624A for each CreditAgencyReportQuery entity39672. The Service entity 39624A includes one 39630A CreditAgencyID39628A of type GDT: ProductPartyID 39632A. There is one 39630ACreditAgencyID 39628A for each Service entity 39624A.

FIG. 397 depicts the element structure for CreditAgencyReportResponse.The element structure identifies the different packages 39700 in theinterface, and represents the entities at various levels within theinterface. As shown in FIG. 397, the interface forCreditAgencyReportResponse includes five levels 39702, 39704, 39706,39708, and 39710. The element structure identifies the cardinality ornumber of occurrences 39712 of each element and provides a data typename 39714 for each element.

The outermost package of this interface is CreditAgencyReportMessagepackage 39716, which includes a CreditAgencyReportMessage entity 39718at the first level 39702. The CreditAgencyReportMessage entity 39718 isof data type MDT: CreditAgencyReportMessage 39720.

The CreditAgencyReportMessage package 39716 includes a MessageHeaderpackage 39722 and a CreditAgencyReport package 39724. The MessageHeaderpackage 39722 includes a MessageHeader entity 39726, is of data typeGDT: MessageHeader 39730. There is one 39728 MessageHeader entity 39726for each CreditAgencyReportMessage entity 39718.

The MessageHeader entity 39726 includes an ID 39732, a ReferenceID39738, a CreationDateTime 39744, a SenderParty 39750, and aRecipientParty 39762. The ID 39732 has one occurrence 39734 for eachMessageHeader entity 39726 and is of data type GDT:BusinessDocumentMessageID 39736. The ReferenceID 39738 has zero or oneoccurrences 39740A for each MessageHeader entity 39726 and is of datatype GDT: BusinessDocumentMessageID 39742. The CreationDateTime 39744has one occurrence 39746 for each MessageHeader entity 39726 and is ofdata type GDT: DateTime 39748.

The SenderParty 39750 includes one 39758 InternalID 39756 of data typeGDT: PartyInternalID 39760. The RecipientParty 39762 includes one 39770InternalID 39768 of datatype GDT: PartyInternalID 39772. TheRecipientParty 39762 is of data type GDT:BusinessDocumentMessageHeaderParty 39766. There is any number 39764 ofRecipientParties 39762 for each MessageHeader entity 39726.

The CreditAgencyReport package 39724 includes a CreationLog package39780, a Party package 39782, a CreditWorthinessInformation package39784, a Legal Information package 39786, and a CreditAgencyReportentity 39774. The CreditAgencyReport entity 39774 has one occurrence39776 for each CreditAgencyReportMessage entity 39718 and is of datatype GDT: CreditAgencyReport 39778.

The CreationLog package 39780 includes a CreationLog entity 39788 in thesecond level L2 39704. The CreationLog entity 39788 includes an Itementity 39792 in the third level L3 39706. The Item entity 39792 has aTypeID 39798, a SeverityCode 39704A, and a Note 39710A. The CreationLogentity 39788 has zero or one occurrences 39790 for eachCreditAgencyReport entity 39774. The Item entity 39792 has 1 to noccurrences 39794 for each CreationLog entity 39788 and is of data typeGDT: LogItem 39796. The TypeID 39798 has zero or one occurrences 39700Afor each Item entity 39792 and is of data type xsd: token 39702A. TheSeverityCode 39704A has zero or one occurrences 39706A for each Itementity 39792 and is of data type GDT: LogItemSeverityCode 39708A. TheNote 39710A has one occurrence 39712A for each Item entity 39792 and isof data type GDT: Note 39714A.

The Party package 39782 inclues a DebtorParty entity 39716A. TheDebtorParty entity 39716A has one occurrence 39718A for eachCreditAgencyReport entity 39774 and is of data type GDT:BusinessTransactionDocumentParty 39720A. The DebtorParty entity 39716Aincludes a StandardID 39722A, a CreditAgencyID 39728A, an Address39734A, an IncorporationDate 39740A, and a BirthDate 39746A. TheStandardID 39722A has zero to n occurrences 39724A for each DebtorPartyentity 39716A and is of data type GDT: PartyStandardID 39726. TheCreditAgencyID 39728A has zero or one occurrences 39730A for eachDebtorParty entity 39716A and has a data type of GDT: PartyPartyID39732A. The Address 39734A has one occurrence 39736A for eachDebtorParty entity 39716A and is of data type GDT: Address 39738A. TheIncorporationDate 39740A has zero or one occurrences 39742A for eachDebtorParty entity 39716A and is of data type GDT: Date 39744A. TheBirthDate 39746A has zero or one occurrences 39748A for each DebtorPartyentity 39716A and is of data type GDT: Date 39750A.

The CreditWorthinessInformation package 39784 includes a CreditRatingentity 39752A, a CreditRiskClass entity 39768A, a Scoring entity 39784A,and a CreditLimit entity 39708B. The CreditRating entity 39752A has oneoccurrence 39754A for each CreditAgencyReport entity 39774 and includesa Code 39756A and a ValidityPeriod 39762A. The Code 39756A has oneoccurrence 39758A for each CreditRating entity 39752A, and is of datatype GDT: CreditRatingCode 39760A. The ValidityPeriod 39762A has zero orone occurrence 39764A for each CreditRating entity 39752A and is of datatype GDT: DatePeriod 39766A. The CreditRiskClass 39768A has one or zerooccurrences 39770A for each CreditAgencyReport entity 39774 and includesa Code 39772A and a ValidityPeriod 39778A. The Code 39772 has oneoccurrence 39774A for each CreditRiskClass entity 39768A and is of datatype GDT: CreditRiskClassCode 39776A. The ValidityPeriod 39778A has zeroor one occurrences 39780A for each CreditRiskClass entity 39768A and isof data type GDT: DatePeriod 39782A. The Scoring entity 39784A includesa ScoreCardID 39790A, a ResultValue 39796A, and a Description 39702B.The Scoring entity 39784A has zero to n occurrences 39786A for eachCreditAgencyReport entity 39774 and is of data type GDT:CreditAgencyReport Scoring 39788A. The ScoreCardID 39790A has zero orone occurrences 39792A for each Scoring entity 39784A and is of datatype 397GDT: ScoreCardID 39794A. The ResultValue 39796A has oneoccurrence 39798A for each Scoring entity 39784A and a data type xsd:decimal 39700A. The Description 39702B has zero or one occurrences39704B for each Scoring entity 39784A and is of data type GDT:Description 39706B. The CreditLimit 39708B has zero or n occurrences39710B for each CreditAgencyReport entity 39774 and includes an Amount39712B and a ValidityPeriod 39718B. The Amount 39712B has one occurrence39714B for each CreditLimit entity 39708B and is of data type GDT:Amount 39716B. The ValidityPeriod 39718B has zero or one occurrence39720B for each CreditLimit entity 39708B and is of data type GDT:DatePeriod 39722B.

The LegalInformation package 39786A includes a LegalEvent entity 39724B.The LegalEvent entity 39724B includes a TypeCode 39728B, a Date 39734B,and a Description 39740B. The LegalEvent entity 39724B has zero to noccurrences 39726B for each Item entity 39774. The TypeCode 39728B haszero or one occurrences 39730B for each LegalEvent entity 39724B and isof data type GDT: LegalEventTypeCode 39732B. The Date 39734B has zero orone occurrences 39736B for each CreditLimit entity 39708B and is of datatype GDT: Date 39738B. The Description 39740B has zero or oneoccurrences 39742B for each CreditLimit entity 39708B and is of datatype GDT: Description 39744B.

m) Accounting Cancellation Request

In the business scenario Sell from Stock, a goods receipt or an outgoinginvoice is executed and transferred to Accounting. It is thenestablished that this process step is to be cancelled. In this case, acancellation request for the original message is sent to Accounting andany further recipients affected. One feature of the cancellation messagemay be that the reference to the original business transaction istransferred; no additional posting information is transferred. Thecancellation message defined here is to be used for cancellation of anInvoiceAccountingInformation and anInventoryChangeAccountingInformation. It may also be used for otherfuture messages that create postings in Accounting.

(1) Message Types

For each message type used for a posting in Accounting, there is acorresponding message type for cancelling this posting. Sincecancellation requests to Financial Accounting are via reference, theyare based on the same message data type AccountingCancellationMessagefor messages to Financial Accounting.

(a) Message Type Invoice Accounting Cancellation Request

An InvoiceAccountingCancellationRequest is a request for thecancellation of posting information previously sent to Accounting for anincoming or outgoing invoice or credit memo(InvoiceAccountingNotification). The message typeInvoiceAccountingCancellationRequest is based on the message data typeAccountingCancellationMessage. In one implementation, Accounting cannotreject the cancellation.

(b) Message Type Inventory Change Accounting Cancellation Request

An InventoryChangeAccountingCancellationRequest is a request for thefull cancellation of posting information previously sent to Accountingwith respect to a goods movement(InventoryChangeAccountingNotification). The message typeInventoryChangeAccountingCancellationRequest is based on the messagedata type AccountingCancellationMessage. In one implementation,Accounting cannot reject the cancellation.

(2) Message Choreography

FIG. 398 depicts the Message Choreography for theAccountingCancellationRequest interface between Invoicing/Billing 39802and Accounting 39804. Invoicing/Billing 39802 sends anInvoiceAccountingNotification 39806 to Accounting 39804.Invoicing/Billing 39802 may then send anInvoiceAccountingCancellationRequest 39808 to Accounting 39804.

The receipt of an invoice in invoice verification causes an accountingdocument to be posted in Accounting. The invoice received can becancelled and, as a result, leads to a cancellation of the relatedinvoice document in Accounting.

(3) Message Data Type Accounting Cancellation Message

The message data type AccountingCancellationMessage includes theAccountingCancellation object included in the business document and thebusiness information that is relevant for sending a business document ina message. As depicted in FIG. 399, the message data typeAccountingCancellationMessage includes an AccountingCancellationMessagepackage 39900, which includes a MessageHeader package 39902 and anAccountingCancellation package 39904. The AccountingCancellationMessagepackage 39900 also includes an AccountingCancellationMessage entity39906. The message data type AccountingCancellationMessage provides thestructure for the message type AccountingCancellation and the relevantinterfaces.

(a) Message Header Package

A MessageHeader package 39902 groups the business information that isrelevant for sending a business document in a message. The MessageHeaderis not required for AccountingCancellationRequest. In oneimplementation, a cancellation is sent to Accounting once. A message IDis not required, since the reference can be established with the ID ofthe source document. The sender may be known as the “system ID.” In oneimplementation, the recipient is not known; the fact that this messageis to be sent to the Accounting application is known.

(b) Accounting Cancellation Package

The AccountingCancellation package 39904 is the grouping of informationrequired for the cancellation of posting information previously sent toAccounting. It includes a BusinessTransactionDocumentReference Package39908 and an AccountingCancellation entity 39910. There is a 1:1relationship 39912 between the AccountingCancellationMessage entity39906 and the AccountingCancellation entity 39910.

(i) Accounting Cancellation

The AccountingCancellation is the cancellation of posting informationpreviously sent to Accounting. The AccountingCancellation entity 39910identifies the business document to be cancelled by means of thereference and type of business transaction in which the document wascreated or involved. The AccountingCancellation entity 39910 includes anOriginBusinessTransactionTypeCode, a PostingDate, and a Description. TheOriginBusinessTransactionTypeCode is a business transaction type inwhich the document to be cancelled was created, and is of the type GDT:BusinessTransactionTypeCode. The PostingDate is the date on which thetransaction is relevant for Accounting, and is of the type GDT: Date.The Description is a description of the cancellation, and is of the typeGDT: Description.

(ii) Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 39908 groups thereferences to business documents on which the cancellation transactionis based. The BusinessTransactionDocumentReference package 39908includes a PrimaNotaReference entity 39914 and anOriginPrimaNotaReference entity 39916. There is a 1:c relationship 39920between the AccountingCancellation entity 39910 and theOriginPrimaNotaReference entity 39916.

The PrimaNotaReference indicates the reference to the document of thesender which represents the cancellation request to Accounting. ThePrimaNotaReference entity 39914 is of type GDT:BusinessTransactionDocumentReference, where the element “ID” is used,since there is no reference to a line item. The PrimaNotaReferenceentity 39914 is typically filled.

The OriginPrimaNotaReference indicates the reference to the origindocument of the sender on which posting information previously sent toAccounting—and now to be cancelled—is based. TheOriginPrimaNotaReference entity 39916 is of type GDT:BusinessTransactionDocumentReference where the element “ID” is usedsince there is no reference to a line item; for example, reference tothe document for an invoice, credit memo, or payment, but also thedocument for an inventory change in the stockholding. TheOriginPrimaNotaReference entity 39916 is typically filled.

(4) Message Data Type Element Structure.

FIGS. 400A-B depict the element structure forAccountingCancellationRequest. The element structure is similar to thedata model, but provides additional information regarding the details ofthe interface. The element structure identifies the different packages40000 in the interface, and represents the entities at various levelswithin the interface. As depicted in FIGS. 400A-B, the interface forAccountingCancellationRequest includes four levels 40002, 40004, 40006,and 40008. The element structure identifies the cardinality oroccurrence 40010 between the entities of the interface, and providesinformation, e.g., the data type 40012, that provides the basis for theentities or elements. The outermost package of this interface is anAccountingCancellationMessage package 40014, which includes anAccountingCancellationMessage entity 40016 at the first level 40002.There is one 40018 AccountingCancellationMessage entity 40016 for eachAccountingCancellationMessage package 40014.

The AccountingCancellationMessage package 40014 also includes anAccountingCancellation package 40020. The AccountingCancellation package40020 includes an AccountingCancellation entity 40022. There is one40024 AccountingCancellation entity 40022 for eachAccountingCancellationMessage entity 40016. The AccountingCancellationentity 40022 includes an BasePrimaNotaID 40026, a PostingDate 40032, anda Note 40038. The BasePrimaNotaID 40026 is of type GDTBusinessTransactionDocumentID 40030. There is one 40028 BasePrimaNotaID40026 for each AccountingCancellation entity 40022. The PostingDate40032 is of type GDT Date 40036, and there is zero or one 40034PostingDate 40032 for each AccountingCancellation entity 40022. The Note40038 is of type GDT Note 40042, and there is zero or one 40040 Note40038 for each AccountingCancellation entity 40022.

The AccountingCancellation package 40020 also includes aBusinessTransactionDocumentReference package 40044. TheBusinessTransactionDocumentReference package 40044 includes aOriginPrimaNotaTypeCode entity 40046 and an OriginPrimaNotaReferenceentity 40058. The OriginPrimaNotaTypeCode entity 40046 is of type GDTBusinessTransactionDocumentTypeCode 40050. There is one 40048OriginPrimaNotaTypeCode entity 40046 for each AccountingCancellationentity 40022. The OriginPrimaNotaReference entity 40058 is of type GDTBusinessTransactionDocumentReference 40062. There is one 40060OriginPrimaNotaReference entity 40058 for each AccountingCancellationentity 40022. The OriginPrimaNotaReference entity 40058 includes an ID40064, which is of type GDT BusinessTransactionDocumentID 40068. Theoccurrence of the ID 40064 is one 40066.

n) Invoice Due Interfaces

Invoice due interfaces are interfaces that transmits information about abusiness transaction to be settled to Billing (billing documentcreation) or Invoicing (invoice verification).

In this document, the term “settlement” refers to creating billingdocuments (outgoing invoices and credit memos), incoming, and“self-billing” invoices and to checking incoming invoices.

The motivating business scenarios for the invoice due interfaces are theProcure to Stock (PTS) and Sell from Stock (SFS) scenarios. Goods arepurchased in the PTS scenario. After a delivery has been received andthe appropriate goods receipt has been posted, the delivery data thatare relevant for invoicing (with reference to the purchase order) aretransmitted to Invoicing. Goods are sold in the SFS scenario. After anorder has been created in Sales (BAC CRM), the elements of the contractthat are relevant for billing are transmitted to Billing. This enablescontract-related billing to be carried out. After the appropriatedeliveries have been made and the relevant goods issues have beenposted, the logistics data (with reference to the order) are transmittedto Billing. Then delivery-related billing can be carried out for theorder.

(1) Message Types

(a) Billing Due Notification

The BillingDueNotification is a notification about data relevant forbilling to an application that carries out billing. The message typeBillingDueNotification is based on the message data typeInvoiceDueMessage.

This message type is used for the following business transactions: (1)Billing based on contract data (e.g., credit memo requests debit memorequests, etc.); (2) Billing of delivery data with reference to contractdata (e.g., a standard order with order items relevant for delivery);(3) Billing of delivery data without reference to contract data; and (4)Billing of contract data (such as a standard order) in accordance withthe delivery quantities (general delivery data).

(b) Invoicing Due Notification

The InvoicingDueNotification is a notification about data relevantstructure for invoicing to an application that checks and createsincoming invoices and/or creates “self-billing” invoices (ERS). Themessage type InvoicingDueNotification is based on the message data typeInvoiceDueMessage.

(2) Message Choreography

FIG. 401 depicts the message choreography for exemplary Billing DueNotification and Invoicing Due Notification processes.

(a) Billing Due Notification

Referring to FIG. 401, data that are relevant for billing aretransmitted from Sales (CRM) 40100 and Supply Chain Execution (SCE)40100 to Billing (invoice creation) 40106 via appropriateBillingDueNotification messages 40108 and 40110. The message is used tocreate and change data that are relevant for billing (theBillingDueNotification is sent again). The data are always transmittedin their entirety. Thus, Sales 40100 transmits a BillingDueNotificationmessage 40106 to Billing 40104 while SupplyChainExecution 40102transmits a BillingDueNotification message 40108 to Billing 40104.

(b) Invoicing Due Notification

Referring to FIG. 401, data that are subject to settlement aretransmitted from Purchasing (SRM) 40110 and Supply Chain Execution (SCE)40112 to Invoicing (invoice verification) 40114 using appropriateInvoicingDueNotification messages 40116 and 40118. The message is usedto create and change data that are subject to settlement (theInvoicingDueNotification is sent again). The data are always transmittedin their entirety. Thus, Purchasing 40110 transmits anInvoicingDueNotification message 40116 to Invoicing 40114 whileSupplyChainExecution 40112 transmits a InvoicingDueNotification message40118 to Invoicing 40114.

(3) Message Data Type Data Model Invoice Due Message

FIG. 402 depicts a data model for the InvoiceDueMessage. The messagedata type InvoiceDueMessage includes an InvoiceDue object, whichincludes an InvoiceDueMessage package 40200. The InvoiceDueMessagepackage 40200 includes a MessageHeader package 40202, an InvoiceDuepackage 40204, and an InvoiceDueMessage entity 40206. The message datatype InvoiceDueMessage provides the structure for the following messagetypes: BillingDueNotification, InvoicingDueNotification and theinterfaces based on them.

(a) Message Header Package

The MessageHeader package 40202 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader package currently does not contain any entries. Thereference to the base business document is always made by establishing areference to the purchase order, delivery, etc. The sender is alsoidentified by means of the reference. The sender does not know who therecipient is and knows that the message is to be sent to a billing orinvoicing application.

(b) Invoice Due Package

The InvoiceDue package 40204 groups all information that is required fora settlement (creation of billing documents and invoice verification).It includes a Party package 40208, a Location package 40210, aDeliveryInformation package 40212, a PaymentInformation package 40214, aPriceInformation package 40216, an AccountAssignment package 40218, anAttachment package 40220, a Description package 40222, an Item package40224, and an InvoiceDue entity 40226. There is a 1:1 relationship 40228between the InvoiceDueMessage entity 40206 and the InvoiceDue entity40226.

(i) Invoice Due

An InvoiceDue package 40204 comprises information that summarizes alldetails about a business transaction that are relevant for settling thisbusiness transaction, where settling means the creation of billingdocuments and the checking and creation (“self-billing”) of incominginvoices. InvoiceDue consists of InvoiceDueItems, which represent itemsin the base business document for the future settlement. AnInvoiceDueItem usually consists of information about the quantity of aproduct that has been ordered or delivered, as well as the businesspartners, locations, terms of delivery and payment involved and theother business documents to be taken into account when the product issettled. Data that applies to (almost) all InvoiceDueItems can also beentered directly at header level.

InvoiceDue includes a BaseBusinessTransactionDocumentID, aBaseBusinessTransactionDocumentTypeCode, an ActionCode, aSettlementRelevanceIndicator, a SettlementPriorityCode, aSettlementBlockedIndicator, an ItemListCompleteTransmissionIndicator, aPlannedBillingDate, a ProposedInvoiceDate, and a DeliveryPeriod. TheBaseBusinessTransactionDocumentID is a unique identifier for a basebusiness document for the InvoiceDue, and is of type GDT:BusinessTransactionDocumentID. TheBaseBusinessTransactionDocumentTypeCode is the coded representation ofthe type of the base business document for the InvoiceDue. The typessales order and (outgoing) delivery are currently relevant for themessage type BillingDueNotification; the types purchase order, salesorder, and (incoming) delivery are currently relevant for the messagetype InvoicingDueNotification. TheBaseBusinessTransactionDocumentTypeCode is of type GDT:BusinessTransactionDocumentTypeCode. The ActionCode is the codedrepresentation of an instruction to the recipient of the message tellingit, whether to create, change or delete the InvoiceDue, and is of typeGDT: ActionCode. The SettlementRelevanceIndicator specifies whether thebusiness transaction is subject to settlement, and is of type GDT:BusinessTransactionDocumentSettlementRelevanceIndicator. TheSettlementPriorityCode is the coded representation of the urgency of adue settlement, and is of type GDT: BusinessTransactionPriorityCode. TheSettlementBlockedIndicator specifies whether the settlement for thetransmitted data is blocked, and is of type GDT:BusinessTransactionBlockedIndicator. TheItemListCompleteTransmissionIndicator specifies whether all the items inthe base business document for the InvoiceDue are to be transmitted(items that are not transmitted are implicitly classed as cancelled) orwhether new items or items that have been changed since the lasttransmission are to be transmitted, and is of type GDT:CompleteTransmissionIndicator. The PlannedBillingDate is the planneddate for billing a document in a business transaction, and is of typeGDT: Date. The ProposedInvoiceDate is the date for the billing businessdocument (invoice, credit memo, debit memo, etc.), and is of type GDT:DateTime. The DeliveryPeriod specifies the period of time during which aservice is provided, and is of type GDT: DateTimePeriod.

Since the data is always transmitted in its entirety, theItemListCompleteTransmissionIndicator has the value “true.” The softsemantic (ActionCodes “04”/“05”) is used for the ActionCode, since theapplications receiving the data contain the data subject to settlementfrom the transmitted item. For the ActionCode the default-logic appliesas described in the “Notes (Regarding the Message Data Type).”ActionCode “04” is interpreted by the receiving application as a changestatement for the items to be transmitted, provided that they havealready been transmitted by a previous message. If this is not the case,the transmitted items are created. The ActionCode “05” (REMOVE)signalizes to the receiving application that item transmitted previouslyfor a business transaction (and cancelled now) are not relevant forsettlement any more.

Initially, the information about the date is used from theProposedInvoiceDate element; hours, minutes, and seconds are ignored.For the element ActionCode a default-logic applies. The ActionCodespecified for the entity InvoiceDue is valid for all InvoiceDueItemsthat do not have an explicitely different ActionCode. If no ActionCodeis specified explicitely for the entity InvoiceDue, the ActionCode “04”shall be assumed as default.

Notes (Regarding the Message Type InvoicingDueNotification): Defaultlogic is not supported for the following elements:SettlementRelevanceIndicator, SettlementBlockedIndicator,ProposedBillingDate, ProposedInvoiceDate, and DeliveryPeriod. For thisreason, these elements are not used at InvoiceDue level. TheSettlementPriority element is initially not supported.

Notes (Regarding the Message Type BillingDueNotification): In case of anActionCode “05” the receiving application has to decide, whether dataalready transmitted for a business transaction is disregarded withrespect to further settlement or—in case of a settlement alreadydone—revoked using a cancellation or credit memo. If theSettlementPriority element is used, the highest level of priority (Code‘1’) denotes immediate or direct billing. All other levels of prioritydenote background/online billing rather than immediate billing. Defaultlogic is used for the elements SettlementRelevanceIndicator andBillingBlockedIndicator: the relevant indicators at InvoiceDue levelapply to all corresponding indicators at InvoiceDueItem level for whichvalues have not been transmitted. The following default logic is usedfor the DeliveryPeriod element: the date specified in the StartDateTimeattribute is interpreted as being the date on which a service isprovided (requested delivery date, date of the goods issue posting); allother information is ignored. If an appropriate date is transmitted atInvoiceDue level, it is used as the date at InvoiceDueItem level in theDeliveryPeriod element for which values have not been transmitted.

Example—Usually the base business transaction for an InvoiceDueMessageis an order, a purchase order, or a delivery.

(ii) Party Package

The Party package 40208 groups information relating to all businesspartners that might be involved in a settlement. The Party package 40208includes a BuyerParty entity 40230, a SellerParty entity 40232, aProductRecipientParty entity 40234, a VendorParty entity 40236, aBillToParty entity 40238, a BillFromParty entity 40240, a PayerPartyentity 40242, and a PayeeParty entity 40244. There is a 1:c relationship40246 between the InvoiceDue entity 40226 and the BuyerParty 40230.There is a 1:c relationship 40248 between the InvoiceDue entity 40226and the SellerParty 40232. There is a 1:c relationship 40250 between theInvoiceDue entity 40226 and the ProductRecipientParty 40234. There is a1:c relationship 40252 between the InvoiceDue entity 40226 and theVendorParty 40236. There is a 1:c relationship 40254 between theInvoiceDue entity 40226 and the BillToParty 40238. There is a 1:crelationship 40256 between the InvoiceDue entity 40226 and theBillFromParty 40240. There is a 1:c relationship 40258 between theInvoiceDue entity 40226 and the PayerParty 40242. There is a 1:crelationship 40260 between the InvoiceDue entity 40226 and thePayeeParty 40244.

Default logic is used for all business partners: business partners thatare specified at InvoiceDue level are used for all the items for which acorresponding partner is not explicitly transmitted. The default logicapplies for the partner as a whole, including the contact person. Partsof a partner cannot be specified in more detail at item level. Thedefault logic is a simplified version of the transmitted message. Interms of logic, partners at InvoiceDue level behave as if they have beenexplicitly transmitted for all the items of the message.

(a) Buyer Party

A BuyerParty is a company or person that purchases goods or services.The BuyerParty entity 40230 is of type GDT:BusinessTransactionDocumentParty, where the “InternalID” is used. TheBuyerParty entity 40230 is entered for a settlement and therefore isspecified at InvoiceDue or InvoiceDueItem level in the message if theBusinessTransactionDocumentTypeCode element refers to a businesstransaction of type order or purchase order. The BuyerParty entity 40230can also fulfill the functions of the ProductRecipientParty entity40234, the BillToParty entity 40238 or the PayerParty entity 40242.

The default logic in the Party package 40208 includes a Address entity40262 and a Contact entity 40264. There is a 1:c relationship 40266between BuyerParty entity 40230 and Address entity 40262. There is a 1:crelationship 40268 between BuyerParty entity 40230 and Contact entity40264.

The Address entity 40262 includes a PersonName entity 40270, an Officeentity 40272, a PhysicalAddress entity 40274, a GeoCoordinates entity40276, and a Communication entity 40278. There is a 1:c relationship40280 between PersonName entity 40270 and Address entity 40262. There isa 1:c relationship 40282 between Office entity 40272 and Address entity40262. There is a 1:c relationship 40284 between PhysicalAddress entity40274 and Address entity 40262. There is a 1:c relationship 40286between GeoCoordinates entity 40276 and Address entity 40262. There is a1:c relationship 40288 between Communication entity 40278 and Addressentity 40262.

The Contact entity 40264 includes an Address entity 40290. There is a1:c relationship 40292 between Address entity 40290 and Contact entity40264. The Address entity 40290 includes a PersonName entity 40294, anOffice entity 40296, a PhysicalAddress entity 40298, a GeoCoordinatesentity 40200A, and a Communication entity 40202A. There is a 1:crelationship 40204A between PersonName entity 40294 and Address entity40290. There is a 1:c relationship 40206A between Office entity 40296and Address entity 40290. There is a 1:c relationship 40208A betweenPhysicalAddress entity 40298 and Address entity 40290. There is a 1:crelationship 40210A between GeoCoordinates entity 40200A and Addressentity 40290. There is a 1:c relationship 40212A between Communicationentity 40202A and Address entity 40290.

(b) Seller Party

A SellerParty is a company or person that sells goods or services. TheSellerParty entity 40232 is of type GDT:BusinessTransactionDocumentParty, where the “InternalID” is used. TheSellerParty entity 40232 can also fulfill the functions of theVendorParty entity 40236, the BillFromParty entity 40240 or thePayeeParty entity 40244. The SellerParty entity 40232 is entered for asettlement and therefore is specified at InvoiceDue or InvoiceDueItemlevel in the message if the BusinessTransactionDocumentTypeCode elementrefers to a business transaction of type order or purchase order.

The SellerParty entity 40232 includes the same Address and Contactentities 40214A as found for the BuyerParty 40230.

(c) Product Recipient Party

A ProductRecipientParty is a company or person to whom goods aredelivered or for whom services are provided. The ProductRecipientPartyentity 40234 is of type GDT: BusinessTransactionDocumentParty, where the“InternalID” is used. If no ShipToLocation is explicitly specified, theProductRecipientParty address is the delivery address. If noProductRecipientParty entity 40234 is explicitly specified, theBuyerParty entity 40230 acts as ProductRecipientParty.

The ProductRecipientParty entity 40234 includes the same Address andContact entities 40216A as found for the BuyerParty 40230.

(d) Vendor Party

A VendorParty is a company or person that delivers goods or providesservices. The VendorParty entity 40236 is of type GDT:BusinessTransactionDocumentParty, where the “InternalID” is used. If noShipFromLocation is explicitly specified, the VendorParty address is theship-from address. If no VendorParty entity 40236 is explicitlyspecified, the SellerParty entity 40232 is also VendorParty. TheVendorParty is not the company or person that is solely responsible fortransporting the goods. The CarrierParty is responsible for this.

The VendorParty entity 40236 includes the same Address and Contactentities 40218A as found for the BuyerParty 40230.

(e) Bill To Party

A BillToParty is a company or person to which the invoice for goods orservices is sent. The BillToParty entity 402 38 is of type GDT:BusinessTransactionDocumentParty, where the “InternalID” is used. If noBillToParty entity 40238 is explicitly specified, the BuyerParty acts asBillToParty.

The BillToParty entity 402 38 includes the same Address and Contactentities 40220A as found for the BuyerParty 40230.

(f) Bill From Party

A BillFromParty is a company or person that draws up the invoice forgoods or services. The BillFromParty entity 40240 is of type GDT:BusinessTransactionDocumentParty, where the “InternalID” is used. If noBillFromParty entity 40240 is explicitly specified, the SellerPartyentity 40232 acts as BillFromParty.

The BillFromParty entity 40240 includes the same Address and Contactentities 40222A as found for the BuyerParty 40230.

(g) Payer Party

A PayerParty is a company or person that pays for goods or services. ThePayerParty entity 40242 is of type GDT:BusinessTransactionDocumentParty, where the “InternalID” is used. If noPayerParty entity 40242 is explicitly specified, the BillToParty entity40230 acts as PayerParty.

The PayerParty entity 40242 includes the same Address and Contactentities 40224A as found for the BuyerParty 40230.

(h) Payee Party

A PayeeParty is a company or person that receives payment for goods orservices. The PayeeParty entity 40244 is of type GDT:BusinessTransactionDocumentParty, where the “InternalID” is used. If noPayeeParty entity 40244 is explicitly specified, the BillFromPartyentity 40240 acts as PayeeParty.

The PayeeParty entity 40244 includes the same Address and Contactentities 40226A as found for the BuyerParty 40230.

(iii) Location Package

The Location package 40210 groups all locations that can occur in asettlement. The Location package 40210 includes a ShipToLocation entity40228A and a ShipFromLocation entity 40230A. There is a 1:c relationship40232A between the InvoiceDue entity 40226 and the ShipToLocation entity40228A. There is a 1:c relationship 40234A between the InvoiceDue entity40226 and the ShipFromLocation entity 40230A.

Default logic is used for all locations: locations that are specified atInvoiceDue level are used for all items for which correspondinglocations are not explicitly transmitted. ShipToLocation andShipFromLocation can be used to provide a detailed description of theflow of goods (between the ship-to location and the ship-from location).In specific countries, this detailed information is required forcalculating taxes (e.g., United States).

(a) Ship To Location

A ShipToLocation is the place to which goods are shipped or whereservices are provided. The ShipToLocation entity 40228A is of type GDT:BusinessTransactionDocumentLocation. A sold-to party (BuyerParty)headquartered in California in the US orders steel beams for a building.The construction site (ShipToLocation) for the building is located inArizona. The tax amount is calculated using the tax rates that apply inArizona.

The ShipToLocation entity 40228 includes an Address entity 40236A. Thereis a 1:c relationshiop 40238A between Address entity 40236A andShipToLocation 40228A.

The Address entity 40236A includes a PersonName entity 40240A, an Officeentity 40242A, a PhysicalAddress entity 40244A, a GeoCoordinates entity40246A, and a Communication entity 40248A. There is a 1:c relationship40250A between the PersonName entity 40240A and the Address entity40236A. There is a 1:c relationship 40252A between the Office entity40242A and the Address entity 40236A. There is a 1:c relationship 40254Abetween the PhysicalAddress entity 40244A and the Address entity 40236A.There is a 1:c relationship 40256A between the GeoCoordinates entity40246A and the Address entity 40236A. There is a 1:c relationship 40258Abetween the Communication entity 40248A and the Address entity 40236A.

(b) Ship From Location

A ShipFromLocation is the place from which goods are shipped. TheShipFromLocation 40230A is of type GDT:BusinessTransactionDocumentLocation.

The ShipFromLocation 40230A includes the same Address entity information40259A as found for the ShipToLocation entity 40228A.

(iv) Delivery Information Package

The DeliveryInformation package 40212 groups all information for arequired delivery in the settlement. It includes a DeliveryTerms entity40260A. The default logic used for DeliveryTerms is similar to that usedfor Parties. There is a 1:c relationship 40262A between the InvoiceDueentity 40226 and the DeliveryTerms entity 40260A.

DeliveryTerms are the conditions and agreements that are valid forexecuting the delivery and transporting the ordered goods and for thenecessary services and activities. The DeliveryTerms entity 40260A istype GDT: DeliveryTerms. Of the DeliveryTerms, Incoterms and transportcan be used for material items. The default logic takes Incoterms andtransport into account for material items. For all other items,Incoterms and transport are ignored.

(v) Payment Information Package

The PaymentInformation package 40214 groups payment information in thesettlement. The PaymentInformation package 40214 includes aCashDiscountTerms entity 40264A and a PaymentForm entity 40266A. Thereis a 1:c relationship 40268A between the InvoiceDue entity 40226 and theCashDiscountTerms entity 40264A. There is a 1:c relationship 402670Abetween the InvoiceDue entity 40226 and the PaymentForm entity 40266A.The default logic used for CashDiscountTerms and the PaymentForm issimilar to that used for Parties. In some variations, thePaymentInformation package 40214 also includes a MaximumDiscount entity40272A, a NormaIDiscount entity 40274A, and a PaymentCard entity 40276A.There is a 1:c relationship 40278A between the CashDiscountTerms entity40264A and the MaximumDiscount entity 40272A. There is a 1:crelationship 40280A between the CashDiscountTerms entity 40264A and theNormaIDiscount entity 40274A. There is a 1:c relationship 40282A betweenthe PaymentForm entity 40266A and the PaymentCard entity 40266A.

(a) Cash Discount Terms

The CashDiscountTerms are the terms of payment (cash discount rates andpayment deadlines). The CashDiscountTerms entity 40264A is type GDT:CashDiscountTerms.

(b) Payment Form

The PaymentForm is the payment form and the data required for it. ThePaymentForm entity 40266A includes the PaymentCard entity 40276A. ThePaymentFormCode is the coded representation of the payment form. Thevalid payment form in a billing process is determined in accordance withthe following rules: (1) If the payment form was transmitted explicitlywith an invoice, this payment form applies, otherwise (2) If the paymentform was agreed upon by both parties, this payment method applies,otherwise (3) standard payment form applies, as defined in the GDT:PaymentFormCode. PaymentCard is to be filled for the payment form“PaymentCard; for all other payment forms, it can be ignored by therecipient.

The PaymentCard is a credit card or a customer card. The PaymentCardentity 40276A is of type GDT: PaymentCard.

(vi) Price Information Package

The PriceInformation package 40216 summarizes all the information aboutthe total amount to be settled for products and services and details allthe tax price components. It includes a Price entity 40284A. There is a1:c relationship 40286A between the InvoiceDue entity 40226 and thePrice entity 40284A.

The Price entity 40270A is the total amount to be settled for productsand services, including tax and net portions. The Price entity 40284Aincludes a GrossAmount, a NetAmount, a TaxAmount, an ExchangeRate, and aPricingDate. The GrossAmount is the gross invoice amount; net amountplus tax amount, and is of type GDT: Amount. The NetAmount is the netinvoice amount, and is of type GDT: Amount. The TaxAmount is the taxamount of an invoice, and is of type GDT: Amount. The ExchangeRate isthe information about the exchange rate, and is of type GDT:ExchangeRate. The PricingDate is the date on which the price iscalculated, and is of type GDT: DateTime.

The gross and net amounts are specified in the same currency. If afollowing currency is specified in the ExchangeRate element, thefollowing currency is the same as the currency in the gross/net amount.If the ExchangeRate element is not specified at all, the currency of thegross/net amount is set as the following and leading currency (in thiscase, the exchange rate would be set to the uniform rate). Specifyingcurrencies at header level is optional. If they are specified, they arethe same as the currencies specified at item level.

Currencies (following and leading currency) for a settlement do not haveto be specified unless the SalesOrderReference entity is not specified(filled with values) at InvoiceDueItem level in theBusinessTransactionDocumentReference package.

(vii) Account Assigmmet Package

The AccountAssignment package 40218 groups account assignmentinformation for accounting. It includes an AccountAssignment entity40288A. There is a 1:nc relationship 40290A between the InvoiceDueentity 40226 and the AccountAssignment entity 40288A.

The AccountAssignment package 40218 includes all information about theaccount assignment objects in accounting to which the base businesstransaction refers. The account assignment can be distributed to variousobjects (such as the cost center or order) on a percentage basis. Inthis case, the total of the account assignments is 100%. The defaultlogic used for the AccountAssignment package 40218 is similar to thatused for Parties.

An AccountAssignment provides information about an account assignmentobject and the percentage rate to be used. The AccountAssignment entity40288A is of type GDT: AccountingObjectSetDistribution.

(viii) Attachment Package

The Attachment package 40220 groups all attachment information regardingthe settlement process. It includes an AttachmentWebAddress entity40292A. There is a 1:cn relationship 40294A between the InvoiceDueentity 40226 and the AttachmentWebAddress entity 40292A.

The AttachmentWebAddress is a web address for a document of any typethat relates to a settlement. The AttachmentWebAddress entity 40292A isof type GDT: AttachmentWebAddress.

(ix) Description Package

The Description package 40222 groups all explanatory texts regarding asettlement. It includes a Description entity 40296A. There is a 1:crelationship 40298A between the InvoiceDue entity 40226 and theDescription entity 40296A.

The Description is natural-language text with additional informationabout a settlement. Description entity 40296A is of type GDT:Description.

(c) Invoice Due Item Package

The InvoiceDueItem package 40224 groups item information from the basicbusiness document for the future settlement. It includes aProductInformation package 40200B, a PriceInformation package 40202B, aParty package 40204B, a Location package 40206B, a DeliveryInformationpackage 40208B, a PaymentInformation package 40210B, aBusinessTransactionDocumentReference package 40212B, anAccountAssignment package 40214B, an Attachment package 40216B, aDescription package 40218B, an Item entity 40229BB and anItemHierarchyRelationship entity 40224B. There is a 1:n relationship40222B between the InvoiceDue entity 40226 and the Item entity 40220B.There is a 1:c relationship 40226B or a 1:cn relationship 40228B betweenthe Item entity 40220B and the ItemHierarchyRelationship 40224B.

(i) Invoice Due Item

An InvoiceDueItem entity 40220B summarizes all information from abusiness document item that is to be taken into account in the futuresettlement. The InvoiceDueItem entity 40220B typically consists ofinformation about the quantity of a product that has been ordered ordelivered, as well as business partners, locations, terms of deliveryand payment conditions and the other business documents to be taken intoaccount when the product is settled.

The InvoiceDueItem entity 40220B includes aBaseBusinessTransactionDocumentID, aBaseBusinessTransactionDocumentItemTypeCode, an ActionCode, aSettlementRelevanceIndicator, an EvaluatedReceiptSettlementIndicator, aSettlementBlockedIndicator, a PricingIndicator, a PlannedBillingDate, aProposedInvoiceDate, a DeliveryPeriod, and a Quantity. TheBaseBusinessTransactionDocumentID is a unique identifier for the item inthe base business document for the InvoiceDue, and is of type GDT:BusinessTransactionDocumentID. TheBaseBusinessTransactionDocumentItemTypeCode is the coded representationof the type of the item in which the base business document for theInvoiceDue is stored. Information about the calendar day. Currently, thetypes sales order item and delivery item are relevant for the messagetype BillingDueNotification; the types purchase order item, sales orderitem, and delivery item are relevant for the message typeInvoicingDueNotification. TheBaseBusinessTransactionDocumentItemTypeCode is of type GDT:BusinessTransactionDocumentItemTypeCode. The ActionCode is the codedrepresentation of the request to the recipient of the InvoiceDue messageto create, change, and delete InvoiceDueItems, and is of type GDT:ActionCode. The SettlementRelevanceIndicator indicates whether thespecified item is subject to settlement, and is of type GDT:BusinessTransactionDocumentSettlementRelevanceIndicator. TheEvaluatedReceiptSettlementIndicator is the indicator that specifieswhether an invoice is to be automatically created for the item, and isof type GDT: EvaluatedReceiptSettlementIndicator. TheSettlementBlockedIndicator specifies whether a settlement item isblocked for further processing, and is of type GDT:BusinessTransactionBlockedIndicator. The PricingIndicator specifieswhether pricing/price determination is to be performed for the specifieditem, and is of type GDT: BusinessTransactionDocumentPricingIndicator.The PlannedBillingDate is the planned date for billing a specified item,and is of type GDT: Date. The ProposedInvoiceDate is the date for thebilling document for a specified item, and is of type GDT: DateTime. TheDeliveryPeriod specifies the exact time or the period of time duringwhich a service is provided, and is of type GDT: DateTimePeriod. TheQuantity is the quantity of the product to be settled, and is of typeGDT: Quantity.

The elements BaseBusinessTransactionDocumentItemID,BusinessTransactionDocumentItemTypeCode, SettlementRelevanceIndicator,and Quantity is specified (except in the case of group hierarchy items).The soft semantic (ActionCodes “04”/“05”) is used for the ActionCode,since the applications receiving the data contain the data subject tosettlement from the transmitted item. ActionCode “04” is interpreted bythe receiving statement as a change statement for the item to betransmitted, provided that this has already been transmitted by aprevious message. If this is not the case, the transmitted item iscreated. The ActionCode “05” (REMOVE) signalizes to the receivingapplication that item transmitted previously for a business transaction(and cancelled now) are not relevant for settlement any more. Initially,this information about the calendar day is used from theProposedInvoiceDate element; hours, minutes, and seconds are ignored.

The element EvaluatedReceiptSettlementIndicator is not used.

Default logic is used for the following elements:SettlementRelevanceIndicator, SettlementBlockedIndicator,DeletedIndicator, and DeliveryDateTimePeriod: if values are nottransmitted at InvoiceDueItem level, the values from the InvoiceDuelevel are used. If values were not transmitted at InvoiceDue andInvoiceDueItem level, the relevant indicators are NOT set. From theDeliveryPeriod element, the date specified in the StartDateTimeattribute is interpreted as being the date on which a service isprovided (requested delivery date, date of the goods issue posting); allother information is ignored. From a semantic perspective,InvoiceDueItems can contain other items. This enables item hierarchiesto be mapped. The hierarchies are mapped using a ParentItemID and anItemHierarchyTypeCode.

There are various types of item, which are governed by a variety ofintegrity conditions. In particular, Standard items are items that areneither above nor below any other items in the hierarchy, Hierarchyitems are items that are above other items in the hierarchy, andSubitems are items that are below other items in the hierarchy. The typeof subitem and the way it is used is indicated using theItemHierarchyRelationTypeCode.

(ii) Invoice Due Item Product Information Package

The InvoiceDueItemProductInformation package 40200B groups allinformation required for identifying, describing, and classifying aproduct for which an invoice is due. It includes a Product 40230B and aProductCategory 40232B. There is a 1:c relationship 40234B between theItem entity 40220B and the Product entity 40230B. There is a 1:crelationship 40236B between the Item entity 40220B and theProductCategory 40232B.

(a) Product

The Product entity 40230B identifies, describes, and classifies aproduct for which an invoice is due. The Product entity 40230B is oftype GDT: Product. A product is specified when the line item instance isnot a grouping or unplanned delivery costs.

(b) Product Category

The ProductCategory entity 40232B is the product category of theproduct/service that is being invoiced. The ProductCategory entity40232B is of type GDT: ProductCategory. The product category derivesdirectly from the product and can vary if the buyer and seller haveassigned the same product to different categories. This is allowed andshould be tolerated by the systems involved.

(iii) Invoice Due Item Price Information Package

The InvoiceDueItemPriceInformation package 40202B summarizes all theinformation about the amount to be settled for a product or a service,including all price components. The InvoiceDueItemPriceInformationpackage 40202B includes a Price entity 40238B, a NetUnitPrice entity40246B, and a ProcurementCostUpperLimit entity 40240B. There is a 1:crelationship 40242B between the Item entity 40220B and the Price entity40238B. There is a 1:c relationship 40244B between the Item entity40220B and the ProcurementCostUpperLimit entity 40240B. There is a 1:crelationship 40248B between the Price entity 40238B and the NetUnitPriceentity 40246B.

(a) Price

The Price is the amount to be settled for a product or service,including tax and net portions. The Price entity 40238B includes aGrossAmount, a NetAmount, a TaxAmount, an ExchangeRate, and aPricingDate. The GrossAmount is the gross invoice amount; net amountplus tax amount, and is of type GDT: Amount. The NetAmount is the netinvoice amount, and is of type GDT: Amount. The TaxAmount is the taxamount of an invoice, and is of type GDT: Amount. The ExchangeRate isthe information about the exchange rate, and is of type GDT:ExchangeRate. The PricingDate is the date on which the price iscalculated, and is of type GDT: DateTime. The Price entity 40238B alsoincludes a NetUnitPrice entity 40246B.

The elements NetAmount, GrossAmount, and TaxAmount are specified whenthe specified line item instance is not an item used simply for groupingpurposes. The gross and net amounts for an item are in the samecurrency. If a following currency is specified in the ExchangeRateelement, the following currency is the same as the currency of thegross/net amount. If the following and leading currencies are notspecified in the ExchangeRate element, the currency of the gross/netamount is set as the following and leading currency (in this case, theexchange rate would be set to the uniform rate). Currencies specified atheader/item level are the same.

NetUnitPrice is the net price for the base quantity of a product thatwas used to calculate the net amount. The NetUnitPrice entity 40246B isof type GDT: Price. For Example, e 10 for 5 pieces.

(b) Procurement Cost Upper Limit

The ProcurementCostUpperLimit is a quantity or value-based restrictionplaced on a product or service to be settled. TheProcurementCostUpperLimit 40240B is of type GDT:ProcurementCostUpperLimit.

The element ProcurementCostUpperLimit is ignored.

(iv) Invoice Due Item Party Package

The InvoiceDueItemParty package 40224 includes a BuyerParty entity40250B, a SellerParty entity 40252B, a ProductRecipientParty entity40254B, a VendorParty entity 40256B, a BillToParty entity 40258B, aBillFromParty entity 40260B, a PayerParty entity 40262B, and aPayeeParty entity 40264B. There is a 1:c relationship 40266B between theItem entity 40220B and the BuyerParty 40250B. There is a 1:crelationship 40268B between the Item entity 40220B and the SellerParty40252B. There is a 1:c relationship 40270B between the Item entity40220B and the ProductRecipientParty 40254B. There is a 1:c relationship40272B between the Item entity 40220B and the VendorParty 40256B. Thereis a 1:c relationship 40274B between the Item entity 40220B and theBillToParty 40258B. There is a 1:c relationship 40276B between the Itementity 40220B and the BillFromParty 40260B. There is a 1:c relationship40278B between the Item entity 40220B and the PayerParty 40262B. Thereis a 1:c relationship 40280B between the Item entity 40220B and thePayeeParty 40264B.

The InvoiceDueItemParty package 40224 is similar to the Party package40208 at the InvoiceDue level. Thus, BuyerParty entity 40250B includessimilar Address and Contact entity information 40282B as found forBuyerParty entity 40230 in the Party package 40208. Similarly,SellerParty entity 40252B includes similar Address and Contact entityinformation 40284B as found for SellerParty entity 40232B in the Partypackage 40208. Similarly, ProductRecipientParty entity 40254B includessimilar Address and Contact entity information 40286B as found forProductRecipientParty entity 40234B in the Party package 40208.Similarly, VendorParty entity 40256B includes similar Address andContact entity information 40288B as found for VendorParty entity 40236Bin the Party package 40208. Similarly, BillToParty entity 40258Bincludes similar Address and Contact entity information 40290B as foundfor BillToParty entity 40238B in the Party package 40208. Similarly,BillFromParty entity 40260B includes similar Address and Contact entityinformation 40292B as found for BillFromParty entity 40240B in the Partypackage 40208. Similarly, PayerParty entity 40262B includes similarAddress and Contact entity information 40294B as found for PayerPartyentity 40242B in the Party package 40208. Similarly, PayeeParty entity40264B includes similar Address and Contact entity information 40296B asfound for PayeeParty entity 40244B in the Party package 40208.

Default logic is used for all business partners: business partners thatare specified at InvoiceDue level are used for all the items for which acorresponding partner is not explicitly transmitted. The default logicapplies for the partner as a whole, including the contact person. Partsof a partner cannot be specified in more detail at item level. Thedefault logic is a simplified version of the transmitted message. Interms of logic, partners at InvoiceDue level behave as if they have beenexplicitly transmitted for all the items of the message.

(v) Invoice Due Item Location Package

The InvoiceDueItemLocation package 40206B includes a ShipToLocationentity 40298B and a ShipFromLocation entity 40200C. TheInvoiceDueItemLocation package 40206B may also include an Address entitysimilar to the Address entity 40236A in the Location Package 40210 atthe InvoiceDue level. There is a 1:c relationship 40202C between theItem entity 40220B and the ShipToLocation 40298B. There is a 1:crelationship 40204C between the Item entity 40220B and theShipFromLocation entity 40200C

The InvoiceDueItemLocation package 40206B is similar to the Locationpackage 40210 at InvoiceDue level. Thus, the ShipToLocation entity40298B contains the same Address entity information 40206C as foundassociated with ShipToLocation entity 40228A in the Location package40210. Similarly, the ShipFromLocation entity 40200C contains the sameAddress entity information 40208C as found associated withShipFromLocation entity 40230A in the Location package 40210.

(vi) Invoice Due Item Delivery Information Package

The InvoiceDueItemDeliveryInformation package 40208B is similar to theDeliveryInformation package 40212 at InvoiceDue level. TheInvoiceDueItemDeliveryInformation package 40208B includes aDeliveryTerms entity 40210C. There is a 1:c relationship 40212C betweenthe Item entity 40220B and the DeliveryTerms entity 40210C.

(vii) Invoice Due Item Payment Information Package

The InvoiceDueItemPaymentInformation package 40210B is similar to thePaymentInformation package 40214 at InvoiceDue level. TheInvoiceDueItemPaymentInformation package 40210B includes aCashDiscountTerms entity 40214C and a PaymentForm entity 40216C. Thereis a 1:c relationship 40218C between the Item entity 40220B and theCashDiscountTerms entity 40214C. There is a 1:c relationship 40220Cbetween the Item entity 40220B and the PaymentForm entity 40216C. Thedefault logic used for CashDiscountTerms and the PaymentForm is similarto that used for Parties. In some variations, the PaymentInformationpackage 40210B also includes a MaximumDiscount entity 40222C, aNormaIDiscount entity 40224C, and a PaymentCard entity 40230C. There isa 1:c relationship 40226C between the CashDiscountTerms entity 40214Cand the MaximumDiscount entity 40222C. There is a 1:c relationship40228C between the CashDiscountTerms entity 40214C and theNormaIDiscount entity 40224C. There is a 1:c relationship 40232C betweenthe PaymentForm entity 40216C and the PaymentCard entity 40230C.

(viii) Invoice Due Item Business Transaction Document Reference Package

The InvoiceDueItemBusinessTransactionDocumentReference package 40212Bgroups all references to business documents that could be relevant forsettling an InvoiceDueItem. TheInvoiceDueItemBusinessTransactionDocumentReference package 40212Bincludes a PurchaseOrderReference entity 40234C, a SalesOrderReferenceentity 40236C, a DeliveryReference entity 40238C, aPurchaseContractReference entity 40240C, a SalesContractReference entity40242C, a BuyerProductCatalogueReference entity 40244C, and aSellerProductCatalogueReference entity 40246C. There is a 1:crelationship 40248C between the Item entity 40220B and thePurchaseOrderReference entity 40248C. There is a 1:c relationship 40250Cbetween the Item entity 40220B and the SalesOrderReference entity40236C. There is a 1:c relationship 40252C between the Item entity40220B and the DeliveryReference entity 40238C. There is a 1:crelationship 40254C between the Item entity 40220B and thePurchaseContractReference entity 40240C. There is a 1:c relationship40256C between the Item entity 40220B and the SalesContractReferenceentity 40242C. There is a 1:c relationship 40258C between the Itementity 40220B and the BuyerProductCatalogueReference entity 40244C.There is a 1:c relationship 40260C between the Item entity 40220B andthe VendorProductCatalogueReference entity 40246C.

(a) Purchase Order Reference

A PurchaseOrderReference is the reference to a purchase order or to anitem within a purchase order. The PurchaseOrderReference entity 40234Cis of type GDT: BusinessTransactionDocumentReference. ThePurchaseOrderReference entity 40234C is transmitted in theBillingDueNotification from CRM Sales to Billing so that it can beoutput together with the invoice. The PurchaseOrderReference entity40234C includes the purchase order number assigned by the buyer.

(b) Sales Order Reference

A SalesOrderReference is the reference to an order or an item within anorder. The SalesOrderReference entity 40236C is of type GDT:BusinessTransactionDocumentReference. The SalesOrderReference entity40236C is to be transmitted in the InvoicingDueNotification from SRMProcurement to Invoicing when the procurement system knows what theorder number is (e.g., using the PurchaseOrderConfirmation). TheSalesOrderReference entity 40236C includes the order number assigned bythe seller.

(c) Delivery Reference

A DeliveryReference is the reference to a delivery (delivery notenumber) or an item within a delivery. The DeliveryReference entity40238C is of type GDT: BusinessTransactionDocumentReference.

The DeliveryReference entity 40238C is to be transmitted in theInvoicingDueNotification from Supply Chain Execution to Invoicing whenthe vendor delivery note number is known.

The DeliveryReference entity 40238C includes the delivery note numberassigned by the seller.

(d) Purchase Contract Reference

A PurchaseContractReference is the reference to a purchase contract orto an item within a purchase contract. The PurchaseContractReferenceentity 40240C, is of type GDT: BusinessTransactionDocumentReference.Provided there is no agreement to the contrary, the seller isresponsible for determining the correct SellerContractReference for acorresponding BuyerContractReference.

(e) Sales Contract Reference

A SalesContractReference is the reference to a sales contract or to anitem within a sales contract. The SalesContractReference entity 4024C isof type GDT: BusinessTransactionDocumentReference.

(f) Buyer Product Catalogue Reference

A BuyerProductCatalogueReference is the reference to a buyer's productcatalog or to an item within this catalog. TheBuyerProductCatalogueReference entity 40244C is of type GDT:CatalogueReference. The BuyerProductCatalogueReference entity 40244C isalways to be filled when an invoice item refers to a catalogue whosenumber and whose item numbers were assigned by the buyer.

(g) Seller Product Catalogue Reference

A SellerProductCatalogueReference is the reference to a seller's productcatalog or to an item within this catalog. TheSellerProductCatalogueReference entity 40246C is of type GDT:CatalogueReference. SellerProductCatalogueReference entity 40246C isalways to be filled when an invoice item refers to a catalog whosenumber and whose item numbers were assigned by the seller.

(ix) Invoice Due Item Account Assignment Package

The InvoiceDueItemAccountAssignment package 40214B is similar to theAccountAssignment package 40218 at InvoiceDue level. TheAccountAssignment package 40214B groups account assignment informationfor accounting. The AccountAssignment package 40214B includes anAccountAssignment entity 40262C. There is a 1:nc relationship 40264Cbetween the Item entity 40220B and the AccountAssignment entity 40262C.

The AccountAssignment package 40214B includes all information about theaccount assignment objects in accounting to which the base businesstransaction refers. The account assignment can be distributed to variousobjects (such as the cost center or order) on a percentage basis. Inthis case, the total of the account assignments is 100%. The defaultlogic used for the AccountAssignment package 40214B is similar to thatused for Parties.

An AccountAssignment provides information about an account assignmentobject and the percentage rate to be used. The AccountAssignment entity40262C is of type GDT: AccountingObjectSetDistribution.

(x) Invoice Due Item Attachment Package

The InvoiceDueItemAttachment package 40216B is similar to the Attachmentpackage 40220 at InvoiceDue level. The InvoiceDueItemAttachment package40216B groups all attachment information regarding the settlementprocess. InvoiceDueItemAttachment package 40216B includes an Attachmententity 40266C. There is a 1:cn relationship 40268C between the Itementity 40220B and the Attachment entity 40266C.

The AttachmentWebAddress is a web address for a document of any typethat relates to a settlement. The AttachmentWebAddress entity 40266C isof type GDT: AttachmentWebAddress.

(xi) Invoice Due Item Description Package

The InvoiceDueItemDescription package 40218B is similar to theDescription package 40222 at InvoiceDue level. The Description package40218B groups all explanatory texts regarding a settlement. It includesa Description entity 40270C. There is a 1:c relationship 40272C betweenthe Item entity 40220B and the Description entity 40270C.

The Description is natural-language text with additional informationabout a settlement. The Description entity 40270C is of type GDT:Description.

(4) Message Data Type Data Model InvoiceDueCancellationRequest

FIG. 403 depicts a data model for the InvoiceDueCancellationRequestprocess that can be used in some business scenarios. The message datatype InvoiceDueCancellationMessage includes anInvoiceDueCancellationMessage package 40302, which contains theInvoiceDueCancellation object contained in the business document and thebusiness information that is relevant for sending a business document ina message. The InvoiceDueCancellationMessage package 40302 includes aMessageHeader package 40304, an InvoiceDueCancellation package 40306,and an InvoiceDueCancellationMessage entity 40308.

The message data type InvoiceDueCancellationMessage makes the structureavailable for the following message types:InvoicingDueCancellationRequest, BillingDueCancellationRequest and therelevant interfaces.

(a) MessageHeader Package

The MessageHeader package 40304 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader package 40304 is similar to the MessageHeader package40202 in the InvoiceDueMessage package 40200.

(b) InvoiceDueCancellation Package

The InvoiceDueCancellation package 40306 groups together informationthat is required to completely cancel an InvoiceDueMessage that hasalready been sent and to cancel the settlement process. TheInvoiceDueCancellation package 40306 includes the InvoiceDueCancellationentity 40310. There is a 1:1 relationship 40312 between theInvoiceDueCancellationMessage entity 40308 and theInvoiceDueCancellation entity 40310.

(c) InvoiceDueCancellation

The InvoiceDueCancellation entity 40310 is a request to exclude businessdocument data that has already been sent from the settlement. TheInvoiceDueCancellation 40310 includes aBaseBusinessTransactionDocumentID and aBaseBusinessTransactionDocumentTypeCode. TheBaseBusinessTransactionDocumentID is a unique identifier for a basebusiness document for an InvoiceDue Message that has already been sent.It has a data type GDT: Business TransactionDocumentID. TheBaseBusinessTransactionDocumentTypeCode is a coded representation of thetype of the base business document for an InvoiceDueMessage that hasalready been sent. The BaseBusinessTransactionDocumentTypeCode has adata type of GDT: BaseBusinessTransactionDocumentTypeCode.

(5) Message Data Type Element Structure

FIG. 404 depicts the element structure for InvoicingDueMessage. Theelement structure identifies the different packages 40400 in theinterface, and represents the entities at various levels within theinterface. As shown in FIG. 404, the interface for InvoicingDueRequestincludes five levels 40402, 40404, 40406, 40408, 40410. The elementstructure identifies the number of occurrences 40412 of each element andprovides a Datatype name 40414 for each element.

The outermost package of this interface is InvoiceDueMessage package40416, which includes a InvoiceDueMessage entity 40418 at the firstlevel 40402. The InvoiceDueMessage entity 40418 is of data type MDT:InvoiceDueMessage 40420.

The InvoiceDueMessage package 40416 includes an InvoiceDue package40422, which includes an InvoiceDue entity 40424 at the second level40404. The InvoiceDue entity 40424 has one occurrence 40426 and is ofdata type InvoiceDue 40428.

The InvoiceDue entity 40424 includes a BaseBusinessTransactionDocumentID40430, a BaseBusinessDocumentTypeCode 40436, a SettlementPriorityCode40442, a SettlementRelevanceIndicator 40448, aSettlementBlockedIndicator 40454, anItemListCompleteTransmissionIndicator 40460, a PlannedBillingDate 40466,a DeliveryPeriod 40472, and a ProposedInvoiceDate 40478 at the thirdlevel 40406. The BaseBusinessTransactionDocumentID 40430 has oneoccurrence 40432 and is of data type GDT: BusinessTransaction DocumentID40434. The BaseBusinessDocumentTypeCode 40436 has one occurrence 40438and is of data type GDT: BusinessTransaction DocumentTypeCode 40440. TheSettlementPriorityCode 40442 has zero or one occurrence 40444 and is ofdata type GDT: BusinessTransaction Priority Code 40446. The SettlementRelevance Indicator 40448 has zero or one occurrence 40450 and is ofdata type GDT: BusinessTransaction DocumentSettlement RelevanceIndicator40452. The SettlementBlockedIndicator 40454 has zero or one occurrence40456 and is of data type GDT: BusinessTransactionBlockedIndicator40458. The ItemListCompleteTransmission Indicator 40460 has zero or oneoccurrence 40462 and is of data type GDT: CompleteTransmissionIndicator40464. The PlannedBilling Date 40466 has zero or one occurrence 40468and is of data type GDT: Date 40470. The DeliveryPeriod 40472 has zeroor one occurrence 40474 and is of data type GDT: DateTimePeriod 40476.The ProposedInvoiceDate 40478 has zero or one occurrence 40480 and is ofdata type GDT: DateTime 40482.

The InvoiceDue package 40422 includes a Party package 40484, a Locationpackage 40486, a Delivery Information package 40488, a PaymentInformation package 40490, a Price Information package 40492, an AccountAssignment package 40494, an Attachment package 40496, a Descriptionpackage 40498, and an Item package 40400A.

The Party package 40484 includes a BuyerParty entity 40402A, aSellerParty entity 40408A, a ProductRecipientParty entity 40414A, aVendorParty entity 40420A, a BillToParty entity 40426A, a BillFromPartyentity 40432A, a PayerParty entity 40438A, and a PayeeParty entity40444A at the third level 40406. The BuyerParty entity 40402A has zeroor one occurrence 40404A and a data type of GDT:BusinessTransactionDocumentParty 40406A. The SellerParty entity 40408Ahas zero or one occurrence 40410A and a data type of GDT:BusinessTransaction DocumentParty 40412A. The ProductRecipientPartyentity 40414A has zero or one occurrence 40416A and a data type of GDT:BusinessTransactionDocumentParty 40418A. The VendorParty entity 40420Ahas zero or one occurrence 40422A and a data type of GDT:BusinessTransactionDocumentParty 40424A. The BillToParty entity 40426Ahas zero or one occurrence 40428A and a data type of GDT:BusinessTransactionDocumentParty 40430A. The BillFromParty entity 40432Ahas zero or one occurrence 40434A and a data type of GDT:BusinessTransactionDocumentParty 40436A. The PayerParty entity 40438Ahas zero or one occurrence 40440A and a data type of GDT:BusinessTransactionDocumentParty 40442A. The PayeeParty entity 40444Ahas zero or one occurrence 40446A and a data type of GDT:BusinessTransactionDocument Party 40448A.

The Location package 40486 includes a ShipToLocation entity 40450A and aShipFromLocation entity 40456A at the third level 40406. TheShipToLocation entity 40450A has zero or one occurrence 40452A and adata type of GDT: BusinessTransaction DocumentLocation 40454A. TheShipFromLocation entity 40456A has zero or one occurrence 40458A and adata type of GDT: BusinessTransactionDocumentLocation 40460A.

The DeliveryInformation package 40488 includes a DeliveryTerms entity40462A at the third level 40406, which has zero or one occurrences40464A and a data type of GDT: DeliveryTerms 40466A.

The PaymentInformation package 40490 includes a CashDiscountTerms entity40468A and a PaymentForm entity 40474A at the third level 40406. TheCashDiscountTerms entity 40468A has zero or one occurrences 40470A and adata type of GDT: CashDiscountTerms 40472A. The PaymentForm entity40474A has zero or one occurrences 40476A and a data type of GDT:PaymentForm 40478A.

The PriceInformation package 40492 includes a Price entity 40480A at thethird level 40406, which has zero or one occurrences 40482A. The Priceentity 40480A includes a GrossAmount 40484A, a NetAmount 40490A, aTaxAmount 40496A, an ExchangeRate 40402B, and a PricingDate 40408B atthe fourth level 40408. The GrossAmount 40484A has zero or oneoccurrences 40486A and a data type of GDT: Amount 40488A. The NetAmount40490A has zero or one occurrences 40492A and a data type of GDT: Amount40494A. The TaxAmount 40496A has zero or one occurrences 40498A and adata type of GDT: Amount 40400B. The ExchangeRate 40402B has zero or oneoccurrences 40404B and a data type of GDT: ExchangeDate 40406B. ThePricingDate 40408B has zero or one occurrences 40410B and a data type ofGDT: DateTime 40412B.

The AccountAssigrnment package 40494 includes an AccountAssigrnmententity 40414B at the third level 40406, which has zero or oneoccurrences 40416B and a data type of GDT:AccountingObjectSetDistribution 40418B .

The Attachment package 40496 includes an AttachmentWebAddress entity40420B at the third level 40406, which has any number of occurrences40422B and a data type of GDT: AttachmentWebAddress 40424B.

The Description package 40498 includes a Description entity 40426B atthe third level 40406, which has zero or one occurrences 40428B and adata type of GDT: Description 40430B.

The Item package 40400A has an Item entity 40432B at the third level40406, which has at least one occurrence 40434B and a data type of GDT:InvoiceDueItem 40436B. The Item entity 40432B includes aBaseBusinessTransaction DocumentItemID 40438B, a BaseBusinessTransactionDocumentItemTypeCode 40444B, a BaseBusinessTransactionDocumentItemDeletedIndicator 40450B, a SettlementRelevanceIndicator40455B, an EvaluatedReceiptSettlementIndicator 40460B, aSettlementBlockedIndicator 40466B, a PricingIndicator 40472B, aPlannedBillingDate 40478B, a ProposedInvoiceDate 40484B, and a HierarchyRelationship 40490B at the fourth level 40408.

The BaseBusinessTransaction DocumentItemID 40438B has one occurrence40440B and a data type of GDT: BusinessTransactionDocument ItemID40442B. The BaseBusinessTransactionDocumentItemTypeCode 40444B has oneoccurrence 40446B and a data type of GDT: BusinessTransactionDocumentItemTypeCode 40448B. TheBaseBusinessTransactionDocumentItemDeletedIndicator 40450B has oneoccurrence 40452B and a data type of GDT: Deleted Indicator 40454B. TheSettlementRelevanceIndicator 40455B has zero or one occurrences 40456Band a data type of GDT: BusinessTransactionDocumentSettlementRelevanceIndicator 40458B. The EvaluatedReceiptSettlementIndicator 40460B has zero or one occurrences 40462B and a data type ofGDT: EvaluatedReceiptSettlementIndicator 40464B. TheSettlementBlockedIndicator 40466B has zero or one occurrences 40468B anda data type of GDT: BusinessTransactionBlockedIndicator 40470B. ThePricingIndicator 40472B has zero or one occurrences 40474B and a datatype of GDT: BusinessTransactionDocument PricingIndicator 40476B. ThePlannedBillingDate 40478B has zero or one occurrences 40480B and a datatype of GDT: Date 40482B. The ProposedInvoiceDate 40484B has zero or oneoccurrences 40486B and a data type of GDT: DateTime 40488B.

The Hierarchy Relationship 40490B has zero or one occurrences 40492B andincludes a ParentItemID 40494B and a TypeCode 40400C at the fifth level40410. The ParentItemID 40494B has one occurrence 40496B and a data typeof GDT: BusinessTransactionDocumentItemID 40498B. The TypeCode 40400Chas one occurrence 40402C and a data type of GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode 40403C.

The Item package 40400A includes a ProductInformation package 40404C, aPriceInformation package 40406C, a Party package 40408C, a Locationpackage 40410C, a DeliveryInformation package 40412C, aPaymentInformation package 40414C, aBusinessTransactionDocumentReference package 40416C, anAccountAssignement package 40418C, an Attachment package 40420C, and aDescription package 40422C.

The ProductInformation package 40404C includes a Product entity 40424C,a ProductCategory entity 40430C, a DeliveryDateTimePeriod entity 40436C,and a Quantity entity 40442C at the fourth level 40408. The Productentity 40424C has zero or one occurrences 40426C and a data type of GDT:BusinessTransactionDocument Product 40428C. The ProductCategory entity40430C has zero or one occurrences 40432C and a data type of GDT:ProductCategory 40434C. The DeliveryDateTimePeriod entity 40436C haszero or one occurrences 40438C and a data type of GDT: DateTimePeriod40440C. The Quantity entity 40442C has one occurrence 40444C and a datatype of GDT: Quantity 40446C.

The PriceInformation package 40406C includes a Price entity 40448C and aProcurementCostUpperLimt 40488C at the fourth level 40408. The Priceentity 40448C has zero or one occurrences 40450C. TheProcurementCostUpperLimit 40488C has zero or one occurrences 40490C anda data type of GDT: ProcurementCostUpperLimit 40492C.

The Price entity 40448C includes a GrossAmount 40452C, a NetAmount40458C, a TaxAmount 40464C, a ExchangeRate 40470C, a PricingDate 40476C,and a NetUnitPrice 40482C at the fifth level 40410. The GrossAmount40452C has zero or one occurrences 40454C and a data type of GDT: Amount40456C. The NetAmount 40458C has zero or one occurrences 40460C and adata type of GDT: Amount 40462C. The TaxAmount 40464C has zero or oneoccurrences 40466C and a data type of GDT: Amount 40468C. TheExchangeRate 40470C has zero or one occurrences 40472C and a data typeof GDT: ExchangeRate 40474C. The PricingDate 40476C has zero or oneoccurrences 40478C and a data type of GDT: DateTime 40480C. TheNetUnitPrice 40482C has zero or one occurrences 40484C and a data typeof GDT: Price 40486C.

The Party package 40408C includes a BuyerParty entity 40494C, aSellerParty entity 40400D, a ProductRecipientParty entity 40406D, aVendorParty entity 40412D, a BillToParty entity 40418D, a BillFromPartyentity 40424D, a PayerParty entity 40430D, and a PayeeParty entity40436D at the fourth level 40408. The BuyerParty entity 40494C has zeroor one occurrences 40496C and a data type of GDT:BusinessTransactionDocumentParty 40498C. The SellerParty entity 40400Dhas zero or one occurrences 40402D and a data type of GDT:BusinessTransactionDocumentParty 40404D. The ProductRecipientPartyentity 40406D has zero or one occurrences 40408D and a data type of GDT:BusinessTransactionDocumentParty 40410D. The VendorParty entity 40412Dhas zero or one occurrences 40414D and a data type of GDT:BusinessTransactionDocumentParty 40416D. The BillToParty entity 40418Dhas zero or one occurrences 40420D and a data type of GDT:BusinessTransactionDocumentParty 40422D. The BillFromParty entity 40424Dhas zero or one occurrences 40426D and a data type of GDT:BusinessTransactionDocumentParty 40428D. The PayerParty entity 40430Dhas zero or one occurrences 40432D and a data type of GDT:BusinessTransactionDocumentParty 40434D. The PayeeParty entity 40436Dhas zero or one occurrences 40438D and a data type of GDT:BusinessTransactionDocumentParty 40440D.

The Location package 40410C includes a ShipToLocation entity 40442D anda ShipFromLocation entity 40448D at the fourth level 40408. TheShipToLocation entity 40442D has zero or one occurrences 40444D and adata type of GDT: BusinessTransactionDocumentLocation 40446D. TheShipFromLocation entity 40448D has zero or one occurrence 40450D and adata type of GDT: BusinessTransactionDocument Location 40452D.

The DeliveryInformation package 40412C includes a DeliveryTerms entity40454D at the fourth level 40408, which has zero or one occurrences40456D and a data type of GDT: DeliveryTerms 40458D.

The PaymentInformation package 40414C includes a CashDiscountTernsentity 40460D and a PaymentForm entity 40466D at the fourth level 40408.The CashDiscountTerms entity 40460D has zero or one occurrences 40462Dand a data type of GDT: CashDiscountTerms 40464D. The PaymentForm entity40466D has zero or one occurrences 40468D and a data type of GDT:PaymentFormCode 40470D.

The BusinessTransactionDocumentReference package 40416C includes aPurchaseOrder Reference entity 40472D, a SalesOrderReference entity40478D, a DeliveryReference entity 40484D, a PurchaseContract Referenceentity 40490D, a SalesContract Reference entity 40496D, a BuyerProductCatalogueReference entity 40402E, and a SellerProduct CatalogueReferenceentity 40408E. The PurchaseOrder Reference entity 40472D has zero or oneoccurrences 40474D and a data type of GDT:BusinessTransactionDocumentReference 40476D. The SalesOrderReferenceentity 40478D has zero or one occurrences 40480D and a data type of GDT:BusinessTransactionDocumentReference 40482D. The DeliveryReferenceentity 40484D has zero or one occurrences 40486D and a data type of GDT:BusinessTransactionDocumentReference 40488D. ThePurchaseContractReference entity 40490D has zero or one occurrences40492D and a data type of GDT: BusinessTransactionDocumentReference40494D. The SalesContractReference entity 40496D has zero or oneoccurrences 40498D and a data type of GDT:BusinessTransactionDocumentReference 40400E. TheBuyerProductCatalogueReference entity 40402E has zero or one occurrences40404E and a data type of GDT: CatalogueReference 40406E. TheSellerProductCatalogueReference entity 40408E has zero or oneoccurrences 40410E and a data type of GDT: CatalogueReference 40412E.

The AccountAssignment package 40418C includes an AccountAssigmnententity 40414E at the fourth level 40408, which has zero or oneoccurrences 40416E and a data type of GDT:AccountingObjectSetDistribution 40418E.

The Attachment package 40420C includes an AttachmentWebAddress entity40420E at the fourth level 40408, which has any number or occurrences40422E and a data type of GDT: AttachmentWebAddress 40424E.

The Description package 40422C includes a Description entity 40426E atthe fourth level 40408, which has zero or one occurrences 40428E and adata type of GDT: Description 40430E.

o) Inventory Change Interfaces

Inventory change interfaces are interfaces that may be used to transferinformation about stock changes in stockholding to interestedapplications, such as Logistics Planning (SCP) or Accounting. In avariation, the inventory change interfaces include theInventoryChangeNotification interface and theInventoryChangeAccountingNotification interface.

The motivating business scenarios for the InventoryChangeNotificationand InventoryChangeAccountingNotification interfaces may be the SellFrom Stock (SFS), Procure To Stock (PTS), and Physical Inventoryscenarios. Goods are received in the PTS scenario and issued in the SFSscenario. In the Physical Inventory scenario, inventory differences canresult in stock changes. All three scenarios can generally be groupedtogether as stock changes (InventoryChange). Information about stockchanges is relevant to Accounting, as well as to other applications,such as Logistics Planning. Therefore, theInventoryChangeAccountingNotification message can be transferred toAccounting. To inform interested applications such as Planning, theInventoryChangeNotification message can be sent. In a variation, thecontent of the messages is prepared in Inventory Management (SCE) basedon a set of rules tailored to the receiving service. For instance, inthe case of stock transfers within the warehouse or changes in the stockof non-valuated material, the information may be sent to Planning butnot to Accounting. The information may be sent at different times,depending on the receiving service. In an example, the information maybe sent promptly to Planning, whereas Accounting is informed after adelay (such as once a month). In addition, the extent to whichinformation is summarized in this scenario depends on the receivingservice. If an order involves partial deliveries, Planning is informedof every single stock change resulting from each partial delivery. Incontrast, Accounting is informed later of the total quantity delivered.Consequently, individual items of n InventoryChangeNotification messagessent at different times correspond to one item in anInventoryChangeAccountingNotification message. In a variation, SAPBusiness Information Warehouse (BW) could also be integrated later usinganother InventoryChange message (this message would be based on the samemessage data type, InventoryChangeMessage, as the messages describedhere). In this case, the information about stock changes may besummarized (for example, the sum of the goods issued for a material in aparticular plant on a certain day).

(1) Message Types

(a) Inventory Change Notification

An InventoryChangeNotification summarizes detailed information aboutstock changes in stockholding that may be required for LogisticsPlanning. The message type InventoryChangeNotification is based on themessage data type InventoryChangeMessage.

(b) Inventory Change Accounting Notification

An InventoryChangeAccountingNotification summarizes aggregatedinformation about stock changes in stockholding that may be required forAccounting. The message type InventoryChangeAccountingNotification isbased on the message data type InventoryChangeMessage.

(2) Message Choreography

FIG. 405 depicts a graphical representation 40500 of anInventoryChangeNotification 40508 and anInventoryChangeAccountingNotification 40510 between business entities inaccordance with methods and systems consistent with the subject matterdescribed herein. The illustrative message choreography is a logicalsequence of messages that is not dependent on actual scenarios. In theimplementation shown in FIG. 405, the illustrative business entitiesinclude a stockholder (or Inventory Management 40502), a logisticsplanner (or Logistics Planning 40504), and an accountant (or Accounting40506). In the illustrative example, Inventory Management 40502 informsinterested applications, such as Logistics Planning 40504 (usingInventoryChangeNotification 40508 message) or Accounting 40506 (usingInventoryChangeAccountingNotification 40510), about stock changes. Thisinformation can also be cancelled by reference, in which InventoryManagement 40502 sends anInventoryChangeAccountingCancellationNotification 40512 message toAccounting 40506. The reference to the original document (prima nota)can also be used in Accounting as an audit trail.

(3) Message Data Type Inventory Change Message

The message data type InventoryChangeMessage 40600 includes theInventoryChangeMessage object 40606 included in the business documentand the business information that is relevant for sending a businessdocument in a message. It includes a MessageHeader Package 40602 and anInventoryChange Package 40604. The message data typeInventoryChangeMessage 40600 makes the structure available for themessage type InventoryChange 40606 and the relevant interfacesInventoryChangeNotification 40508, InventoryChangeAccountingNotification40510, and InventoryChangeAccountingCancellationRequest 40512.

(a) Message Header Package

A MessageHeader package 40602 groups together the business informationthat is relevant for sending a business document in a message. In oneimplementation, the MessageHeader package 40602 may not be relevant forimplementing the InventoryChangeNotification 40508,InventoryChangeAccountingNotification 40510, orInventoryChangeAccountingCancellationRequest 40512.

(b) Inventory Change Package

The InventoryChange package 40604 summarizes changes in warehouse stock.It includes an InventoryChangeItem package 40608 and an InventoryChangeentity 40610. There is a 1:1 relationship 40612 between theInventoryChangeMessage object 40606 and the InventoryChange entity40610.

(i) Inventory Change

The InventoryChange entity 40610 summarizes changes in warehouse stock.An InventoryChange 40610 consists of individual changes in warehousestock which Accounting or Logistics Planning is informed of. The stockchanges summarized in a message may be of the same transaction type(goods receipt, goods issue, physical stock, transfer posting, and thelike).

InventoryChange 40610 includes an ID and a BusinessTransactionTypeCode.The ID is a unique identifier of InventoryChange 40610, and is of typeGDT: BusinessTransactionDocumentID. The BusinessTransactionTypeCode isthe type of business transaction that caused the stock change, and is oftype GDT: BusinessTransactionTypeCode.

In stockholding, the term “stock” refers to a certain quantity of amaterial kept in a particular location. Usually, other attributes areused to define the stock more precisely. The stock posted can differfrom the physical warehouse stock but this can be corrected by physicalinventories.

In a variation, a distinction can be made between external stock changes(goods receipt and issue) and internal stock changes (physical stock,stock transfer, and transfer posting). Stock changes are characterizedby the difference between the (internal) stock prior to the change andthe (internal) stock after the change. From the (internal) perspectiveof stockholding, each stock change involves an issue (outbound) or areceipt (inbound). In the case of goods receipt, a receipt is specified,whereas goods issue specifies an issue. Internal stock changes involveboth an issue and a receipt. A stock change is transferred to LogisticsPlanning and Accounting as an item in an InventoryChangeNotification oran InventoryChangeAccountingNotification, respectively.

(ii) Inventory Change Item Package

The InventoryChangeItem package 40608 summarizes information about anindividual warehouse stock change. It includes an InventoryChangeItementity 40620, an InventoryChangeItemOutbound package 40614, anInventoryChangeItemlnbound package 40616, and anInventoryChangeItemBusinessTransactionDocumentReference package 40618.In a variation, the InventoryChangeItem package 40608 may also includean InventoryChangeItemAccountingAssignment, which includes accountassignment information for an individual warehouse stock change, such asthe cost center.

InventoryChangeItem entity 40620 is an individual warehouse stockchange. There is a 1:n 40622 relationship between InventoryChange entity40610 and InventoryChangeItem entity 40620. An InventoryChangeItementity 40620 includes an ID, a DateTime, and a Note. The ID is the itemnumber, and is of type GDT: BusinessTransactionDocumentItemID. TheDateTime is the date and time of the stock change, and is of type GDT:DateTime. The Note is a note about the stock change, and is of type GDT:Note.

(iii) Inventory Change Item Outbound Package

The InventoryChangeItemOutbound package 40614 summarizes informationabout an issue of warehouse stock. It includes anInventoryChangeItemOutbound entity 40624, a Location 40626, a Product40628, and an OwnerParty 40630. There is a 1:c 40632 relationshipbetween InventoryChangeItem 40620 and InventoryChangeItemOutbound entity40624. There is a 1:n 40634 between InventoryChangeItemOutbound 40624and Location 40626. There is a 1:1 40636 relationship betweenInventoryChangeItemOutbound 40624 and Product 40628. There is a 1:1relationship 40638 between InventoryChangeItemOutbound 40624 andOwnerParty 40630.

(a) Inventory Change Item Outbound

An InventoryChangeItemOutbound 40624 characterizes an issue of warehousestock by means of the ship-from location, issuing owner, issuedquantity, and issued material. An InventoryChangeItemOutbound 40624includes an InventoryUsabilityStatusCode, a ValuationQuantity, anOrderingQuantity, and an AdditionalQuantity. TheInventoryUsabilityStatusCode is the usability of the stock for thecompany-specific business processes, and is of type GDT:InventoryUsabilityStatusCode. The ValuationQuantity is the quantity ofthe stock change expressed in the unit that Accounting uses to valuatestock, and is of type GDT: Quantity. The OrderingQuantity is thequantity of the stock change expressed in the unit of the purchase order(not to be confused with the ordered quantity), and is of type GDT:Quantity. The AdditionalQuantity is the quantity of the stock change inadditional units used to manage stock, and is of type GDT: Quantity.

For the message data type InventoryChangeMessage, in a variation, anissue of warehouse stock is specified when goods are issued and internalstock changes occur but not when goods are received. For the messagedata type InventoryChangeAccounting Notification, the elementAdditionalQuantity may be empty.

The stock of a material may be managed in several units of measure. Afixed conversion factor can exist between these units of measure (suchas “gallons” and “liters”). This can be material-specific (“kg” and“litre”) or general (material “pork halves” in the units of measure“piece” and “kg”). This information may be relevant for subsequentapplications in the business process chain, such as Planning. In avariation, the moved quantities expressed in the order unit and thevaluation unit of measure are relevant to Accounting. The units ofmeasure that are permitted and used to specify the quantities can beestablished on the basis of the combination of material and location ineach case. For instance, the material “crude oil” can be valuated in theunit of measure “litre” for the location “Hamburg” and in the unit ofmeasure “gallon” for the location “Dallas.” Transfer postings can bemade in which the InventoryUsability of the stock changes. In this case,the ship-from location, issue owner, issue quantity, and issue materialare the same as for the receiving location, receipt owner, receiptquantity, and receipt material, but the issue InventoryUsability maydiffer from the receipt InventoryUsability.

(b) Location

A Location 40626 is the outbound location of a warehouse stock change.Location 40626 is of type GDT: BusinessTransactionDocumentLocation forwhich InternalID is used.

In the context of the InventoryChangeAccountingMessage, the location isthe particular, valuation-relevant location of a stock change. In thecontext of the InventoryChangeMessage, the location may be the complete(hierarchical) specification of the location of a stock change.

Since stockholding generally uses a very fine-grained location structure(such as “storage bin 17-05-72”), this location is to be assigned to thevaluation-relevant location (such as “plant 072 in Hamburg”) prior tofilling the InventoryChangeAccountingNotification message, as thisinformation is of significance to Accounting. On the other hand, theentire location (such as “plant 072 in Hamburg,” “warehouse 42,”“storage bin 17-05-72”) may be specified in theInventoryChangeNotification message, since this is of relevance tosubsequent applications in the business process chain, such as Planning.

(c) Product

A Product 40628 is the issue material of a warehouse stock change.Product 40628 is of type GDT: BusinessTransactionDocumentProduct forwhich InternalID is used. In a variation, a material is a physicalobject which forms part of the business activity. In a variation, amaterial is traded, used during production, consumed, or produced. Inparticular, a material may be a product.

(d) Owner Party

An OwnerParty 40630 is the owner of the issue stock in a warehouse stockchange. OwnerParty is of type GDT: BusinessTransactionDocumentParty forwhich InternalID is used.

(iv) Inventory Change Item Inbound Package

The InventoryChangeItemInbound package 40616 summarizes informationabout a receipt of warehouse stock. It includes anInventoryChangeItemlnbound 40640, a Location 40642, a Product 40644, andan OwnerParty 40646. There is a 1:c 40648 relationship betweenInventoryChangeItem 40620 and InventoryChangeItemlnbound 40640. There isa 1:n 40650 relationship between InventoryChangeItemlnbound 40640 andLocation 40642. There is a 1:1 40652 relationship betweenInventoryChangeItemlnbound 40640 and Product 40644. There is a 1:1 40654relationship between InventoryChangeItemlnbound 40640 and OwnerParty40646.

(a) Inventory Change Item Inbound

An InventoryChangeItemInbound 40640 characterizes a receipt of warehousestock by means of the receiving location, receiving owner, receivedquantity, and received material. In the context of anInventoryChangeMessage, in a variation, a receipt of warehouse stock isspecified when goods are received and internal stock changes occur butnot when goods are issued. In the context of anInventoryChangeAccountingNotification, the element AdditionalQuantitymay be empty.

(b) Location

A Location 40642 is the inbound location of a warehouse stock change.Location 40642 is of type GDT: BusinessTransactionDocumentLocation forwhich InternalID is used.

(c) Product

A Product 40644 is the receipt material of a warehouse stock change.Product 40644 is of type GDT: BusinessTransactionDocumentProduct forwhich InternalID is used.

(d) Owner Party

An OwnerParty 40646 is the owner of the receipt stock in a warehousestock change. OwnerParty 40646 is of type GDT:BusinessTransactionDocumentParty for which InternalID is used.

(v) Inventory Change Item Business

Transaction Document Reference Package TheInventoryChangeItemBusinessTransactionDocumentReference package 40618summarizes the unique references to item lines in other documents, whichare relevant in the business process for warehouse stock changes. Itincludes a SalesOrderReference 40656 and a PurchaseOrderReference 40658.If other scenarios, such as physical inventory, are to be mapped,additional elements could be required in this package. There is a 1:crelationship 40660 between InventoryChangeItem 40620 andSalesOrderReference 40656. There is a 1:c relationship 40662 betweenInventoryChangeItem 40620 and PurchaseOrderReference 40658.

(a) Sales Order Reference

A SalesOrderReference 40656 is a reference to a sales order item thattriggered the change in warehouse stock. The SalesOrderReference 40656is of type GDT: BusinessTransactionDocumentReference. TheSalesOrderReference 40656 is filled in the case of a goods issue for asales order. Subsequent applications in the business process chain mayrequire this information to create the business context of the stockchange (such as for account determination in Accounting).

(b) Purchase Order Reference

A PurchaseOrderReference 40658 is a reference to a purchase order itemthat triggered the stock change. The PurchaseOrderReference 40658 is oftype GDT: BusinessTransactionDocumentReference. ThePurchaseOrderReference 40658 is filled in the case of a goods receiptfor a purchase order. Subsequent applications in the business processchain may require this information to create the business context of thestock change (such as for account determination in Accounting).

(4) Message Data Type Element Structure

FIGS. 407A-D depict the element structure for the Inventory Change, suchas the InventoryChangeNotification andInventoryChangeAccountingNotification. The element structure is similarto the above described data model of the Inventory Change as reflectedin FIG. 406, but provides additional information regarding the detailsfor interfacing with or implementing an Inventory Change. As shown inFIGS. 407A-D, the element structure identifies the different packages40700 that may be in a respective Inventory Change. The elementstructure for the Inventory Change includes six levels 40702, 40704,40706, 40708, 40710, and 40712 associated with a respective package40700. The element structure for an Inventory Change also identifies thecardinality 40714 and data type 40716 for the elements at respectivelevels 40702, 40704, 40706, 40708, 40710, and 40712 in a package 40700.

The outermost package of this interface is an InventoryChangeMessagepackage 40718, which includes an InventoryChangeMessage entity 40720 atthe first level 40702. The InventoryChangeMessage entity 40720 is ofmessage data type InventoryChangeMessage 40722.

The InventoryChangeMessage package 40718 includes an InventoryChangepackage 40724 that has an InventoryChange entity 40726. There is one40728 InventoryChange entity 40726, which is of global data type(“GDT”): InventoryChange. As shown in FIG. 407A, each InventoryChangeentity 40726 includes an ID 40732 and a BusinessTransactionTypeCode40738. The ID 40732 is of type GDT: BusinessTransactionDocumentID 40736.The BusinessTransactionTypeCode 40738 is of type GDT:BusinessTransactionTypeCode 40742. For each InventoryChange entity40726, there is one 40734 ID 40726 and one 40740BusinessTransactionTypecode 40738.

The InventoryChange package 40724 also includes an Item package 40744.Item package 40744 includes an Item entity 40746 of type GDT:InventoryChangeItem 40750. There is one or more 40748 Item entity 40746.Each Item entity 40746 includes an ID 40752, a DateTime 40758, and aNote 40764. The ID 40752 is of type GDT:BusinessTransactionDocumentItemID 40756. The DateTime 40758 is of typeGDT: DateTime 40762. The Note 40764 is of type GDT: Note 40768. For eachItem entity 40746, there is one 40754 ID 40752, one 40760 DateTime40758, and zero or one 40766 Note 40764.

The Item package 40744 also includes an Outbound package 40770, anInbound package 40774, and a BusinessTransactionDocumentReferencepackage 40776.

Outbound package 40770 includes an Outbound entity 40776 of type GDT:InventoryChangeItemOutbound 40780. There is zero or one Outbound entity40776 for each InventoryChangeItem entity 40746. Outbound entity 40776includes one or more 40784 Location entity 40782 of data type GDT:BTDLocation 40786. Location entity 40782 includes one 40790 InternalIDentity 40788 of data type GDT: LocationInternalID 40792. Outbound entityalso includes one 40796 Product entity 40794 of data type GDT:BTDProduct 40798. Product entity 40794 includes one 40702A InternalID40700A of data type GDT: ProductInternalID 40704A. Outbound entity 40776also includes one 40708A OwnerParty entity 40706A of data type GDT:BTDParty 40710A. OwnerParty entity 40706A includes one 40714A InternalIDentity 40712A of data type GDT: PartyInternalID 40716A.

Outbound entity 40776 also includes an InventoryUsabilityStatusCodeentity 40718A of data type GDT: InventoryUsabilityStatusCode 40722A, anOrderingQuantity entity 40724A of data type GDT: Quantity 40728A, aValuationQuantity entity 40730A of data type GDT: Quantity 40734A, andan AdditionalQuantity 40736A of data type GDT: Quantity 40740A. For eachOutbound entity 40776, there is one 40720A InventoryUsabilityStatusCode40718A, zero or one 40726A OrderingQuantity 40724A, zero or one 40732AValuationQuantity 40730A, and zero or more 40738A AdditionalQuantity40736A.

Inbound package 40774 includes an Inbound entity 40742A of type GDT:InventoryChangeItemlnbound 40746A. There is zero or one Inbound entity40742A for each InventoryChangeItem entity 40746. Inbound entity 40742Aincludes one or more 40750A Location entity 40748A of data type GDT:BTDLocation 40752A. Location entity 40748A includes one 40756AInternalID entity 40754A of data type GDT: LocationInternalID 40758A.Inbound entity 40742A also includes one 40762A Product entity 40760A ofdata type GDT: BTDProduct 40764A. Product entity 40760A includes one40768A InternalID 40766A of data type GDT: ProductInternalID 40770A.Inbound entity 40742A also includes one 40774A OwnerParty entity 40772Aof data type GDT: BTDParty 40776A. OwnerParty entity 40772A includes one40780A InternalID entity 40778A of data type GDT: PartyInternalID40782A.

Inbound entity 40742A also includes an InventoryUsabilityStatusCodeentity 40784A of data type GDT: InventoryUsabilityStatusCode 40788A, anOrderingQuantity entity 40790A of data type GDT: Quantity 40794A, aValuationQuantity entity 40796A of data type GDT: Quantity 40700B, andan AdditionalQuantity 40702B of data type GDT: Quantity 40706B. For eachInbound 40742A, there is one 40786A InventoryUsabilityStatusCode 40784A,zero or one 40792A OrderingQuantity 40790A, zero or one 40798AValuationQuantity 40796A, and zero or more 40704B AdditionalQuantity40702B.

BusinessTransactionDocumentReference 40776 includes aSalesOrderReference entity 40708B of type GDT:BusinessTransactionDocumentReference 40712B and a PurchaseOrderReferenceentity 40714B of type GDT: BusinessTransactionDocumentReference 40718B.For each InventoryChangeItem 40746, there is zero or one 407 1OBSalesOrderReference 40708B and zero or one 40716B PurchaseOrderReference40714B.

p) Sales Order Fulfillment Interfaces

SalesOrderFulfillment interfaces allow sales orders and availabilityconfirmations to be exchanged in a sales order fulfillment between aselling component or business entity and a procurement planningcomponent or business entity (e.g., fulfillment coordination, supplychain execution, logistics, availability check, requirements planning,scheduling, procurement, and other business entities). As discussed indetail below, the SalesOrderFulfillment interfaces reflect thelogistical part of the PurchaseOrder messages that are sent from thecustomer (Buyer) to the selling component (Seller).

In the ‘Sell from Stock’ scenario, goods and service orders are acceptedby customers and create a request to logistics to fulfill the order. Inthis scenario, the order is fulfilled in that the ordered goods areprocured to the customer from a warehouse. An availability check andscheduling (synchronously or asynchronously) is typically not plannedfor in the first step. Third-party order processing is not investigatedin detail. It is assumed that there will be typically one procurementplanning component (fulfillment coordination) that communicates with aselling component. If there are several procurement planning components,one of them is responsible for the communication with the sellingcomponents. There may be any number of selling components.

(1) Message Types

(a) Sales Order Fulfillment Request

A SalesOrderFulfillmentRequest message is a request (or change andcancellation of such a request) from a selling component to aprocurement planning component to fulfill a sales order and, in doingso, to take into account the logistical requirements (availabilitycheck, scheduling, requirements planning, procurement, delivery, . . . )of a sales order. The structure of the message typeSalesOrderFulfillmentRequest is specified by the message data typeSalesOrderFulfillmentMessage in FIG. 409.

(b) Sales Order Fulfillment Confirmation

A SalesQrderFulfillmentConfirmafion message is the confirmation, thepartial confirmation, or the changing of the procurement planningcomponent to the selling component with regards to the fulfillment of asales order. The structure of the message typeSalesOrderFulfillmentConfirmation is specified by the message data typeSalesOrderFulfillmentMessage in FIG. 409.

The SalesOrderFulfillmentConfirmation message can be used by theprocurement planning component in the following ways:

(1) The procurement planning component may inform the selling componentof the confirmation status of the SalesOrderFulfillment. Theconfirmation status values may be ‘accepted,’ ‘pending,’ or ‘rejected.’The confirmation status may be set at the header or item level of theSalesQrderFulfillmentConfirmation message as discussed in further detailbelow. In one implementation, a rejection at the header level equates toa rejection of all items. Acceptance at header level means acceptance ofthe SalesOrderFulfillment. Individual items may be accepted, opened, orrejected.

(2) The procurement planning component may explicitly confirm plannedprocurement schedules, quantities and other procurement elements to theselling component, and suggest substitute products.

The selling component may explicitly request aSalesOrderFulfillmentConfirmation by setting theFollowUpSalesOrderFulfillmentConfirmation/RequirementCode to ‘expected.’In this implementation, the procurement planning component may send aSalesOrderFulfillmentConfirmation:

(1) as a response when a SalesOrderFulfillmentRequest message isreceived. In order to send the response as promptly as possible, no userinteraction should be required with the procurement planning component.If it is not possible to accept or reject a request for the sellingcomponent automatically, the confirmation status ‘pending’ may be used.

(2) when the confirmation status of the SalesOrderFulfillment as a wholeor of an item changes.

(3) when quantities or deadlines can be explicitly confirmed, or whenchanges to confirmations that have already been transferred occur.

A SalesOrderFulfillmentConfirmation may be sent by the procurementplanning component when the procurement planning component rejectsindividual items or the SalesOrderFulfillment as a whole and when theprocurement planning component requires changes to the sales order.

(2) Message Choreography

The interaction that takes place between the SalesOrderFulfillmentinterfaces is described in detail in the following section.

SalesOrderFulfillmentRequest and SalesOrderFulfillmentConfirmation arethe messages that are used to represent a SalesOrderFulfillment process.

Furthermore, the selling component is interested in the actualconfirmations from the procuring component: e.g., delivery created,reserved goods issued, goods packed and goods issue posted,DeliveryInfo.

(a) Process Flow

As depicted in FIG. 408, the message choreography may involve thefollowing business entities or components: a Purchasing component 40802,a Sales component 40804, a Fulfillment coordination component 40806, aSupplyChain Planning component 40808, and a SupplyChain Executioncomponent 40810. To start the process, the Sales component 40804receives a PurchaseOrderRequest message 40812 from the Purchasingcomponent 40802. In response, the Sales component 40804 starts afulfillment process for a sales order by sending aSalesOrderFulfillmentRequest message 40814 to the FulfillmentCoordination component 40806, which in turn sends theSalesOrderFulfillmentRequest message 40814 to the SupplyChain Planningcomponent 40816. Supply Chain Planning 40816 may respond to FulFillmentCoordination 40806 with a SalesOrderFulfillmentConfirmation 40818.

After the process has started, the Sales component 40804, whetherinternally or triggered by the customer, is operatively configured tocommunicate requests for changes via a SalesOrderFulfillmentRequestmessage (e.g., that has an action code set to ‘Change’) to FulfillmentCoordination 40806. The Sales component 40804 is also operativelyconfigured to communicate a request to delete or reject the sales order(e.g., action code set to ‘Delete’). After theSalesOrderFulfillmentRequest message has been received, the procurementplanning component (Fullfillment Coordination 40806) may inform theselling component (Sales component 40804) about the status of the salesorder with regard to the confirmed quantities and dates via aSalesOrderFulfillmentConfirmation message 40820. Upon receiving this,the Sales component 40804 may send a PurchaseOrderConfirmation 40822 tothe Purchasing component 40802.

(b) Serialization of Messages

The messages within a SalesOrderFulfillment process are transferred EOIO(exactly once in order) and serialized using message queues. In oneimplementation, there is one message queue per SalesOrderFulfillmentprocess (as opposed to one queue for all SalesOrderFulfillment messages)so that if one message fails, not all other SalesOrderFulfillmentmessages are blocked throughout the entire system.

(c) Error Handling

A target system (e.g., the Fulfillment Coordination component) isoperatively configured to accept each formally correct incomingSalesOrderFulfillment message. Business problems are solved via aSalesOrderFulfillmentRequest (change, reject) message on the sellingside and via a SalesOrderFulfillmentConfirmation message on theprocurement planning side. In order to avoid endless message loops, aselling system may not be allowed to reject aSalesOrderFulfillmentConfirmation automatically via aSalesOrderFulfillmentRequest, or it has to present other mechanisms toavoid endless loops (for example, maximum one consecutive rejectionpermitted). To restart a SalesOrderFulfillment process that is corruptdue to a failed message, the selling system should offer the possibilityof transferring the current state of the SalesOrderFulfillment with aSalesOrderFulfillmentRequest message. The action codes ‘Save’ and‘Remove’ can be used in this message. The procurement planning systemshould offer the same functionality for theSalesOrderFulfillmentConfirmation. In order to be able to restart aprocess after a failed SalesOrderFulfillmentRequest message (create),the selling system should be in a position to start aSalesOrderFulfillment process with a SalesOrderFulfillmentRequestmessage (change).

(3) Message Data Type Sales Order Fulfillment Message

The data model for the message data type SalesOrderFulfillmentMessageused to implement a SalesOrderFulfillmentRequest message, aSalesOrderFulfillmentConfirmation message, and relevant interfaces isdepicted in FIGS. 409A-L. The message data typeSalesOrderFulfillmentMessage includes the object SalesOrderFulfillmentincluded in the business document and the business information that isrelevant for sending a business document in a message. As shown in FIG.409A, the SalesOrderFulfillmentMessage 40900 includes a MessageHeaderpackage 40902, a SalesOrderFulfillment package 40904, and aSalesOrderFulfillmentMessage object or entity 40906.

(a) Message Header Package

The MessageHeader package 40902 groups the business information that isrelevant for sending a business document in a message. The MessageHeaderpackage 40902 includes a MessageHeader entity 40908. There is a 1:1relationship 40910 between the SalesOrderFulfillmentMessage entity 40906and the MessageHeader entity 40908. The MessageHeader package 40902 alsoincludes a SenderParty entity 40912 and a RecipientParty entity 40914.The MessageHeader entity 40908 has a 1:c relationship 40916 with theSenderParty entity 40912 and a 1:cn relationship 40918 with theRecipientParty entity 40914.

(i) Message Header

The MessageHeader entity 40908 groups the business information for thesending application for identifying the business document in a message,information about the sender, and potential information about therecipient. The MessageHeader entity 40908 is of type GDT:BusinessDocumentMessageHeader.

(ii) Sender Party

The SenderParty entity 40912 is responsible for sending a businessdocument at business application level. The SenderParty entity 40912 isof type GDT: BusinessDocumentMessageHeaderParty.

(iii)Recipient Party

The RecipientParty 40914 is responsible for receiving a businessdocument at business application level. The RecipientParty 40914 is oftype GDT: BusinessDocumentMessageHeaderParty.

(b) Sales Order Fulfillment Package

The SalesOrderFulfillment package 40904 groups the SalesOrderFulfillmentwith a Party Package 40924, a Location Package 40926, aDeliveryInformation Package 40928, an Attachment Package 40930, aDescription Package 40932, a FollowUpBusinessTransactionDocument Package40934, an Item Package 40936, and a SalesOrderFulfillment entity 40938(FIG. 409B). There is a 1:1 relationship 40940 between theSalesOrderFulfillmentMessage entity 40906 and the SalesOrderFulfillmententity 40938.

(i) Sales Order Fulfillment

A SalesOrderFulfillmentRequest is a request (or change and cancellationof such a request) to fulfill a sales order and, in doing so, to takeinto account the logistical requirements (availability check,scheduling, requirements planning, procurement, delivery, . . . .) of asales order. The SalesOrderFulfillment entity 40938 (FIG. 409B) isdivided into SalesOrderFulfillmentItems 40932B (FIG. 409H) that eachspecify the product that is still to be fulfilled or additionalinformation for such a product such as BOM information (seePurchaseOrderItem Package). The SalesOrderFulfillment entity 40938 has a1:cn relationship 40934B with the Item entity 40932B. Alongside thepurchasing party and the seller, other parties can be involved in theSalesOrderFulfillment (see Party Package 40924). For the fulfillment ofthe SalesOrderFulfillment, locations can be determined (see LocationPackage 40926), and delivery methods can be agreed upon (seeDeliveryInformation Package 40928). Notes or references to attachmentscan be added to the SalesOrderFulfillment (see Description Package 40932or Attachment Package 40930). Furthermore, it is possible to specifywhich types of follow-up documents are expected with regard to theSalesOrderFulfillment (see FollowUpBusinessTransactionDocument Package40934). The SalesOrderFulfillment entity 40938 is of type GDT:SalesOrderFulfillment.

The SalesOrderFulfillment entity 40938 includes an ID, aBaseBusinessTransactionDocumentID, aBaseBusinessTransactionDocumentTypeCode, an ActionCode, anItemListCompleteTransmissionIndicator, a CreationDateTime, aLastChangeDateTime, and an AcceptanceStatusCode. The ID is a uniqueidentification issued by the seller for a SalesOrderFulfillment. The IDis of type GDT: BusinessTransactionDocumentID. TheBaseBusinessTransactionDocumentID is a unique identifier of the businessdocument underlying the SalesOrderFulfillment. TheBaseBusinessTransactionDocumentID is of type GDT:BusinessTransactionDocumentID. TheBaseBusinessTransactionDocumentTypeCode is the coded representation ofthe type of the business document underlying the SalesOrderFulfillment.The BaseBusinessTransactionDocumentTypeCode is of type GDT:BusinessTransactionDocumentTypeCode. The ActionCode is the request tonewly create, change, or delete the SalesOrderFulfillment at therecipient of the SalesOrderFulfillment. The ActionCode is of type GDTActionCode. The ItemListCompleteTransmissionIndicator specifies whetherall items of the requesting document are always transferred andnon-transferred items implicitly count as rejected, or whether new andchanged items as well as items that have been rejected since the lasttransfer are transferred. The ItemListCompleteTransmissionIndicator isof type GDT CompleteTransmissionIndicator. The CreationDateTime is thecreation date of the requesting document. CreationDateTime is of typeGDT Date Time. The LastChangeDateTime is the change date of therequesting document. The LastChangeDateTime is of type GDT Date Time.The AcceptanceStatusCode is the coded representation of the status ofthe agreement of the procurement planning unit. The AcceptanceStatusCodeis of type GDT: AcceptanceStatusCode.

ActionCode/CompleteTransmissionIndicator: in aSalesOrderFulfillmentRequest, items and schedule lines may betransferred with complete dates at the object level, that is to say,when an item or a schedule line is transferred, all dates of that itemor schedule line specified on the interface may be transferred too. Inthe SalesOrderFulfillmentRequest, the ActionCode may be used at a headerand an item level to display whether the SalesOrderFulfillmentRequest orindividual items are to be created, changed or deleted or rejected (forexample, individual schedule lines). A SalesOrderFulfillmentRequest maybe configured to control whether all items are transferred or thoseitems that have been explicitly changed via theCompleteTransmissionIndicator. One convention is that if theCompleteTransmissionIndicator is set, the ActionCode is by definitionset to ‘Create.’ In this case, items that have not been transferred areimplicitly deleted.

The AcceptanceStatusCode may be used in theSalesOrderFulfillmentConfirmation message at header and item level todescribe the status of the agreement of the procurement planningcomponent with regard to the SalesOrderFulfillment or individual items.

(ii) Sales Order Fulfillment Party Package

The Party package 40924 (FIG. 409B) is a grouping of the businessparties involved in the SalesOrderFulfillment. The Party package 40924includes a BuyerParty entity 40942, a SellerParty entity 40944 (FIG.409C), a ProductRecipientParty entity 40946, a VendorParty entity 40948,a ManufacturerParty entity 40950, and a CarrierParty entity 40952. TheSalesOrderFulfillment entity 40938 has a respective 1:c relationship40954-64 with each of the BuyerParty entity 40942, the SellerPartyentity 40944, the ProductRecipientParty entity 40946, the VendorPartyentity 40948, the ManufacturerParty entity 40950, and the CarrierPartyentity 40952.

(a) Buyer Party

The BuyerParty is a party that buys goods or services. The BuyerPartyentity 40942 is of type GDT: BusinessTransactionDocumentParty. In oneimplementation, the BuyerParty entity 40942 uses an InternalID from theGDT: BusinessTransactionDocumentParty data type to identify theBuyerParty. In one implementation, the same BuyerParty applies to allitems in a SalesOrderFulfillment. In SAP CRM, the BuyerParty is alsoreferred to as the SoldToParty or the customer.

The BuyerParty entity 40942 has a 1:c relationship 40970 with an Addressentity 40966 and a 1:c relationship 40972 with a Contact entity 40968.The Address entity 40966 has a respective 1:c relationship 40984-92 witheach of a PersonName entity 40974, a Office entity 40976, aPhysicalAddress entity 40978, a GeoCoordinates entity 40980, and aCommunication entity 40982. Likewise, Contact entity 40968 has arespective 1:c relationship 40996 with an Address entity 40994, which inturn has a respective 1:c relationship 40908A-16A with each of aPersonName entity 40998, an Office entity 40900A, a Physical Addressentity 40902A, a GeoCoordinates entity 40904A, and a Communicationentity 40906A.

(b) Seller Party

A SellerParty is a party that sells goods or services. The SellerPartyentity 40944 is of type GDT: BusinessTransactionDocumentParty. In oneimplementation, the SellerParty entity 40944 uses an InternalID from theGDT: BusinessTransactionDocumentParty data type to identify theSellerParty. In one implementation, the same SellerParty applies to allitems in a SalesOrderFulfillment.

(c) Product Recipient Party

A ProductRecipientParty is a party to which goods are delivered orservices are provided. The ProductRecipientParty entity 40946 is of typeGDT: BusinessTransactionDocumentParty. In one implementation, theProductRecipientParty entity 40946 uses an InternalID from the GDT:BusinessTransactionDocumentParty data type to identify theProductRecipientParty. In one implementation, if a ShipToLocation is notexplicitly specified in a SalesOrderFulfillment process, the address ofthe ProductRecipientParty may be used as the ShipToLocation address.

(d) Vendor Party

A VendorParty is a party which delivers goods or provides services. TheVendorParty entity 40948 is of type GDT:BusinessTransactionDocumentParty. In one implementation, the VendorPartyentity 40948 uses an InternalID from the GDT:BusinessTransactionDocumentParty data type to identify the VendorParty.In one implementation, if a ShipFromLocation is not explicitly specifiedin a SalesOrderFulfillment process, the address of the VendorParty maybe used as the ShipFromLocation address. The VendorParty is not thecompany or the person that exclusively takes on the transport of goods.The CarrierParty is intended for this. The contact and the address ofthe VendorParty are used by the selling component as the contact personfor the procurement planning component.

(e) Manufacturer Party

A ManufacturerParty is a party that manufactures goods. TheManufacturerParty entity 40950 is of type GDT:BusinessTransactionDocumentParty. In one implementation, theManufacturerParty entity 40950 uses an InternalID from the GDT:BusinessTransactionDocumentParty data type to identify theManufacturerParty.

(f) Carrier Party

A CarrierParty is a party that transports goods. The CarrierParty entity40952 is of type GDT: BusinessTransactionDocumentParty. In oneimplementation, the CarrierParty entity 40952 uses an InternalID fromthe GDT: BusinessTransactionDocumentParty data type to identify theCarrierParty.

(iii) Sales Order Fulfillment Location Package

The location package 40926 groups all locations that are relevant forthe SalesOrderFulfillment. As shown in FIG. 409E, the location package40926 includes a ShipToLocation 40928A and a ShipFromLocation 40930A.The SalesOrderFulfillment entity 40938 has a respective 1:c relationship40932A or 40934A with each of the ShipToLocation 40928A and theShipFromLocation 40930A. Changes to locations may be changes to allitems to which this location applies. For each location, an ID or theaddress or both may be transferred.

(a) Ship To Location

A ShipToLocation is the place to which goods should be delivered orwhere a service should be rendered. The ShipToLocation entity 40928A isof type GDT: BusinessTransactionDocumentParty. In one implementation,the ShipToLocation entity 40928A uses an InternaliD from the GDT:BusinessTransactionDocumentParty data type to identify theShipToLocation. In CRM, ShipToLocation may be understood to mean theunloading point at the ProductRecipientParty. The ShipToLocation entity40928A has a 1:c relationship 40938A with an Address entity 40936A,which has a respective 1:c relationship 40950A-58A with each of aPersonName 40940A entity, a Office entity 40942A, a PhysicalAddressentity 40944A, a GeoCoordinates entity 40946A, and a Communicationentity 40948A.

(b) Ship From Location

A ShipFromLocation is the place from which goods should be delivered.The ShipFromLocation entity 40934A is of type GDT:BusinessTransactionDocumentLocation. In one implementation, theShipFromLocation entity 40934A uses an InternalID from the GDT:BusinessTransactionDocumentParty data type to identify theShipFromLocation. In CRM, ShipFromLocation may be understood to mean theplant of the VendorParty. As indicated by elipsis 40960A, theShipFromLocation entity 40930A is defined to include or have similarrelationships with the same elements as those described for theShipToLocation entity 40928A.

(iv) Sales Order Fulfillment Delivery Information Package

The DeliveryInformation package 40928 groups all information on arequired procurement in a SalesOrderFulfillment process. TheDeliveryInformation package 40928 includes a DeliveryTerms entity 40962Aand a DeliveryControl entity 40964A. The SalesOrderFulfillment entity40938 has a 1:c relationship 40966A with the DeliveryTerms entity 40962Aand a 1:c relationship 40968A with the DeliveryControl entity 40964A.

(a) Delivery Terms

DeliveryTerms are the conditions and agreements that are valid forexecuting the delivery and transporting the ordered goods and for thenecessary services and activities. The DeliveryTerms entity 40962A is oftype GDT: DeliveryTerms and has a respective 1:c relationship 40980A-88Awith each of an Incoterms entity 40970A, a Partial Delivery entity40972A, a QuantityTolerance entity 40974A, a Transport entity 40976A,and a Description entity 40978A.

(b) Delivery Control

DeliveryControl is the quantity of controlling parameters forprocurement in a SalesOrderFulfillment process. The DeliveryControlentity 40964A includes a DeliveryBlockedIndicator, which indicateswhether the sales order or the sales order item are blocked fordelivery. DeliveryBlockedIndicator is of type GDT:BusinessTransactionBlockedIndicator.

(v) Sales Order Fulfillment Attachment Package

The Attachment package 40930 groups attachment information withreference to the requesting order. The Attachment package 40930 includesan AttachmentWebAddress entity 40990A. The SalesOrderFulfillment entity40938 has a 1:cn relationship 40992A with the AttachmentWebAddressentity 40990A. AttachmentWebAddress entity 40990A is a reference to anattachment. The AttachmentWebAddress entity 40990A is of type GDT:WebAddress.

(vi) Sales Order Fulfillment Description Package

The Description package 40932 groups all texts to be described withreference to the SalesOrderFulfillment. The Description package 40932includes a Description entity 40994A and a ConfirmationDescriptionentity 40996A. The SalesOrderFulfillment entity 40938 has a 1:crelationship 40998A with the Description entity 40994A and a 1:crelationship 40900B with the ConfirmationDescription entity 40996A.

(a) Description

A Description is a text written in normal language that can be seen byparties with reference to the SalesOrderFulfillment. The Descriptionentity 40994A is of type GDT: Description. The Description entity 40994Amay be used for all types of textual information that relates to thetransferred SalesOrderFulfillment and not to the current message. Anexample would be a description of how the customer should be dealt withregarding the delivery.

(b) Confirmation Description

A ConfirmationDescription is a text written in normal language that canbe seen by parties with reference to theSalesOrderFulfillmentConfirmation. The ConfirmationDescription entity40996A is of type GDT: Description. The ConfirmationDescription entity40996A may be used for all types of textual information that relates tothe SalesOrderFulfillmentConfirmation. An example would be anexplanation as to why a SalesOrderFulfillment was rejected.

(vii) Sales Order Fulfillment Follow-Up Message Package

The FollowUpMessage package 40934 groups information about follow upmessages that the selling component expects from the procurementplanning component with regard to the SalesOrderFulfillment. TheFollowUpMessage package 40934 includes aFollowUpSalesOrderFulfillmentConfirmation entity 40902B, aFollowUpDespatchedDeliveryNotification entity 40904B, and aFollowUpBillingDueNotification entity 40906B. The SalesOrderFulfillmententity 40938 has a respective 1:c relationship 40908B-40912B with eachof the FollowUpSalesOrderFulfillmentConfirmation entity 40902B, theFollowUpDespatchedDeliveryNotification entity 40904B, and theFollowUpBillingDueNotification entity 40906B.

(a) Follow-Up Sales Order Fulfillment Confirmation

A FollowUpSalesOrderFulfillmentConfirmation is a notice which showswhether the selling component expects a confirmation of theSalesOrderFulfillment from the procurement planning component. TheFollowUpSalesOrderFulfillmentConfirmation entity 40902B includes aRequirementCode, which is a coded representation of the notice whichshows whether the selling component expects a confirmation from theprocurement planning component. The RequirementCode is of type GDT:FollowUpMessageCode. In one implementation, the RequirementCode of theFollowUpSalesOrderFulfillmentConfirmation entity 40902B has a value of‘expected’ or ‘unexpected.’ In one implementation, the RequirementCodeis set by the selling component.

(b) Follow-Up Despatched Delivery Notification

A FollowUpDespatchedDeliveryNotification is a notice that shows whetherand, if so, how the customer would like to be informed about a deliveryby the procurement planning component. TheFollowUpDespatchedDeliveryNotification is passed on to the procurementplanning component from the PurchaseOrderRequest. TheFollowUpDespatchedDelivery Notification entity 40904B includes aRequirementCode, which is a coded representation of the notice thatshows whether the purchaser expects a notification about the delivery ofordered goods from the vendor. The RequirementCode is of type GDT:FollowUpMessageCode.

In one implementation, the RequirementCode of theFollowUpDespatchedDelivery Notification entity 40904B has a value of‘expected’ or ‘unexpected.’ In one implementation, the RequirementCodeis set by the selling component.

(c) Follow-Up Billing Due Notification

A FollowUpBillingDueNotification is a notice that shows whether theselling component expects the procurement planning component to deliverlogistical information after posting the goods issue in the BillingEngine (delivery-related billing document, in which commercial data fromCRM and logistical data from the delivery are consolidated in thebilling unit in the billing due list). TheFollowUpBillingDueNotification entity 40906B includes a RequirementCode,which is a coded representation of the notice that shows whether theselling component expects the procurement planning component to deliverlogistical information after posting of the goods issue in the billingunit. The RequirementCode is of type GDT: FollowUpMessageCode.

In one implementation, the RequirementCode ofFollowUpBillingDueNotification entity 40906B entity 40904B has a valueof ‘expected’ or ‘unexpected.’ In one implementation, theRequirementCode is set by the selling component.

(viii) Sales Order Fulfillment Item Package

The SalesOrderFulfillmentItem package 40936 groups aSalesOrderFulfillmentItem entity 40932B with the packages within theSalesOrderFulfillmentItem package 40936. The SalesOrderFulfillmentItempackage 40936 includes a ProductInformation package 40914B, a Batchpackage 40916B, a Party package 40918B, a Location package 40920B, aDeliveryInformation package 40922B, aBusinessTransactionDocumentReference package 40924B, an Attachmentpackage 40926B, a Description package 40928B, and a ScheduleLine package40930B.

(a) Sales Order Fulfillment Item

The SaleOrderFulfillmentItem entity 40932B specifies a producttransferred by the SalesOrderFulfillment or additional information onsuch a product. The SalesOrderFulfillmentItem 40932B includes detailedinformation on a product (see ProductInformationPackage 40914B) and itsbatch (see Batch Package 40916B). The quantity of the product and the(delivery) date are specified in the schedule line (see ScheduleLinePackage 40930B). Deviating parties, locations and delivery methods maybe specified for the SalesOrderFulfillmentItem 40932B (compared to theinformation of the SalesOrderFulfillment) (see Party Package 40918B,Location Package 40920B, DeliveryInformation Package 40922B). TheSalesOrderFulfillmentItem may include references to other businessdocuments that are relevant for the item (seeBusinessTransactionDocumentReference Package 40924B). Furthermore, notesor references can be added as attachments (see Description Package40928B or Attachment Package 40926B). A SalesOrderFulfillmentItem can besubordinate to another SalesOrderFulfillmentItem within a hierarchy inorder to represent a business connection between the two items. Thishierarchical relationship is reflected by the ItemHierarchyRelationshipentity 40936B. This might, for example, be the addition of a free-goodsdiscount or a substitute product to an ordered product.

The SalesOrderFulfillmentItem entity 40932B is of type GDT:SalesOrderFulfillmentItem. The SalesOrderFulfillmentItem entity 40932Bincludes an ID, a TypeCode, an ActionCode, aScheduleLineListCompleteTransmissionIndicator, a CreationDateTime, aLastChangeDateTime, and an AcceptanceStatusCode. The ID is a uniqueidentification issued by the seller for the item of aSalesOrderFulfillment. The ID is of type GDT:BusinessTransactionDocumentItemID. The TypeCode is the document type ofthe requesting document. TypeCode is of type GDT:BusinessTransactionDocumentTypeCode. The ActionCode is the codedrepresentation of a message request to the recipient to create, change,delete, or reject business objects. The ActionCode is of type GDTActionCode. The ScheduleLineListCompleteTransmissionIndicator specifieswhether the schedule lines of the requesting document are alwaystransferred and non-transferred schedule lines implicitly count asrejected, or whether new and changed schedule lines as well as schedulelines that have been rejected since the last transfer are transferred.ScheduleLineListCompleteTransmissionIndicator is of type GDTCompleteTransmissionIndicator. The CreationDateTime is the creation timeof the item of the requesting document. CreationDateTime is of type GDTDateTime. The LastChangeDateTime is the change date of the item of therequesting document. LastChangeDateTime is of type GDT DateTime. TheAcceptanceStatusCode is the coded representation of the status of theagreement of the procurement planning unit. The AcceptanceStatusCode isof type GDT: AcceptanceStatusCode.

(b) Hierarchy Relationship

SalesOrderFulfillmentItem entities are arranged hierarchically using aHierarchy Relationship entity 40936B. The Item Hierarchy Relationship40936B is the relationship between a sub-item and a higher-level parentitem in an item hierarchy. There is a 1:cn relationship 40938B betweenthe SalesOrderFulfillmentItem entity 40932B and its subordinateentities, and there is a 1:c relationship 40940B between theSalesOrderFulfillmentItem entity 40932B and its superordinate entities.The HierarchyRelationship entity 40936B includes a ParentItemID and aTypeCode. The ParentItemID is the reference to the parent item. TheParentItemID is of type GDT: BusinessTransactionDocumentItemID. TheTypeCode is the kind of relationship between a subitem and itshierarchically higher-level parent item. The TypeCode is of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode.

(c) Sales Order Fulfillment Item Product Information Package

The ProductInformation Package 40914B groups the information foridentifying, describing, and classifying a product. TheProductInformation Package 40914B includes a Product entity 40942B and aProductCategory entity 40944B. The SalesOrderFulfillmentItem entity40932B has a respective 1:c relationship 40946B or 40948B with each ofthe Product entity 40942B and the ProductCategory entity 40944B.

(i) Product

A product includes the details about a product as generally understoodfrom a commercial point of view in business documents. These are thedetails for identifying a product, product type as well as thedescription of the product. The product entity 40942B is of type GDT:BusinessTransactionDocumentProduct. In one implementation, the productto be procured is not be changed by the selling component. Theprocurement planning component may add a product number to a productdescription without a product number or specify a product for a newlyproposed item.

(ii) Product Category

A ProductCategory includes the details about a product category asgenerally understood from a commercial point of view in businesstransaction documents. The ProductCategory includes details foridentifying the product category using an internal ID, a standard IDalong with IDs assigned by involved parties. The ProductCategory entity40944B is of type GDT: BusinessTransactionDocumentProductCategory.

(d) Sales Order Fulfillment Item Batch Package

The Batch package 40916B groups all batch information on the productspecified in a SalesOrderFulfillmentItem. The Batch package 40916Bincludes a Batch entity 40950B. The SalesOrderFulfillmentItem entity40932B has a 1:c relationship 40952B with the Batch entity 40950B. Thebatch entity 40950B is a non-reproducible, homogenous subset of aproduct. The subset's chracteristics lie within the batchcharacteristics defined for the product. The Batch entity 40950Bincludes a BatchID, which is of type GDT: BatchID. A batch entity 40950Bis either identified directly by its ID or described by itscharacteristics.

(e) Sales Order Fulfillment Item Party Package

The SalesOrderFulfillment Item Party package 40918B is defined similaryto Party package 40924. For example, SalesOrderFulfillment Item Partypackage 40918B includes a BuyerParty item 40954B, a SellerParty item40956B, a ProductRecipientParty item 40958B, a Vendor party entity40959B, a Manufacturer Party entity 40960B, and a CarrierParty item40962B. Each of these entities is defined similary to theircorresponding counterpart in the Party package 40924 as indicated byelipses 40974B-82B. The SalesOrderFulfillmentItem entity 40932B has arespective 1:c relationship 40964B-40972B with each of these entities40954B, 40956B, 40958B, 40959B, 40960B, and 40962B.

(f) Sales Order Fulfillment Item Location Package

The SalesOrderFulfillment Item Location Package 40920B contains theShipTo-Location entity 40984B and the ShipFrom-Location entity 40994B.Each of these entities 40984B and 40994B is defined similarly to theirlike-named counterpart in the Location Package 40926 as indicated byelipses 40992B and 40994B. The SalesOrderFulfillmentItem entity 40932Bhas a respective 1:c relationship 40988B, 40990B with each of theShipTo-Location entity 40984B and the ShipFrom-Location entity 40994B.

(g) Sales Order Fulfillment Item Delivery Information Package

The SalesOrderFulfillment Item DeliveryInformation package 22B includesthe DeliveryTerms entity 40996B and the DeliveryControl entity 40998B.The SalesOrderFulfillmentItem entity 40932B has a respective 1:crelationship 40900C, 40902C with each of the DeliveryTerms entity 40996Band the DeliveryControl entity 40998B. Each of DeliveryTerms entity40996B and the DeliveryControl entity 40998B is defined similarly totheir like-named counterpart in the DeliveryInformation package 40928.For example, the DeliveryTerms entity 40996B has a 1:c relationship40914C-40922C with an Incoterms entity 40914C, an PartialDelivery entity40906C, an QuantityTolerance entity 40908C, an Transport entity 40910C,and an Description entity 40912C. Each of these entities 40914C, 40906C,40908C, 40910C, and 40912C is defined similary to their like-namedcounterpart in the DeliveryInformation package 40928.

(h) Sales Order Fulfillment Item Business Transaction Document ReferencePackage

The BusinessTransactionDocumentReference package 40924B groups allreferences to business documents that can occur for theSalesOrderFulfillmentItem and have a business connection to the item.The BusinessTransactionDocumentReference package 40924B includes aQuoteReference entity 40924C, a SalesContractReference entity 40926C, aPurchaseOrderReference entity 40928C, and anOriginPurchaseOrderReference entity 40930C. TheSalesOrderFulfillmentItem entity 40932B has a 1:c relationship40932C-40938C with each of these entities 40924C, 40926C, 40928C, and40930C.

(i) Quote Reference

The QuoteReference is the reference to a quotation or an item within aquotation. The QuoteReference entity 40924C is of type GDT:BusinessTransactionDocumentReference.

(ii) Sales Contract Reference

The SalesContractReference is the reference to a sales contract or anitem within a sales contract. The SalesContractReference entity 40926Cis of type GDT: BusinessTransactionDocumentReference.

(iii) Purchase Order Reference

The PurchaseOrderReference is the reference to the PurchaseOrder or toan item within the PurchaseOrder. The PurchaseOrderReference entity40928C is of type GDT: BusinessTransactionDocumentReference. ThePurchaseOrderReference entity 40928C may make reference to the Buyer'sorder in the procurement planning component (for example, in theDespatchedDeliveryNotifcafion).

(iv) Origin Purchase Order Reference

The OriginPurchaseOrderReference is the reference to the origin purchaseorder or to an item within the origin purchase order in a third-partybusiness transaction. The OriginPurchaseOrderReference entity 40930C isof type GDT: BusinessTransactionDocumentReference. TheOriginPurchaseOrderReference may be passed on through all PurchaseOrdersso that the procurement planning component may refer to the originalPurchaseOrder of the ProductRecipientParty via theOriginPurchaseOrderReference during the delivery.

(i) Sales Order Fulfillment Item Attachment Package

The SalesOrderFulfillment Item Attachment Package 40926B is definedsimilarly to the Attachment package 40930 and includes theAttachmentWebAddress entity 40940C. The SalesOrderFulfillmentItem entity40932B has a 1:cn relationship with the AttachmentWebAddress entity40940C.

(j) Sales Order Fulfillment Item Description Package

The description package 40928B groups the texts to be described withreference to a SalesOrderFulfillmentItem. The description package 40928Bincludes a Description entity 40944C and a ConfirmationDescription40946C. The SalesOrderFulfillmentItem entity 40932B has a respective 1:crelationship 40948C, 40950C with each of the Description entity 40944Cand the ConfirmationDescription entity 40946C.

(i) Description

A Description is a text written in normal language that can be seen byparties with reference to the SalesOrderFulfillmentItem. The Descriptionentity 40944C is of type GDT: Description. The Description entity 40944Ccan be used for all types of textual information that relates to theSalesOrderFulfillmentConfirmation. An example would be the packagingrequested by a customer.

(ii) Confirmation Description

A ConfirmationDescription is a text written in normal language that canbe seen by parties with reference to theSalesOrderFulfillmentConfirmationItem. The ConfirmationDescriptionentity 40946C is of type GDT: Description. The ConfirmationDescriptioncan be used for all types of textual information that relates to an itemin a SalesOrderFulfillmentConfirmation. An example would be anexplanation from the procurement planning component as to why asubstitution subitem was created.

(k) Sales Order Fulfillment Item Schedule Line Package

The ScheduleLine Package 40930B is the grouping of the quantity and dateinformation on a SalesOrderFulfillmentItem. The ScheduleLine Package40930B includes a ScheduleLine entity 40952C and a ConfirmedScheduleLineentity 40954C. SalesOrderFulfillmentItem entity 40932B has a 1:nrelationship 40956C with the ScheduleLine entity 40952C and a 1:cnrelationship 40958C with the ConfirmedScheduleLine entity 40954C. TheScheduleLine entity 40952C has a 1:c relationship 40962C with theDeliveryPeriod entity 40960C, and the ConfirmedScheduleLine entity40954C has a 1:c relationship 40966C with the DeliveryPeriod entity40964C.

(i) Schedule Line

The ScheduleLine is a line with the quantity and date of the provisionschedule required by the selling system. The ScheduleLine entity 40952Cincludes an ID, an ActionCode, a Quantity, and a DeliveryPeriod. The IDis a unique identification issued by the vendor for the schedule line ofa SalesOrderFulfillmentItem, and is of type GDTBusinessTransactionDocumentItemScheduleLineID. The ActionCode is thecoded representation of a message request to the recipient to create,change, delete, or reject business objects, and is of type GDTActionCode. The Quantity is the requested or expected quantity in salesor order unit of measure, and is of type GDT Quantity. TheDeliveryPeriod is the (planned) delivery period: expected or confirmeddelivery date or period, and is of type GDT DateTimePeriod. The Quantityand the DeliveryPeriod may be changed by the selling component. Theprocurement planning component may specify a Quantity or DeliveryPeriodfor an item that it has newly proposed itself.

(ii) Confirmed Schedule Line

The ConfirmedScheduleLine is a line with the quantity and date of theprovision schedule confirmed via ATP and scheduling by the procurementplanning component. A confirmation for a partial quantity cannot beequated with a rejection of the remaining quantity. The confirmation ofa partial quantity merely means that the procurement planning componenthas accepted this partial quantity, and has not yet made a statementconcerning the remaining quantity. The ConfirmedScheduleLine entity40954C is defined similary to the ScheduleLine entity 40952C and has a1:c relationship 40966C with the DeliveryPeriod entity 40964C.

(4) Message Data Type Element Structure

FIGS. 410A-M depict the element structure for a message data typeSalesOrderFulfillmentMessage. The message data typeSalesOrderFulfillmentMessage includes the object SalesOrderFulfillmentincluded in the business document and the business information that isrelevant for sending a business document in a message. The elementstructure is similar to the above described data model of the messagedata type SalesOrderFulfillmentMessage as reflected in FIG. 409, butprovides additional information regarding the details for interfacingwith or implementing a SalesOrderFulfillmentMessage, such as aSalesOrderFulfillmentRequest and a SalesOrderFulfillmentConfirmation. Asshown in FIGS. 410A-D, the element structure identifies the differentpackages 41000 that may be in a respective SalesOrderFulfillmentRequestand a SalesOrderFulfillmentConfirmation. The element structure for aSalesOrderFulfillmentRequest and a SalesOrderFulfillmentConfirmationincludes five levels 41002, 41004, 41006, 41008, and 41010 each of whichis associated with a respective package 41000. The element structureidentifies the cardinality or occurrence 41012 and the data type 41014information for the elements at the respective levels 41002, 41004,41006, 41008, and 41010 in the respective package 41000.

The outermost package of this interface is a SalesOrderFulfillmentpackage 41016, which includes a SalesOrderFulfillmentMessage entity41018 at the first level 41002. The SalesOrderFulfillmentMessage entity41018 is of type MDT: SalesOrderFulfillmentMessage 41022. In oneimplementation, there is one 41020 SalesOrderFulfillmentMessage entity41018 in the SalesOrderFulfillment package 41016.

The SalesOrderFulfillment package 41016 also includes a MessageHeaderpackage 41024 and a SalesOrderFulfillment package 41026. TheMessageHeader package 41024 includes a MessageHeader entity 41028 thatis of type GDT: BusinessDocumentMessageHeader 41032. In oneimplementation, there is one or zero 41030 MessageHeader entities 41028for each SalesOrderFulfillmentMessage entity 41018.

The SalesOrderFulfillment package 41026 includes a SalesOrderFulfillmententity 41034 of type GDT: SalesOrderFulfillment 41038. In oneimplementation, there is one or zero 41036 SalesOrderFulfillment entity41034 for each SalesOrderFulfillmentMessage entity 41018. TheSalesOrderFulfillment entity 41034 includes an ID 41040, aBaseBusinessTransactionDocumentID 41046, aBaseBusinessTransactionDocumentTypeCode 41052, an ActionCode 41058, anItemListCompleteTransmissionIndicator 41064, a CreationDateTime 41070, aLastChangeDateTime 41076, and an AcceptanceStatusCode 41082. The ID41040 is of type GDT: BusinessTransactionDocumentID 41044. TheBaseBusinessTransactionDocumentID 41046 is of type GDT:BusinessTransactionDocumentID 41050. TheBaseBusinessTransactionDocumentTypeCode 41052 is of type GDT:BusinessTransactionDocumentTypeCode 41056. The ActionCode 41058 is oftype GDT: ActionCode 41062. The ItemListCompleteTransmissionIndicator41064 is of type GDT: CompleteTransmissionIndicator 41068. TheCreationDateTime 41070 is of type GDT: DateTime 41074. TheLastChangeDateTime 41076 is of type GDT: DateTime 41080. TheAcceptanceStatusCode 41082 is of type GDT: AcceptanceStatusCode 41086.In one implementation, for each SalesOrderFulfillment entity 41034,there is one 41042 ID 41040, one or zero 41048BaseBusinessTransactionDocumentID 41046, one or zero 41054BaseBusinessTransactionDocumentTypeCode 41052, one or zero 41060ActionCode 41058, one or zero 41066ItemListCompleteTransmissionIndicator 41064, one or zero 41072CreationDateTime 41070, one or zero 41078 LastChangeDateTime 41076, andone or zero 41084 AcceptanceStatusCode 41082.

The SalesOrderFulfillment package 41026 also includes a Party package41088, a Location package 41090, a DeliveryInformation package 41092, anAttachment package 41094, a Description package 41096, aFollowUpBusinessTransactionDocument or FollowUp package 41098, and aSalesOrderFulfillmentItem or Item Package 41000A.

As shown in FIG. 410B, the Party package 41088 includes a BuyerParty41002A, a SellerParty 41020A, a ProductRecipientParty 41026A, aVendorParty 41032A, a ManufacturerParty 41038A, and a CarrierParty41044A. The BuyerParty entity 41002A is of type GDT:BusinessTransactionDocumentParty 41006A. The SellerParty entity 41020Ais of type GDT: BusinessTransactionDocumentParty 41024A. TheProductRecipientParty entity 41026A is of type GDT:BusinessTransactionDocumentParty 41030A. The VendorParty entity 41032Ais of type. GDT: BusinessTransactionDocumentParty 41036A. TheManufacturerParty entity 41038A is of type GDT:BusinessTransactionDocumentParty 41042A. The CarrierParty 41044A is oftype GDT: BusinessTransactionDocumentParty 41048A. In oneimplementation, for each SalesOrderFulfillment entity 41034, there isone 41004A BuyerParty 41002A, one 41022A SellerParty 41020A, one or zero41028A ProductRecipientParty 41026A, one or zero 41034A VendorParty41032A, one or zero 41040A ManufacturerParty 41038A, and one or zero41046A CarrierParty 41044A.

The BuyerParty 41002A may include one 41010A InternalID 41008A of typeGDT: PartyInternalID 41012A and any number 41016A of StandardIDs 41014Aof type GDT: PartyInternalID 41018A. The SellerParty 41020A, theProductRecipientParty 41026A, the VendorParty 41032A, and theManufacturerParty 41038A, and a CarrierParty 41044A may each includeelements similar to the BuyerParty 41002A, such as a respectiveInternalID and a respective one or more StandardIDs.

The Location package 41090 includes a ShipToLocation entity 41050A oftype GDT: BusinessTransactionDocumentLocation 41054A and aShipFromLocation entity 41062A of type GDT:BusinessTransactionDocumentLocation 41066A. In one implementation, foreach SalesOrderFulfillment entity 41034, there is one or zero 41052AShipToLocation entity 41050A and one or zero 41064A ShipFromLocationentity 41062A. The ShipToLocation entity 41050A includes one 41058AInternalID 41056A of type GDT: LocationID 41060A. The ShipFromLocationentity 41062A may include elements similar to the ShipToLocation entity41050A, such as a respective InternalID.

The DeliveryInformation package 41092 includes a DeliveryTerms entity41068A of type GDT: DeliveryTerms 41072A. There is one or zero 41070ADeliveryTerms entity 41068A for each SalesOrderFulfillment entity 41034.The DeliveryTerms entity 41068A includes a DeliveryItemGroupID 41074A oftype GDT: BusinessTransactionDocumentGroupID 41078A, aDeliveryPriorityCode 41080A of type GDT:BusinessTransactionDocumentPriorityCode 41084A, an Incoterms entity41086A of type GDT: Incoterms 41090A, a PartialDelivery entity 41092A oftype GDT: PartialDelivery 41096A, a QuantityTolerance entity 41098A oftype GDT: QuantityTolerance 41002B, a Transport entity 41004B, and aDescription entity 41008B of type GDT: Description 41012B. In oneimplementation, for each DeliveryTerms entity 41068A, there is one orzero 41076A DeliveryItemGroupID 41074A, one or zero 41082ADeliveryPriorityCode 41080A, one or zero 41088A Incoterms entity 41086A,one or zero 41094A PartialDelivery entity 41092A, one or zero 41000BQuantityTolerance entity 41098A, one or zero 41006B Transport entity41004B, and one or zero 41010B Description entity 41008B.

The DeliveryInformation package 41092 also includes a DeliveryControlentity 41014B. There is one or zero 41016B DeliveryControl entity 41014Bfor each SalesOrderFulfillment entity 41034. The DeliveryControl entity41014B includes a DeliveryBlockedIndicator 41018B of type GDT:BusinessTransactionBlockedIndicator 41022B. There is one or zero 41020BDeliveryBlockedIndicator 41018B for each DeliveryControl entity 41014B.

The Attachment package 41094 includes an AttachmentWebAddress entity41024B of type GDT: WebAddress 41028B. In one implementation, there isany number 41026B of AttachmentWebAddress entities 41024B for eachAttachmentWebAddress entity 41024B.

The Description package 41096 includes a Description entity 41030B oftype GDT: Description 41034B and a ConfirmationDescription entity 41036Bof type GDT: Description 41040B. In one implementation, for eachSalesOrderFulfillment entity 41034, there is one or zero 41032BDescription entity 41030B and one or zero 41038B ConfirmationDescriptionentity 41036B.

The FollowUpMessage (“FollowUp”) package 41098 includes aFollowUpSalesOrderFulfillmentConfirmation entity 41042B, aFollowUpDespatchedDeliveryNotification entity 41052B, and aFollowUpBillingDueNotification entity 41062B. In one implementation, foreach SalesOrderFulfillment entity 41034, there is one or zero 41044BFollowUpSalesOrderFulfillmentConfirmation entity 41042B, one or zero41054B FollowUpDespatchedDeliveryNotification entity 41052B, and one orzero 41064B FollowUpBillingDueNotification entity 41062B. TheFollowUpSalesOrderFulfillmentConfirmation entity 41042B may have one41048B RequirementCode 41046B of type GDT:FollowUpMessageRequirementCode 41050B. TheFollowUpDespatchedDeliveryNotification entity 41052B may also have one41058B RequirementCode 41056B of type GDT:FollowUpMessageRequirementCode 41060B. TheFollowUpBillingDueNotification entity 41062B may also have one 41068BRequirementCode 41066B of type GDT: FollowUpMessageRequirementCode41070B.

The SalesOrderFulfillmentItem or Item package 41000A includes anSalesOrderFulfillmentItem or Item entity 41072B of type GDT:SalesOrderFulfillmentItem 41076B. There is any number 41074B of Itementities 41072B for SalesOrderFulfillment entity 41034. The Item 41072Bincludes an ID 41078B, a TypeCode 41084B, an ActionCode 41090B, aScheduleLineListCompleteTransmissionIndicator 41096B, a CreationDateTime41002C, a LastChangeDateTime 41008C, and an AcceptanceStatusCode 41014C.The ID 41078B is of type GDT: BusinessTransactionDocumentItemID 41082B.The TypeCode 41084B is of type GDT: BusinessTransactionDocumentTypeCode41088B. The ActionCode 41090B is of type GDT: ActionCode 41094B. TheScheduleLineListCompleteTransmissionIndicator 41096B is of type GDT:CompleteTransmissionIndicator 41000C. The CreationDateTime 41002C is oftype GDT: DateTime 41006C. The LastChangeDateTime 41008C is of type GDT:DateTime 41012C. The AcceptanceStatusCode 41014C is of type GDT:AcceptanceStatusCode 41018C. In one implementation, for eachSalesOrderFulfillment entity 41034, there is one 41080B ID 41078B, one41086B TypeCode 41084B, one or zero 41092B ActionCode 41090B, one orzero 41098B ScheduleLineListCompleteTransmissionIndicator 41096B, one orzero 41004C CreationDateTime 41002C, one or zero 41010CLastChangeDateTime 41008C, and one or zero 41016C AcceptanceStatusCode41014C.

Each Item 41072B also includes a HierarchyRelationship entity 41020C. Inone implementation, there is one or zero 41022C HierarchyRelationshipentities 41020C for each Item 41072B of the SalesOrderFulfillment entity41034. The HierarchyRelationship entity 41020C includes a ParentItemID41024C of type GDT: BusinessTransactionDocumentItemID 41028C and aTypeCode 41030C of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode 41034C. Inone implementation, for each HierarchyRelationship entity 41020C, thereis one or zero 41026C ParentItemID 41024C and one 41032C TypeCode41030C.

The SalesOrderFulfillmentItem or Item package 41000A also includes aProductInformation package 41036C, a Batch package 41038C, a Partypackage 41040C, a Location package 41042C, a DeliveryInformation package41044C, a BusinessTransactionDocumentReference or Reference package41046C, an Attachment package 41048C, a Description package 41050C, anda ScheduleLine package 41052C.

The ProductInformation package 41036C includes a Product entity 41054Cof type GDT: BusinessTransactionDocumentProduct 41058C and aProductCategory entity 41084C of type GDT:BusinessTransactionDocumentProductCategory 41088C. In oneimplementation, for each Item entity 41072B, there is one 41056C Productentity 41054C and one or zero 41086C ProductCategory entity 41084C. Theproduct entity 41054C includes an ID 41060C of type GDT: ProductID41064C, a StandardID 41066C of CDT: ProductStandardID 41070C, a PartyID41072C of type CDT: ProductPartyID 41076C, and a Description 41078C oftype GDT: Description 41082C. In one implementation, for each Productentity 41054C, there is one or zero 41062C ID 41060C, one or zero 41068CStandardID 41066C, one or zero 41074C PartyID 41072C and one or zero41080C Description 41078C.

The ProductCategory entity 41084C an ID 41090C of type GDT:ProductCategoryID 41094C. There may be one or zero 41092C ID 41090C foreach ProductCategory entity 41084C.

The Batch package 41096C includes a Batch entity 41096C. In oneimplementation, there is one or zero 41098C Batch entity 41096C for eachItem entity 41072B. The Batch entity 41096C includes an ID 41000D oftype GDT: BatchID 41004D. There is one or zero 41002D ID 41000D for eachBatch entity 41096C.

The SalesOrderFulfillment Item Party package 41040C includes elementssimilar to Party package 41088. As shown in FIG. 410I, the Party package41040C includes a BuyerParty 41006D, a SellerParty 41012D, aProductRecipientParty 41018D, a VendorParty 41024D, a ManufacturerParty41030D, and a CarrierParty 41036D. The BuyerParty entity 41006D is oftype GDT: BusinessTransactionDocumentParty 41010D. The SellerPartyentity 41012D is of type GDT: BusinessTransactionDocumentParty 41016D.The ProductRecipientParty entity 41018D is of type GDT:BusinessTransactionDocumentParty 41022D. The VendorParty entity 41024Dis of type GDT: BusinessTransactionDocumentParty 41028D. TheManufacturerParty entity 41030D is of type GDT:BusinessTransactionDocumentParty 41034D. The CarrierParty 41036D is oftype GDT: BusinessTransactionDocumentParty 41040D. In oneimplementation, for each SalesOrderFulfillment Item entity 41072D, thereis one 41008D BuyerParty 41006D, one 41014D SellerParty 41012D, one orzero 41020D ProductRecipientParty 41018D, one or zero 41026D VendorParty41024D, one or zero 41032 ManufacturerParty 41030D, and one or zero41038D CarrierParty 41036D. Each of these entities is defined similarlyto their corresponding counterpart in the Party package 41088.

The SalesOrderFulfillment Item Location Package 41042C includes elementssimilar to the Location Package 41090. The Location package 41042Cincludes a ShipToLocation entity 41042D of type GDT:BusinessTransactionDocumentLocation 41046D and a ShipFromLocation entity41048D of type GDT: BusinessTransactionDocumentLocation 41052D. In oneimplementation, for each SalesOrderFulfillment Item entity 41072B, thereis one or zero 41044D ShipToLocation entity 41042D and one or zero41050D ShipFromLocation entity 41048D. The ShipToLocation entity 41042Dand the ShipFromLocation entity 41048D has elements similar to thecorresponding entities, i.e., the ShipToLocation entity 41050A and theShipToLocation entity 41062A.

The SalesOrderFulfillment Item DeliveryInformation package 41044Cincludes elements similar to the DeliveryInformation package 41092. TheDeliveryInformation package 41044C includes the DeliveryTerms entity41054D of type GDT: DeliveryTerms 41058D. There is one or zero 41056DDeliveryTerms entity 41054D for each SalesOrderFulfillment Item entity41072B. The DeliveryTerns entity 41054D includes a DeliveryItemGroupID41060D of type GDT: BusinessTransactionDocumentGroupID 41064D, aDeliveryPriorityCode 41066D of type GDT:BusinessTransactionDocumentPriorityCode 41070D, an Incoterms entity41072D of type GDT: Incoterms 41076D, a PartialDelivery entity 41078D oftype GDT: PartialDelivery 41082D, a QuantityTolerance entity 41084D oftype GDT: QuantityTolerance 41088D, a Transport entity 41090D, and aDescription entity 41094D of type GDT: Description 41098D. In oneimplementation, for each DeliveryTerms entity 41054D, there is one orzero 41062D DeliveryItemGroupID 41060D, one or zero 41068DDeliveryPriorityCode 41066D, one or zero 41074D Incoterms entity 41072D,one or zero 41080D PartialDelivery entity 41078D, one or zero 41086DQuantityTolerance entity 41084D, one or zero 41092D Transport entity41090D, and one or zero 41096D Description entity 41096D.

The DeliveryInformation package 41044C also includes a DeliveryControlentity 41000E. There is one or zero 41002E DeliveryControl entity 41000Efor each SalesOrderFulfillment Item entity 41072B. The DeliveryControlentity 41000E includes a DeliveryBlockedIndicator 41004E of type GDT:BusinessTransactionBlockedIndicator 41008E. There is one or zero 41006EDeliveryBlockedIndicator 41004E.

The BusinessTransactionDocumentReference or Reference package 41046Cincludes a QuoteReference 41010E of type GDT:BusinessTransactionDocumentReference 41014E, a SalesContractReference41016E of type GDT: BusinessTransactionDocumentReference 41020E, aPurchaseOrderReference 41022E of type GDT:BusinessTransactionDocumentReference 41026E, and anOriginPurchaseOrderReference 41034E of type GDT:BusinessTransactionDocumentReference 41038E. In one implementation, foreach SalesOrderFulfillment Item 41072B, there is one or zero 41012EQuoteReference 41010E, one or zero 41018E SalesContractReference 41016E,one or zero 41024E PurchaseOrderReference 41022E, and one or zero 41036EOriginPurchaseOrderReference 41034E.

The SalesOrderFulfillment Item Attachment Package 41048C includeselements similar to the Attachment package 41094. The Attachment package41048C includes an AttachmentWebAddress entity 41040E of type GDT:WebAddress 41044E. In one implementation, there is any number 41042E ofAttachmentWebAddress entities 41040E for each AttachmentWebAddressentity 41040E.

The SalesOrderFulfillment Item Description Package 41050C includeselements similar to the Description package 41096. The Descriptionpackage 41050C includes a Description entity 41046E of type GDT:Description 41050E and a ConfirrnationDescription entity 41052E of typeGDT: Description 41056E. In one implementation, for eachSalesOrderFulfillment Item entity 41072B, there is one or zero 41048EDescription entity 41046E and one or zero 41054E ConfirmationDescriptionentity 41052E.

The ScheduleLine Package 41052C includes a ScheduleLine entity 41058E oftype GDT: SalesOrderFulfillmentItemScheduleLine 41062E and aConfirmedScheduleLine entity 41088E of type GDT:SalesOrderFulfillmentItemScheduleLine 41092E. In one implementation, foreach SalesOrderFulfillment Item entity 41072B, there is one or more41060E ScheduleLine entity 41058E and any number 41090EConfirmedScheduledLine 41088E. Each ScheduleLine 41058E includes an ID41064E of type GDT: ScheduleLineID 41068E, ActionCode 41070E of typeGDT: ActionCode 41074E, Quantity 41076E of type GDT: Quantity 41080E,and DeliveryPeriod entity 41082E of type GDT: DateTimePeriod 41092E. Inone implementation, for each SalesOrderFulfillment Item entity 41072B,there is one or zero 41066E ID 41064E, one or zero 41072E ActionCode41070E, one 41078E Quantity 41076E, and one or zero 41084EDeliveryPeriod entity 41082E.

The ConfirmedScheduleLine entity 41088E includes an ID 41094E of typeGDT: ScheduleLineID 41098E, ActionCode 41000F of type GDT: ActionCode41004F, Quantity 41006F of type GDT: Quantity 41010F, and aDeliveryPeriod entity 41012F of type GDT: DateTimePeriod 41016F. In oneimplementation, for each SalesOrderFulfillment Item entity 41072B, thereis one or zero 41096E ID 41094E, one or zero 41002F ActionCode 41000F,one 41008F Quantity 41006F, and one or zero 41014F DeliveryPeriod entity41012F.

q) Delivery Interfaces

Delivery interfaces are used for the business scenarios Supplier ManagedInventory (SMI) and Release Processing as messages between a supplierand the Inventory Collaboration Hub (ICH) of a manufacturer and betweenthe ICH and the back-end system of the manufacturer.

The business scenario Supplier Managed Inventory describes the planningand processing of replenishment deliveries for a manufacturer at asupplier. The supplier receives data about the existing stock and thecurrent gross requirement for a product from the Inventory CollaborationHub. The business scenario Release Processing is similar to the SMIscenario, regarding the message flow. However, the processing ofreplenishment deliveries from the manufacturer is triggered here by thepublication of the manufacturer's net requirements for the products.This publication along with the receipt of the shipping notification forthe resulting delivery also takes place with the Inventory CollaborationHub.

(1) Message Types

(a) Despatched Delivery Notification

A DespatchedDeliveryNotification is a notice for a goods recipient aboutthe planned arrival/pickup/issue date for a ready-to-send deliveryincluding details about the contents of the delivery. The structure ofthe message type DespatchedDeliveryNotification is specified in themessage data type DespatchedDeliveryNotificationMessage 41200. TheDespatchedDeliveryNotification is often also known as the “AdvancedShipping Notification” (ASN). It is sent from a vendor (VendorParty) toa product recipient (ProductRecipientParty). The message transfer isgenerally complete (“complete transmission”).

(b) Received Delivery Notification

A ReceivedDeliveryNotification is a message to the vendor about thearrival of the delivery he sent to the goods recipient, includingdetails about the content of the received delivery. The structure of themessage type ReceivedDeliveryNotification is specified in the messagedata type ReceivedDeliveryNotificationMessage. TheReceivedDeliveryNotification is also often known as the “Proof ofDelivery” (POD). It is sent from a product recipient to a vendor. Themessage is used to notify the vendor about the receipt of his delivery.The message also enables you to report quantity variances of the arriveddelivery at the shipper at item level. The message transfer is generallycomplete (“complete transmission”).

(2) Message Choreography.

The following message choreography describes a logical sequence of themessage types for the scenario realization. A vendor notifies a goodsrecipient (Product Recipient) about his goods delivery with aDespatchedDeliveryNotification. The goods recipient (Product Recipient)confirms the receipt of a delivery from the vendor with aReceivedDeliveryNotification.

(3) Message Data Type Despatched Delivery Notification

The message data type DespatchedDeliveryNotificationMessage 41200 (seeFIG. 412) includes the business information that is relevant for sendinga business document in a message and the object Delivery included in thebusiness document in the view of a DespatchedDeliveryNotification. Itincludes a MessageHeader package 41202 and a Delivery Package 41204. Themessage data type DespatchedDeliveryNotificationMessage makes thestructure available for the message type DespatchedDeliveryNotificationand the interfaces based on it.

(a) Message Header Package

A MessageHeader package 41204 groups the business information that isrelevant for sending a business document in a message. It includes aMessageHeader entity 41206. The DispatchDeliveryNotificationMessageentity 41208 includes the MessageHeader entity 41206 and has a 1:1relationship with it.

(i) Message Header

A MessageHeader entity 41206 groups the business information from theview of the sending application. It includes information to identify thebusiness document in a message, information about the sender and,possibly, information about the recipient.

The MessageHeader entity 41206 includes a SenderParty entity 41210 and aRecipientParty entity 41212. It has a respective 1:c relationship withthese entities. It is of type GDT: BusinessDocumentMessageHeader.

The MessageHeader entity 41206 includes an ID, a ReferenceID, and aCreationDateTime. The ID an identifier for the business document in a(technical) message, and is of type GDT: MessageID. The ReferenceID isan identifier for another business document in another (technical)message, and is of type GDT: MessageID. The CreationDateTime is thecreation date and time of message, and is of type GDT: DateTime.

(ii) Sender Party

A SenderParty entity 41210 is responsible for sending a businessdocument at business application level. The SenderParty entity 41210 isof type GDT: BusinessDocumentMessageHeaderParty.

(iii) Recipient Party

A RecipientParty entity 41212 is responsible for receiving a businessdocument at business application level. The RecipientParty entity 41212is of type GDT: BusinessDocumentMessageHeaderParty.

(b) Delivery Package

The Delivery Package 41204 groups the delivery and its packages. Itincludes a Party Package 41214, a Location Package, aTransportInformation Package, a DeliveryInformation Package 41220, aDeliveryItem Package 41222, and a HandlingUnit Package 41224.

(i) Delivery

The delivery entity 41226 in the view of aDespatchedDeliveryNotification describes when and where from a productis to be delivered or picked up, and the quantity. TheDispatchedDeliveryNotificationMessage entity 41208 includes the Deliveryentity 41226 and has a 1:1 relationship with it. A delivery entity 41226generally includes of several items, which refer to the specificationsfor the quantity, weight, and volume for each delivered product, as wellas preceding documents and/or outline agreements. Delivery includes anID, a CreationDateTime, a GrossWeightMeasure, a NetWeightMeasure, aVolumeMeasure, an ArrivaIDateTime, an IssueDateTime, aCarrierHandoverDateTime, a GroupID, a WayBillID, a TransportModeCode, aDangerousGoodsIndicator, and a Note.

The ID is an identifier for the delivery, and is of type GDT:BusinessTransactionDocumentID. The CreationDateTime is the creation timeof delivery, and is of type GDT: DateTime. The GrossWeightMeasure is thegross weight of delivery, and is of type GDT: Measure. TheNetWeightMeasure is the net weight of delivery, and is of type GDT:Measure. The VolumeMeasure is the volume of delivery, and is of typeGDT: Measure. The ArrivaIDateTime is the (estimated) arrival date/timeof delivery, and is of type GDT: DateTime. The IssueDateTime is the(estimated) shipping date/time of delivery, and is of type GDT:DateTime. The CarrierHandoverDateTime is the time of goods transfer tocarrier, and is of type GDT: DateTime. The GroupID is an identifier fora group of deliveries to which the existing delivery belongs, and is oftype GDT: BusinessTransactionDocumentGroupID. The WayBillID is anidentifier of bill of lading, and is of type GDT:BusinessTransactionDocumentID. The TransportModeCode is the encodedrepresentation of transportation mode, and is of type GDT:TransportModeCode. The DangerousGoodsIndicator is the specification ofwhether delivery includes dangerous goods or not, and is of type GDT:DangerousGoodsIndicator. The Note is the note for delivery, and is oftype GDT: Note.

(ii) Party Package

The Party Package 41214 is the grouping of the business partners thatmay be relevant within the shipping notification. It includes aVendorParty entity 41228, a ProductRecipientParty entity 41230, and aCarrierParty entity 41232, a BuyerParty 41241, and a BilltoPayParty31245. The Delivery entity 41226 includes these entities and has arespective 1:1 relationship with the VendorParty entities 41228 and theProductRecipientParties entity 41230, and a 1:c relationship with theCarrierParty entities 41232. The BuyerParty 41241 is the company orperson that/who has bought the notified products. The BuyerParty 31241is type GDT: BusinessTransactionDocumentParty, whereby only theInternalID, the StandardID, the ProductRecipientID, and Address areused. The BillToParty 41245 is the company or the person to whom thebill for the notified products is sent. The BillToParty 41245 is typeGDT: BusinessTransactionDocumentParty, whereby only the InternalID, theStandardID, the ProductRecipientID, and Address are used.

(a) Vendor Party

VendorParty entity 41228 is the company or the person to deliver thenotified products. VendorParty entity 41228 is of type GDT:BusinessTransactionDocumentParty, whereas the InternalID, theStandardID, and the ProductRecipientID are used. For an internalcommunication, the InternalID is used for party entity types. For aninterenterprise communication, for party entity types either theStandardID or the partner-role-specific ID of the receiving partner isused, in other words, for Supplier Collaboration scenarios theProductRecipientID is used, and for Customer Collaboration scenarios,the VendorID is used. Due to the different possibilities for ID use, IDelements of the particular “Party” are optional.

(b) Product Recipient Party

ProductRecipientParty entity 41230 is the company or the person to takedelivery of the notified products. ProductRecipientParty entity 41230 isof type GDT: BusinessTransactionDocumentParty, whereas the InternalID,the StandardID, and the ProductRecipientID are used. The use of theaddress of the ProductRecipientParty entity 41230 as the deliveryaddress may not be intended in a delivery process in Supply ChainPlanning and Execution. The ShipToLocation is intended for this.

(c) Carrier Party

CarrierParty entity 41232 is the company or person that/who transportsthe notified products. CarrierParty entity 41232 is of type GDT:BusinessTransactionDocumentParty, whereas the InternalID, theStandardID, and the ProductRecipientID are used.

(iii) Location Package

The Location Package 41216 is the grouping of the locations that may berelevant within the shipping notification. It includes aShipFromLocation entity 41234, a ShipToLocation entity 41236, and aTransShipmentLocation 41249. The Delivery entity 41226 includes theShipToLocation entity 41234 and the ShipFromLocation entity 41236. TheDelivery entity 41226 has a 1:1 relationship with theShipToLocationentity 41234 and a 1:c relationship with the ShipFromLocation entity41236.

(a) Ship From Location

The ShipFromLocation entity 41234 is the place where the notifiedproducts to be delivered come from. The ShipFromLocation entity 41234 isof type GDT: BusinessTransactionDocumentShipFromLocation, whereas theInternalID, the StandardID, the ProductRecipientID, and the VendorID areused. For an internal communication, the InternalID is used for locationentity types. For an interenterprise communication, for location entitytypes, either the StandardID or the partner-role-specific ID of thereceiving partner is used, in other words, for Supplier Collaborationscenarios the ProductRecipientID is used, and for Customer Collaborationscenarios, use the VendorID is used. Due to the different possibilitiesfor ID use, ID elements of the particular “location” are optional.

(b) Ship To Location

The ShipToLocation entity 41236 is the place to where the notifiedproducts are delivered. The ShipToLocation entity 41236 is of type GDT:BusinessTransactionDocumentShipToLocation, whereas the InternalID, theStandardID, the ProductRecipientID, and the VendorID are used.

Transshipment Location

The TransshipmentLocation entity 41249 is the location at which thenotified products are transferred on the way to the recipient. TheTransshipmentLocation 41249 is type GDT:BusinessTransactionDocumentTransshipmentLocation, whereby theInternalID, StandardID, VendorID, ProductRecipientID, Note, and Addressare used.

(iv) Transport Information Package

The TransportInformation Package 41218 is the summary of transportationinformation that may be relevant within the shipping notification. Itincludes a TransportMeans entity 41238 and a TransportTracking entity41240. The Delivery entity 41226 includes the TransportMeans entity41238 and the TransportTracking entity 41240. It has a 1:c relationshipwith these entities.

(a) Transport Means

The TransportMeans entity 41238 is the description of a means oftransport and can also include information for a more detailedidentification. The TransportMeans entity 41238 is of type GDT:TransportMeans.

(b) Transport Tracking

The TransportTracking entity 41240 delivers transport-relatedinformation that can be used for tracking deliveries, for example, ingoods deliveries. The TransportTracking entity 41240 is of type GDT:TransportTracking.

(v) Delivery Information Package

The DeliveryInformation Package 41220 is the summary of deliveryinformation that may be relevant within the shipping notification. Itincludes The Incoterms entity 41242. The Delivery entity 41226 includesthe Incoterms entity 41242 and has a 1:c relationship with it.

The Incoterms entity 41242 is a commercial contract formula for thedelivery conditions that correspond with the rules compiled by theInternational Chamber of Commerce (ICC). The Incoterms entity 41242 isof type GDT: Incoterms.

(vi) Delivery Item Package

The DeliveryItem Package 41222 is a grouping of items of a notifieddelivery, which includes specifications for the quantity of a product tobe delivered/picked up. It includes aBusinessTransactionDocumentReference package 41244 and aProductInformation package 41246.

(a) Delivery Item

DeliveryItem entity 41248 describes what quantity of a product is to bedelivered/picked up. The DeliveryItem entity 41248 includes an ID, aConsignmentIndicator, a GrossWeightMeasure, a NetWeightMeasure, aVolumeMeasure, a Quantity, Dangerous Goods, and a Note. The Deliveryentity 41226 includes the DeliveryItem entity 41248 and has 1:cnrelationship with it.

The ID is the identifier for the item in the delivery, which is of typeGDT: BusinessTransactionDocumentItemID. The ConsignmentIndicator is thespecification whether the item is intended for the consignment stock ornot, which is of type GDT: ConsignmentIndicator. The GrossWeightMeasureis the gross weight of products in the delivery item, which is of typeGDT: Measure. The NetWeightMeasure is the net weight of products in thedelivery item, which is of type GDT: Measure. The VolumeMeasure is thevolume of products in the delivery item, which is of type GDT: Measure.The Quantity is the quantity of product in the delivery item, which isof type GDT: Quantity. The Dangerous Goods is the classification of adangerous goods in the delivery item, which is of type GDT:DangerousGoods. The Note is the note for item of delivery, which is oftype GDT: Note.

(b) Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 41244 is a grouping ofreferences to other business documents that may occur in the shippingnotification. It includes a PurchaseOrderReference, aSchedulingAgreementReference, an OriginPurchaseOrder Reference and aSalesOrderReference. The DeliveryItem entity 41248 includes thePurchaseOrder Reference entity 41250, the SchedulingAgreementReferenceentity 41252 and the SalesOrderReference entity 41254 and has arespective 1:c relationship with these entities.

(i) Purchase Order Reference

The PurchaseOrderReference entity 41250 is the reference to a purchaseorder or an item within a purchase order. PurchaseOrderReference is oftype GDT: BusinessTransactionDocumentReference. ThePurchaseOrderReference entity 41250 includes the purchase order numberand purchase order item number specified by the buyer.

(ii) Scheduling Agreement Reference

The SchedulingAgreementReference entity 41252 is the reference to anoutline agreement. According to the rules of the outline agreement,products are procured on predefined dates within a time period. TheSchedulingAgreementReference entity 41252 is of type GDT:BusinessTransactionDocumentReference.

(iii) Sales Order Reference

The SalesOrderReference entity 41254 is the reference to an order or anitem within an order. The SalesOrderReference entity 41254 is of typeGDT: BusinessTransactionDocumentReference. SalesOrderReference includesthe order number and order item number specified by the vendor.

(iv) Origin Purchase Order Reference

The OriginPurchaseOrderReference entity 41283 is the reference to theoriginal purchase order or to an item within the original purchaseorder. The OriginPurchaseOrderReference 41283 is type GDT:BusinessTransactionDocumentReference.

(v) Sales Order Reference

The SalesOrderReference entity 41254 is the reference to an order or anitem within an order. The SalesOrderReference entity 41254 is of typeGDT: BusinessTransactionDocumentReference. SalesOrderReference includesthe order number and order item number specified by the vendor.

(c) Product Information Package

The ProductInformation package 41246 is a group of information thatcharacterizes the product in a delivery in detail. It includes a Productentity 41256 and a Batch entity 41258. The DeliveryItem entity 41248includes the Product entity 41256 and the Batch entity 41258, and has a1:1 relationship with the Product entity 41256 and a 1:c relationshipwith the Batch entity 41258.

(i) Product

Product entity 41256 includes specifications to identify a deliveredproduct and to track manufacture-related changes to the product. Productentity 41256 is of type GDT: BusinessTransactionDocumentProduct, whereasthe InternalID, the StandardID, the ProductRecipientID, and the VendorIDare used together with the ChangeNumber and, if necessary, the note. Foran internal communication, the InternalID is used for product entitytypes. For an interenterprise communication, for product entity types,either the StandardID or the partner-role-specific ID of the receivingpartner is used, in other words, for Supplier Collaboration scenariosthe ProductRecipientID is used, and for Customer Collaboration scenariosthe VendorID is used. Due to the different possibilities for ID use, IDelements of the particular ‘product’ are optional.

(ii) Batch

Batch entity 41258 is a batch in the delivery item. Batch entity 41258includes an InternalID, a VendorID, a ProductRecipientID, aManufacturingDate, a BestBeforeDate, and an OriginCountryCode.

The InternalID is the proprietary identifier for the batch, and is oftype GDT: BatchID. The VendorID is an unique identifier used by theVendorParty for the batch, and is of type GDT: BatchID. TheProductRecipientID is an unique identifier used by theProductRecipientParty entity 41230 for the batch, and is of type GDT:BatchID. The ManufacturingDate is the date of manufacture of the batch,and is of type GDT: Date. The BestBeforeDate is the best-before date ofbatch, and is of type GDT: Date. The OriginCountryCode is the encodedrepresentation of country of origin of batch, and is of type GDT:CountryCode.

(vii) Handling Unit Package

The HandlingUnit Package 41224 is the summary of information thatcharacterizes in detail how the delivery is packed or to be packed. Itincludes a HandlingUnit entity 41260. The DeliveryItem entity 41248includes the HandlingUnit entity 41260 and has a 1:cn relationship withit.

HandlingUnit entity 41260 is a physical unit of packaging materials(load carrier, additional packaging materials) and the packaged products(of type “Material”). HandlingUnit entity 41260 is of type GDT:HandlingUnit.

(4) Message Data Type Received Delivery Notification The message datatype ReceivedDeliveryNotificationMessage groups the business informationthat is relevant for sending a business document in a message and theobject Delivery included in the business document in the view of aReceivedDeliveryNotification. It includes a MessageHeader package 41320and a DeliveryPackage 41304. The message data typeReceivedDeliveryNotificationMessage makes the structure available forthe message type ReceivedDeliveryNotification and the interfaces basedon it.

(a) Message Header Package

A MessageHeader package 41302 groups the business information that isrelevant for sending a business document in a message. The MessageHeader41302 may not be required in the ReceivedDeliveryNotification.

(b) Delivery Package

The Delivery Package 41304 groups the delivery and its packages. Itincludes a Party Package 41306, a Location Package 41308, and aReceivedDeliveryItem Package 41310.

(i) Delivery

The Delivery entity 41312 in the view of a ReceivedDeliveryNotificationis the detailed confirmation of the receipt of a delivery. TheReceivedDeliveryNotificationMessage entity 41314 includes the Deliveryentity 41312 and has a 1:1 relationship with it. Delivery entity 41312includes an ID and a ReceiptDateTime. The ID is an identifier for thedelivery, and is of type GDT: BusinessTransactionDocumentID. TheReceiptDateTime is the time of arrival of delivery according to thegoods receipt posting, and is of type GDT: DateTime. The receiveddelivery can vary from a delivery specified on a deliverynote/previously notified by a DespatchedDeliveryNotification delivery(for example, varying quantities as a result of damages to thetransport, varying arrival time).

(ii) Party Package

The Party Package 41306 is the grouping of the business partners thatmay be relevant within the notification about receipt of delivery. Itincludes a VendorParty entity 41316 and a ProductRecipientParty entity41318. The Delivery entity 41312 includes the VendorParty entity 41316and the ProductReipientParty entity 41318 and has a respective 1:1relationship with these entities.

(a) Vendor Party

VendorParty entity 41316 is the company or the person that/who deliveredthe products. VendorParty entity 41316 is of type GDT:BusinessTransactionDocumentParty, whereas the InternalID, theStandardID, and the ProductRecipientID are used. For an internalcommunication, the InternalID is used for party entity types. For aninterenterprise communication, for party entity types, either theStandardID or the partner-role-specific ID of the receiving partner isused, in other words, for Supplier Collaboration scenarios theProductRecipientID is used, and for Customer Collaboration scenarios,the VendorID is used. Due to the different possibilities for ID use, IDelements of the particular “Party” are optional.

(b) Product Recipient Party

ProductRecipientParty entity 41318 is the company or the person that/whotook delivery of the products. ProductRecipientParty entity 41318 is oftype GDT: BusinessTransactionDocumentParty, whereas the InternalID, theStandardID, and the ProductRecipientID are used. The use of the addressof the ProductRecipientParty entity 41318 as the delivery address maynot be intended in a delivery process in Supply Chain Planning andExecution. The ShipToLocation is intended for this.

(iii) Location Package

The Location Package 41308 is the grouping of the locations that may berelevant within the notification about receipt of delivery. It includesa ShipFromLocation and a ShipToLocation entity 41320.

ShipToLocation entity 41320 is the place to where the products weredelivered. ShipToLocation entity 41320 is of type GDT:BusinessTransactionDocumentShipToLocation, whereas the InternalID, theStandardID, the ProductRecipientID, and the VendorID are used. For aninternal communication, the InternalID is used for location entitytypes. For an interenterprise communication, for location entity types,either the StandardID or the partner-role-specific ID of the receivingpartner is used, in other words, for Supplier Collaboration scenariosthe ProductRecipientID is used, and for Customer Collaboration scenariosthe VendorID is used. Due to the different possibilities for ID use, IDelements of the particular “location” are optional.

(iv) Delivery Item Package

The DeliveryItem Package 41310 is a grouping of the DeliveryItem entity41322 and its packages. It includes a ProductInformation Package 41324and a DeliveryInformation Package 41326. The Delivery entity 41312includes the DeliveryItem entity 41322 and has a 1:cn relationship withit.

(a) Delivery Item

DeliveryItem entity 41322 describes which quantity of a product has beenreceived. DeliveryItem entity 41322 includes an ID, aCompletedIndicator, an InventoryStatusDateTime, and a ReceivedQuantity.The ID is an identifier for the item of the delivery received, which isof type GDT: BusinessTransactionDocumentItemID. The CompletedIndicatoris the specification whether the delivery is completed from therecipient's point of view. This may also be the case if a quantity belowthe desired or notified quantity of the product has arrived, which is oftype GDT: BusinessTransactionCompletedIndicator. TheInventoryStatusDateTime is the date and time at which the goods receiptis posted into the warehouse stock, which is of type GDT:InventoryStatusDateTime. The ReceivedQuantity is the actual receivedquantity of the product, which is of type GDT: Quantity.

ReceiptDateTime is the time of the goods receipt posting,InventoryStatusDateTime is the time of the update for the goods receiptin the warehouse stock. As the update of the warehouse stock can takeplace later than the goods receipt posting, these dates may vary fromeach other, whereupon the InventoryStatusDateTime lies after theReceiptDateTime. The InventoryStatusDateTime is required to ensure dataconsistency at the recipient of the ReceivedDeliveryNotification.

(b) Product Information Package

The ProductInformation package 41324 is a grouping of information thatcharacterizes the product in a delivery in detail. It includes a Productentity 41328. The DeliveryItem entity 41322 includes the Productentities 41328 and has a 1:1 relationship with it.

Product entity 41328 includes the specifications for identifying adelivered product. Product is of type GDT:BusinessTransactionDocumentProduct, whereas the InternalID, theStandardID, the ProductRecipientID, and the VendorID are used. For aninternal communication, the InternalID is used for product entity types.For an interenterprise communication, for product entity types, eitherthe StandardID or the partner-role-specific ID of the receiving partneris used, in other words, for Supplier Collaboration scenarios theProductRecipientID is used, and for Customer Collaboration scenarios,the VendorID is used. Due to the different possibilities for ID use, IDelements of the particular ‘product’ are optional.

(c) Delivery Information Package

The DeliveryInformation Package 41326 is the summary of deliveryinformation about a product. It includes a Variance entity 41330. TheDeliveryItem entity 41322 includes the Variance entity 41330 and has a1:cn relationship with it. Variance describes a variance in the receivedquantity of a product and type of and reason for the variance. TheVariance entity 41330 includes a Quantity and a QuantityDiscrepancyCode.The Quantity is the quantity deviation from the shipping notification(difference). This may be specified without a sign. It can be determinedwhether too much or too little was delivered from the followingQuantityDiscrepancyCode, which is of type GDT: Quantity. TheQuantityDiscrepancyCode is the encoded representation of type of andreason for the deviation at the received product, which is of type GDT:QuantityDiscrepancyCode.

(5) Element Structure

(a) Despatched Delivery Notification

FIG. 414 depict the element structure forDespatchedDeliveryNotification. The element structure is similar to thedata model, but provides additional information regarding the details ofthe interface. The element structure identifies the different packages41400 in the interface, and represents the entities at various levelswithin the interface. As depicted in FIGS. 414-414, the interface forDespatchedDeliveryNotification includes five levels 41402, 41404, 41406,41408, and 41410. The element structure identifies the cardinality 41412between the entities of the interface, and provides information (i.e.,type 41414) regarding the data type that provides the basis for theentity. The outermost package of this interface is aDespatchedDeliveryNotificationMessage package 41416, which includes aDespatchedDeliveryNotificationMessage entity 41418 at the first level41402. The DespatchedDeliveryNotificationMessage entity 41418 is of typemessage data type (“MDT”) 41414 “DespatchedDeliveryNotificationMessage”41422 and there is one or zero 41420 occurrences.

The DespatchedDeliveryNotificationMessage package 41416 includes aMessageHeader package 41424 and a Delivery package 41426. TheMessageHeader package 41424 includes a MessageHeader entity 41428, whichis of type generic data type (“AGDT”) 41414 “MessageHeader” 41432. Thereis one or zero 41430 MessageHeader entity 41428 for eachDespatchedDeliveryNotificationMessage package 41424.

The MessageHeader entity 41428 includes a MessageID 41434 and aCreationDateTime 41440. The MessageID 41434 is of type GDT 41414MessageID 41438. The CreationDateTime 41440 is of type GDT 41414DateTime 41444. There is one 41436 MessageID 41434 for eachMessageHeader entity 41428, one or zero 41442 CreationDateTime 41440 foreach MessageHeader entity 41428.

The MessageHeader entity 41428 also includes a SenderParty entity 41446and a RecipientParty entity 41452. The SenderParty entity 41446 is oftype AGDT 41414 BusinessDocumentMessageHeaderParty 41450. TheRecipientParty entity 41452 is also of type AGDT 41414BusinessDocumentMessageHeaderParty 41456. There is one or zero 41448SenderParty entity 41446 for each MessageHeader entity 41428, and thereis one or zero 41454 RecipientParty entity 41452 for each MessageHeaderentity 41428.

The Delivery package 41426 includes a Delivery entity 41458, a Partypackage 41442A, Location package 41444A, TransportInformation package41446A, DeliveryInformation package 41448A, Item package 41450A, andHandlingUnit package 41450C. There is one 41460 Delivery entity 41458for each DespatchedDeliveryNotificationMessage package 41426. TheDelivery entity 41458 includes an ID 41464, a CreationDateTime 41470, aGrossWeightMeasure 41476, a NetWeightMeasure 41482, a VolumeMeasure41488, an ArrivaIDateTime 41494, IssueDateTime 41400A,CarrierHandoverDateTime 41406A, GroupID 41412A, WayBillID 41418A, aTransportModeCode 41424A, a DangerousGoodsIndicator 41430A, an ActionCode 41467, a ProductRecipientID 41473, a ReturnsIndicator 41419A and aNote 41436A.

There is one 41466 ID 41464 for each Delivery entity 41458. The ID 41464is of type GDT 41414 BusinessTransactionDocumentID 41474. ACreationDateTime 41470 has one 41472 occurrence and is of type GDT 41414DateTime 41474. GrossWeightMeasure 41476 has zero or one 41478occurrences and is of type GDT 41414 Measure41480. NetWeightMeasure41482 has zero or one 41484 occurrences and is of type GDT 41414 Measure41486. VolumeMeasure 41488 has zero or one 41490 occurrences and is oftype GDT 41414 Measure 41492. ArrivaIDateTime 41494 has zero or one41496 occurrences and is of type GDT 41414 DateTime 41498. IssueDateTime41400A has zero or one 41402A occurrences and is of type GDT 41414DateTime 41404A. CarrierHandoverDateTime 41406A has zero or one 41408Aoccurrences and is of type GDT 41414 DateTime 41410A. GroupID 41412A haszero or one 41414A occurrences and is of type GDT 41414BusinessTransactionDocumentGroupID 41416A. WayBillID 41418A has zero orone 41420A occurrences and is. of type GDT 41414BusinessTransactionDocumentID 41422A. TransportModeCode 41424A has zeroor one 41426A occurrences and is of type GDT 41414 TransportModeCode41428A. DangerousGoodsIndicator 41430A has zero or one 41432Aoccurrences and is of type GDT 41414 DangerousGoodsIndicator 41434A.Note 41436A has zero or one 41438A occurrences and is of type GDT 41414Note 41440A. ActionCode has zero or one 41469 occurrences of and thename is ActionCode 41471. ProductRecipientID has zero or one 41475occurrences and the name is BusinessTransactionDocumentID 41466.ReturnIndicator 41421A has zero or one occurrences and the name isReturnsIndicator 41423A.

The Party package 41442A includes a VendorParty entity 41452A, aProductRecipientParty entity 41458A, a BuyerParty entity 41467A, aBillToParty entity 41400E and a CarrierParty entity 41464A. TheVendorParty entity 41452A is of type AGDT 41414BusinessTransactionDocumentParty 41456A. There is one 41454A VendorPartyentity 41452A for each Party package 41442A. There is one 41460AProductRecipientParty entity 41458A for each Party package 42A 414. TheProductRecipientParty entity 58A is of type AGDT 41414BusinessTransactionDocumentParty 41462A. The CarrierParty entity 41464Ais of type GDT 41414 BusinessTransactionDocumentParty 41468A. There isone or zero 41466A CarrierParty entity 41464A for each Party package41442A.

The BuyerParty package 41467A includes an InternalID 41473A, aStandardID 41479A, a ProductRecipientID 41485A, and an Address 41464A.The InternalID 41473A has zero or one occurrences 41475A and the namePartyInternalID 41477A. The StandardID 41479A has any number ofoccurrences 41481A and the name PartyStandardID 41483A. TheProductRecipientID 41485A has zero or one occurrences 41487A and thename PartyPartyID 41489A. The Address 41464A has zero or one occurrences41491A and the name Address 41493A. The BillToParty package 41400Eincludes an InternalID 41406E, a StandardID 41412E, a ProductRecipientID41418E, and an Address 41424E. The InternalID 41406E has zero or oneoccurrences 41408E and the name PartyInternalID 41410E. The StandardID41412E has any number of occurrences 41414E and the name PartyStandardID41416E. The ProductRecipientID 41418E has zero or one occurrences 41420Eand the name PartyPartyID 41422E. The Address 41424E has zero or oneoccurrences 41426E and the name Address 41428E.

The Location package 41444A includes a ShipFromLocation entity 41470Aand a ShipToLocation entity 41476A. The ShipFromLocation entity 41470Ais of type GDT 41414 BusinessTransactionDocumentShipFromLocation 41474A.There is one or zero 41472A ShipFromLocation entity 41470A for eachLocation package 41444A. The ShipToLocation entity 41476A is of type GDT41414 BusinessTransactionDocumentShipToLocation 41480A. There is one41478A ShipToLocation entity 41476A for each Location package 41444A.

The TransshipmentLocation entity 41450E includes an InternalID 41456E, aStandardID 41462E, a VendorID 41466E, a ProductRecipientID 41472E, aNote 41478E, and an Address 41486E. The InternalID 41456E has zero orone occurrences 41458E and the name TransshipmentLocation 41460E. TheStandardID 41462E has any number of occurrences 41464E, and the name isLocationInternalID 41464E. The VendorID 41466E has zero or oneoccurrences 41468E and the name LocationStandardID 41470E. TheProductRecipientID 41472E has zero or one occurrences 41474E and thename LocationPartyID 41476E. The Note 41478E has zero or one occurrences41480E and the name LocationPartyID 41482E. The Address 41486E has zeroor one occurrences 41488E and the name Note 41490E.

The TransportInformation package 41446A includes a TransportMeans entity41482A and a TransportTracking entity 41488A. The TransportMeans entity41482A is of type GDT 41414 TransportMeans 41486A, and there is one orzero 41484A TransportMeans entity 41482A for each TransportInformationpackage 41446A. The TransportTracking entity 41488A is of type GDT 41414TransportTracking 41492A, and there is one or zero 41490ATransportTracking entity 41488A for each TransportInformation package41446A.

The ShipToLocation package 41476A includes an Address entity 41400F withzero or one occurrences 41402F and the name Address 41404F. The Locationpackage 41444A includes a FreightInvoice ID 41406F with zero or oneoccurrences 41408F and the name BusinessTransactionDocumentID 41410F.

The DeliveryInformation package 414048A includes an Incoterms entity41494A which is of type GDT 41414 Incoterms 41498A. There is one or zero41496A Incoterms entity 41494A.

The Item package 41450A includes an Item entity 41400B. There is one ormore 41402B Item entities 41400B for each Item package 41450A. The Itementity 41400B includes an ID 41406B, a ConsignmentIndicator 41412B, aGrossWeightMeasure 41418B, a NetWeightMeasure 41424B, a VolumeMeasure41430B, a Quantity 41436B, a DangerousGoodsIndicator 41442B, and a Note41448B. A CompletedIndicator entity 41417B with zero or one occurrences41419B and the name BusinessTransaction-CompletedIndicator 41421 B isalso included.

There is one or zero 41408B ID 41406B for each Item entity 41400B. TheID 41406B is of type GDT 41414 BusinessTransactionDocumentItemID41441410B. A ConsignmentIndicator 41412B has one or zero 41414Boccurrences and is of type GDT 41414 ConsignmentIndicator 41416B.GrossWeightMeasure 41418B has zero or one 41420B occurrences and is oftype GDT 41414 Measure 41422B. NetWeightMeasure 41424B has zero or one41426B occurrences and is of type GDT 41414 Measure 41428B.VolumeMeasure 41430B has zero or one 41432B occurrences and is of typeGDT 41414 Measure 41434B. Quantity 41436B has zero or one 41438Boccurrences and is of type GDT 41414 Quantity 41440B. DangerousGoods41442B has zero or one 41444B occurrences and is of type GDT 41414DangerousGoods 41446B. Note 41448B has zero or one 41450B occurrencesand is of type GDT 41418 Note 41452B.

The Item package 41450B also includes aBusinessTransactionDocumentReference package 41454B and aProductInformation package 41456B. TheBusinessTransactionDocumentReference package 41454B includes aPurchaseOrderReference entity 41458B. The PurchaseOrderReference entity41458B is of type GDT 41414 BusinessTransactionDocumentReference 41462B.There is one or zero 41460B PurchaseOrderReference entities 41458B foreach BusinessTransactionDocumentReference package 41454B. TheBusinessTransactionDocumentReference package 41454B includes aSchedulingAgreementReference entity 41464B. TheSchedulingAgreementReference entity 41464B is of type GDT 41414BusinessTransactionDocumentReference 41468B. There is one or zero 41466BSchedulingAgreementReference entities 41464B for eachBusinessTransactionDocumentReference package 41454B. TheBusinessTransactionDocumentReference package 41454B includes aSalesOrderReference entity 41470B. The SalesOrderReference entity 41470Bis of type GDT 41414 SalesOrderReference 41474B. There is one or zero41472B SalesOrderReference entities 41470B for eachBusinessTransactionDocumentReference package 41454B. AnOriginPurchaseOrderReference entity 41463B with zero or one occurrences41465B and the name BusinessTransactionDocumentReference 41467B is alsoincluded.

The Item package 41450A also includes a SerialID 41420F, aShippedQuantityAccumulation 41426F, a ReturnMaterialAuthorisationID41432F, a KanbanCardID 41438F, a PackingListID 41444F, and anOutstandingQuantity 41450F. The SerialID 41420F may have any number ofoccurrences 41422F and the name is SerialID 41424F. TheShippedQuantityAccumulation 41426F has zero or one occurrences 41428Fand the name ShippedQuantityAccumulation 41430F. TheReturnMaterialAuthorisationID 41432F has zero or one occurrences 41434Fand the name ReturnMaterial 41436F. The KanbanCardID 41438F has zero orone occurrences 41440F and the name AuthorisationID 41442F. ThePackingListID 41444F has zero or one occurrences 41446F and the nameKanbanCardID 41448F. The OutstandingQuantity 41450F has zero or oneoccurrences 41452F and the name Quanity 41454F.

The ProductInformation package 41456B includes a Product entity 41476Band a Batch entity 41418C. The Product entity 41476B is of type GDT41414 BusinessTransactionDocumentProduct 41480B. There is one or zero41478B Product entity 41476B for each ProductInformation package 41456B.There is one or zero 41420C Batch entity 41418C for eachProductInformation package 41456B.

The Product entity 41476B includes an InternalID 41482B, a StandardID41488B, a ShipperID 41494B, a ConsigneeID 41400C, a ChangeID 41406C, anda Note 41412C. The InternalID 41482B has zero or one 41484B occurrencesand a data type of CDT 41414 ProductInternalID 41486B. The StandardID41488B of the Product entity 41476B has zero or one 41490B occurrencesand has a data type of CDT 41414 ProductStandardID 41492B. The ShipperID41494B has zero or one 41496B occurrences and a data type of CDT 41414ProductPartyID 41498B. The ConsigneeID 41400C has zero or one 41402Coccurrences and a data type of CDT 41414 ProductPartyID 41404C. TheChangeID 41406C has zero or one 41408C occurrences and a data type ofCDT 41414 ProductChangeID 41410C. The Note 41412C has zero or one 41414Coccurrences and a data type of CDT 41414 Note 41416C.

The Batch entity 41418C includes an InternalID 41422C, a ShipperID41428C, a ConsigneeID 41434C, a ManufacuringDate 41440C, aBestBeforeDate 41446C, and a OriginCountryCode 41452C. The InternalID41422C has zero or one 41424C occurrences and has a data type of CDT41414 BatchID 41426C. The ShipperID 41428C has zero or one 41430Coccurrences and has a data type of CDT 41414 BatchID 41432C. TheConsigneeID 41434C has zero or one 41436C occurrences and has a datatype of CDT 41414 BatchID 41438C. The ManufacturingDate 41440C has zeroor one 41442C occurrences and a data type of CDT 41414 Date 41444C. TheBestBeforeDate 41446C has zero or one 41448C occurrences and a data typeof CDT 41414 Date 41450C. The OriginCountryCode 41452C has zero or one41454C occurrences and a data type of CDT 41414 CountryCode 41456C.

The HandlingUnit package 41458C includes a HandlingUnit entity 41460Chaving any number 41441441462C of occurrences and a data type 41414 ofHandlingUnit 41464C. The HandlingUnit package 41458C also includes aNetVolumeMeasure 41456F, a NetWeightMeasure 41462F, and a SerialID41468F. The NetVolumeMeasure 41456F has zero or one occurrences 41458Fand the name Measure 41460F. The NetWeightMeasure 41462F has zero or oneoccurrences 41464F and the name Measure 41466F. The SerialID 41468F haszero or one occurrences 41470F and the name SerialID 41472F.

(b) Received Delivery Notification

FIG. 415 depict the element structure for ReceivedDeliveryNotification.The element structure is similar to the data model, but providesadditional information regarding the details of the interface. Theelement structure identifies the different packages 41500 in theinterface, and represents the entities at various levels within theinterface. As depicted in FIGS. 415-415, the interface forReceivedDeliveryNotification includes five levels 41502, 41504, 41506,41508, and 41510. The element structure identifies the cardinality 41512between the entities of the interface, and provides information (i.e.,type 41514) regarding the data type that provides the basis for theentity. The outermost package of this interface is aReceivedDeliveryNotificationMessage package 41516, which includes aReceivedDeliveryNotificationMessage entity 41518 at the first level41502. The ReceivedDeliveryNotificationMessage entity 41518 is of typemessage data type (“MDT”) 41514 “ReceivedDeliveryNotificationMessage”41520 and there is one or zero 41541526 occurrences.

The ReceivedDeliveryNotificationMessage package 41516 includes aDelivery package 41522. The Delivery package 41522 includes a Deliveryentity 41524, a Party package 41542, Location package 41544, and an Itempackage 41546. There is one 41526 Delivery entity 41524 for eachDelivery package 41522. The Delivery entity 41524 includes an ID 41530,and a ReceiptDateTime 41536. There is one 41532 ID 41530 for eachDelivery entity 41524. The ID 41530 is of type GDT 41514BusinessTransactionDocumentID 41534. A ReceiptDateTime 41536 has one orzero 415 38 occurrences and is of type GDT 41514 DateTime 41540.

The Party package 41542 includes a VendorParty entity 41548 and aProductRecipientParty entity 41554. The VendorParty entity 41548 is oftype AGDT 41514 BusinessTransactionDocumentParty 41552. There is one41550 VendorParty entity 41548 for each Party package 41542. There isone 41556 ProductRecipientParty entity 41554 for each Party package41542. The ProductRecipientParty entity 41554 is of type AGDT 41514BusinessTransactionDocumentParty 41558.

The Location package 41544 includes a ShipToLocation entity 41560. TheShipToLocation entity 41560 is of type GDT 41514BusinessTransactionDocumentShipToLocation 41564. There is one or zero41562 ShipToLocation entities 41560 for each Location package 41544.

The Item package 41546 includes an Item entity 41566. There is anynumber 41568 of Item entities 41566 for each Item package 41546. TheItem entity 41566 includes an ID 41570, a CompletedIndicator 41576, anInventoryStatusDateTime 41582, and a ReceivedQuantity 41588.

There is one or zero 41572 ID 41570 for each Item package 41546. The ID41570 is of type GDT 41514 BusinessTransactionDocumentItemID 41574. ACompletedIndicator 41576 has one or zero 41578 occurrences and is oftype GDT 41514 BusinessTransactionCompleteIndicator 41580.InventoryStatusDateTime 41582 has zero or one 41584 occurrences and isof type GDT 41514 DateTime 41586. ReceivedQuantity 41588 has one 41590occurrence and is of type GDT 41514 Quantity 41592.

The Item package 41546 also includes a ProductInformation package 41594and a DeliveryInformation package 41596. The ProductInformation package41594 includes a Product entity 41598. The Product entity 41598 is oftype GDT 41514 BusinessTransactionDocumentProduct 41502A. There is one41500A Product entity 41598 for each ProductInformation package 41594.

The Product entity 41598 includes an InternalID 41504A, a StandardID41510A, a ShipperID 41516A, and a ConsigneeID 41522A. The InternalID41504A has zero or one 41506A occurrences and a data type of CDT 41514ProductInternalID 41508A. The StandardID 41510A of the Product entity41598 has zero or one 41541512A occurrences and has a data type of CDT41514 ProductStandardID 41514A. The ShipperID 41516A has zero or one41518A occurrences and a data type of CDT 41514 ProductPartyID 41520A.The ConsigneeID 41522A has zero or one 41524A occurrences and a datatype of CDT 41514 ProductPartyID 41526A.

The DeliveryInformation package 41596 includes a Variance entity 41528A.There is any number 41530A Variance entities 41528A. The Variance entity41528A includes a Quantity 41532A having one 41534A occurrence andhaving a type 41514 of Quantity 41536A. The Variance entity 41528Aincludes a QuantityDiscrepancyCode 41538A having one 41540A occurrenceand having a type 41514 of QuantityDiscrepancyCode 41542A.

r) Invoice Accounting Interface

The motivating business scenarios for the InvoiceAccountingNotificationinterface are Sell from Stock and Procure from Stock. After an vendorinvoice is checked in BAC Invoicing, a message is sent to BAC Accountingto update the payables to the vendors, the receivables from tax, and theexpenses. Similarly, when a billing document is sent in BAC Billing, amessage is sent to BAC Accounting to post the receivables from delivery,the payables from tax, and the revenues.

(1) Message Type Invoice Accounting Notification

An InvoiceAccountingNotification is a message for transferringinformation about incoming and outgoing payments from invoiceverification and billing to Accounting. The message typeInvoiceAccountingNotification is based on the message data typeInvoiceAccountingMessage.

The requirements from Accounting are fulfilled with the information inthe message. This includes: (1) Creation of an accounting document inthe relevant legal unit in accordance with generally accepted accountingprinciples; (2) Assigrnent of primary expenses and revenues inaccordance with the requirements of cost and revenue accounting; and (3)Linking the business transactions (purchase order/order with invoice) sothat, for example, audit requirements are met, but also, for example, sothat variances between the order value and the invoice value can bedetermined and forwarded to the cost object and profitability analysis.

(2) Message Choreography

FIG. 416 depicts the message choreography for an exemplary invoiceaccounting notification process. The receipt or sending of an invoice isposted accordingly in Accounting. The information required istransmitted by Invoicing/Billing 41602 using anInvoiceAccountingNotification message 41606 to Accounting 41604. Theinvoice can be reversed, even if this could be problematic from aprocess view (for example, if payment has already been received). Withan InvoiceAccountingCancellationRequest message 41608, in the case of aninvoice reversal, Accounting 41604 can request a complete cancellationof a previously sent InvoiceAccountingNotification message 41606.

(3) Message Data Type Invoice Accounting Message

FIG. 417 shows a data model for the Invoice Accounting Notification. Themessage data type InvoiceAccountingMessage includes theInvoiceAccountingMessage Package 41700 included in the business documentand the business information that is relevant for sending a businessdocument in a message. The InvoiceAccountingMessage package 41700includes a MessageHeader package 41702, an InvoiceAccounting package41704 and an InvoiceAccountingMessage entity 41706. The message datatype InvoiceAccountingMessage provides the structure for the messagetypes InvoiceAccountingNotification and the relevant interfaces.

(a) Message Header Package

The MessageHeader package 41702 groups the business information that isrelevant for sending a business document in a message. The MessageHeader41702 is not required for InvoiceAccountingMessage. An invoice or creditmemo is transferred to Accounting 41741704 once. A message ID is notrequired, since the reference can always be established with the ID ofthe invoice or credit memo. At most, the sender is known as the “systemID.” The recipient is not known. Invoicing and Billing 41702 know thatthis message is to be sent to the Accounting 41741704 application.

(b) Invoice Accounting Package

The InvoiceAccounting package 41704 summarizes all the invoice or creditmemo information relevant for Accounting. The InvoiceAccounting package41704 includes a Party Package 41708, aBusinessTransactionDocumentReference Package 41710, an Item Package41712 and an InvoiceAccounting entity 41714. There is a 1:1 relationship41716 between the InvoiceAccountingMessage entity 41706 and theInvoiceAccounting entity 41714.

InvoiceAccounting is the preparation of an invoice or credit memo forAccounting. For an invoice or credit memo uniquely identified as theunderlying business document, the InvoiceAccounting includes iteminformation about receivables and payables, taxes on sales andpurchases, and expenses and revenues. In addition, the business partnersinvolved are. named. In addition, the business partners involved arenamed.

The InvoiceAccounting entity 41714 includes an ID, a TypeCode, a Date,and a PostingDate. The ID is the Identification of the invoice or creditmemo, and is of type GDT: BusinessTransactionDocumentID. The TypeCode isthe type of invoice or credit memo. These are “101 VendorInvoice” for anincoming invoice or credit memo, and “102 Invoice” for an outgoinginvoice or credit memo. The differentiation between invoice and creditmemo is relevant at item level for Accounting. The TypeCode is of typeGDT: BusinessTransactionDocumentTypeCode. The Date is the invoice date,and is of type GDT: Date. The PostingDate is the date for which theinvoice or vendor invoice is relevant for Accounting. This element isoptional and has to be filled if this date is different to the invoicedate. The PostingDate is of type GDT: Date.

(c) Party Package

The Party package 41708 groups together the information relevant tobusiness partners affected by the invoice or vendor invoice. It includesa DebtorParty entity 41718 and a CreditorParty entity 41720. There is a1:1 relationship 41722 between the InvoiceAccounting entity 41714 andthe DebtorParty entity 41718. There is a 1:1 relationship 41724 betweenthe InvoiceAccounting entity 41714 and the CreditorParty entity 41720.

(i) Debtor Party

The DebtorParty entity 41718 (customer, debtor) is the owner ofpayables. The DebtorParty entity 41718 is of type GDT:BusinessTransactionDocumentParty, but includes the InternalID element.No other elements are required since the master data exists in thesender and receiver system to be able to operate correctly. TheDebtorParty entity 41718 is always filled.

For an vendor invoice or credit memo, the buying company (OrderingParty)is mapped in this business partner role. For an invoice or credit memo,the sold-to party is mapped in this business partner role.

(ii) Creditor Party

The CreditorParty entity 41720 (vendor, creditor) is the owner of thereceivables. The CreditorParty entity 41720 is of type GDT:BusinessTransactionDocumentParty, but includes the InternalID element.No other elements are required since the master data exists in thesender and receiver system to be able to operate correctly.CreditorParty is always filled.

For an vendor invoice or credit memo, the vendor is mapped in thisbusiness partner role. For an invoice or credit memo, the own billingunit is mapped in this business partner role.

(d) Business Transaction Document Reference Package

The BusinessTransactionDocumentReferencePackage 41710 is the groupstogether information relevent to references to the underlying businessdocuments for the invoice or vendor invoice that are relevant for allInvoiceAccountingItems. The BusinessTransactionDocumentReferencePackage41710 includes an OriginInvoiceReference entity 41726 and anOriginVendorInvoiceReference entity 41728. There is a 1:c relationship41730 between the InvoiceAccounting entity 41714 and theOriginInvoiceReference entity 41726. There is a 1:c relationship 41732between the InvoiceAccounting entity 41714 and theOriginVendorInvoiceReference entity 41728.

(i) Origin Invoice Reference

The OriginInvoiceReference 41726 is the reference to a previous invoiceto the DebtorParty entity 41718, and for which the current invoice orcredit memo is a follow-on document. The OriginInvoiceReference entity41726 is of type GDT: BusinessTransactionDocumentReference, but includesthe Element ID. The ItemID element is not required since reference ismade to the document and not to an item. The OriginInvoiceReferenceentity 41726 is filled if the current invoice or credit memo is afollow-on document for a previous invoice or credit memo. AnOriginInvoiceReference 41726 may be the original invoice number of acurrent credit memo.

(ii) Origin Vendor Invoice Reference

The OriginVendorInvoiceReference 41728 is the reference to a previousvendor invoice for which the current invoice or credit memo is afollow-on document. The OriginVendorInvoiceReference 41728 is of typeGDT: BusinessTransactionDocumentReference, but includes the Element ID.The ItemID element is not required since reference is made to thedocument and not to an item. The OriginVendorInvoiceReference 41728 isfilled if the current invoice or credit memo is a follow-on document foran vendor invoice or credit memo. An OriginVendorInvoiceReference may bethe original invoice number of a current credit memo.

(e) Invoice Accounting Item Package

The InvoiceAccountingItem package 41712 includes the informationrequired for creating the line items of the accounting document. Theseare receivables or payments from deliveries and services (DueItem),receivables and payables from taxes (TaxItem), and expenses or revenues(ExpenseRevenueItem). The InvoiceAccountingItem package 41712 includes aDueItem Package 41734, a TaxItem Package 41736, and anExpenseRevenueItem Package 41738.

The Item package 41712 belong to an invoice that may consist of severalitems. The total of all Items always balances to zero.

(f) Due Item Package

The DueItem package 41734 is the summary of all accounts receivable orpayable from deliveries and services that are listed in an invoice orcredit memo item. It includes a DueItem entity 41740. There is a 1:nrelationship 41742 between the InvoiceAccounting entity 41714 and theDueItem entity 41740.

The DueItem entity 41740 is the information relevant for Accountingabout receivables or payments from deliveries and services that arelisted in an invoice or credit memo item. The DueItem entity 41740includes an Amount, which is the invoice amount in transaction currency.Vendor invoices and credit memos (document type “101 VendorInvoice”) aretreated as payables, in other words a positive amount means increasedpayables and a negative amount means decreased payables. Invoices andcredit memos (document type “102 Invoice”) are treated as receivables,in other words a positive amount means increased receivables and anegative amount means decreased receivables. The DueItem entity 41740 isof type GDT: Amount.

There is usually exactly one DueItem entity 41740 that includes thetotal amount of the receivable or payable. In certain cases, severalDueItem entities 41740 may be transferred (Example, Retail: Vendorinvoice for drinks also includes a credit memo item for empties).

(g) Tax Item Package

The Taxitem package 41736 is the summary of all receivables or paymentsfrom taxes on sales and purchases that are listed in an invoice orcredit memo item. The TaxItem package 41736 includes a TaxItem entity41744. There is a 1:cn relationship 41741746 between theInvoiceAccounting entity 41714 and the TaxItem entity 41744.

The TaxItem entity 41744 is the information relevant for Accountingabout an account receivable or payable from taxes on sales and purchasesthat are listed in an invoice or credit memo item.

The TaxItem entity 41744 includes an Amount and aProductTaxEventTypeCode. The Amount is the tax amount in transactioncurrency. Vendor invoices and credit memos (document type “101VendorInvoice”) are receivables from the tax authorities, in otherwords, a positive amount means increased receivables and a negativeamount means decreased receivables. Invoices and credit memos (documenttype “102 Invoice”) are payables to the tax authorities, in other words,a positive amount means increased payables and a negative amount meansdecreased payables. The TaxItem entity 41744 is of type GDT: Amount.ProductTaxEventTypeCode is the taxable income that characterizes thecircumstances of the purchase, sale, or consumption of a product, and isof type GDT: ProductTaxEventTypeCode.

There does not have to be a TaxItem entity 41744, for example, if thebusiness transaction is not tax-relevant. However, there can be severalTaxItem entities 41744 if several types of tax on sales and purchases orseveral tax rates are determined (example: Sales tax in USA).

(h) Expense Revenue Item Package

The ExpenseRevenueItem package 41738 is the summary of all expenses orrevenues that are listed in an invoice or credit memo item. It includesan ExpenseRevenueItem entity 41754, anExpenseRevenueItemProductInformation Package 41748, anExpenseRevenueItemBusinessTransactionDocumentReference Package 41750,and an ExpenseRevenueItemAccountAssignment Package 41752. There is a 1:nrelationship 41756 between the InvoiceAccounting entity 41714 and theExpenseRevenueItem entity 41754.

(i) Expense Revenue Item

The ExpenseRevenueItem entity 41754 is the information relevant forAccounting about an expense or revenue that was listed in an invoice orcredit memo item. The ExpenseRevenueItem entity 41754 includes anAmount, a PriceComponentTypeCode, and a Quantity. The Amount is theamount in transaction currency. Vendor invoices and credit memos(document type “101 VendorInvoice”) are an expense, in other words, apositive amount means increased expenses and a negative amount meansdecreased expenses. Invoices and credit memos (document type “102Invoice”) are revenue, in other words, a positive amount means increasedrevenues and a negative amount means decreased revenues. TheExpenseRevenueItem entity 41754 is of type GDT: Amount. ThePriceComponentTypeCode is the type of amount: Basic price, freightcosts, discount, and is of type GDT: PriceComponentTypeCode. TheQuantity is the quantity ordered or sold, and is of type GDT: Quantity.

There is at least one ExpenseRevenueItem entity 41754. If the invoiceincludes several items with different materials (products) several Itemsare created. If the revenues or expenses are split further (example:Discount, freight, and so on), several Items are transferred.

(ii) Expense Revenue Item Product Information Package

The ExpenseRevenueItemProductInformation package 41748 is the summary ofall Accounting-relevant information from the item concerned about theproject. It includes a Product entity 41758. There is a 1:c relationshipbetween the ExpenseRevenueItem entity 41754 and the Product entity41758.

The Product entity 41758 identifies the goods or service that theinvoice item refers to. Product entity 41758 is of type GDT:BusinessTransactionDocumentProduct, but includes the InternalID element.No other elements are required since the master data exists in thesender and receiver system to be able to operate correctly.

(iii)Expense Revenue Item Business

Transaction Document Reference Package TheExpenseRevenueItemBusinessTransactionDocumentReference package 41750 isthe summary of all references to business documents that substantiatethe invoice or vendor invoice from the invoice item. TheExpenseRevenueItemBusinessTransactionDocumentReference package 41750includes a PurchaseOrderReference entity 41762 and a SalesOrderReferenceentity 41764. There is a 1:c relationship 41766 between theExpenseRevenueItem entity 41754 and the PurchaseOrderReference entity41762. There is a 1:c relationship 41768 between the ExpenseRevenueItementity 41754 and the SalesOrderReference entity 41764.

(a) Purchase Order Reference

The PurchaseOrderReference entity 41762 is the referenced order item inthe invoice item. The PurchaseOrderReference entity 41762 is of typeGDT: BusinessTransactionDocumentReference. In the GR/IR account, thePurchaseOrderReference entity 41762 is used to assign the vendor invoiceto the goods receipt.

(b) Sales Order Reference

The SalesOrderReference entity 41764 is the referenced sales order itemin the invoice item. SalesOrderReference entity 41764 is of type GDT:BusinessTransactionDocumentReference. In the goods issue/invoice issueaccount, the SalesOrderReference entity 41764 is used to assign theinvoice to the goods issue.

(iv) Expense Revenue Item Accounting Object Set Package

The ExpenseRevenueItemAccountingObjectSet package 41752 is the summaryof all account assignment information for the invoice item. It includesan AccountingObjectSet entity 41770. There is a 1:c relationship 41772between the ExpenseRevenueItem 41754 and the AccountingObjectSet entity41770.

Expenses or revenues from an invoice can be mapped with severaldifferent account assignments. For example, expenses for freight couldbe mapped to two different cost centers, 50% to each. However, thesending applications have to make this split; one account assignment canbe specified for each ExpenseRevenueItem.

The AccountingObjectSet entity 41770 includes the account assignmentobjects to which the expenses or revenues of the invoice item areassigned. The AccountingObjectSet entity 41770 is of type GDT:AccountingObjectSet.

(4) Message Data Type Element Structure

FIG. 418 depicts the element structure forInvoiceAccountingNotification. The element structure identifies thedifferent packages 41800 in the interface, and represents the entitiesat various levels within the interface. As shown in FIG. 418, theinterface for InvoiceAccountingNotification includes six levels 41802,41804, 41806, 41808, 41810, and 41812. The element structure identifiesthe number of occurrences 41814 of each element and provides a data type41816 and a data type name 41818 for each element.

The outermost package of this interface is InvoiceAccountingMessagepackage 41820, which includes a InvoiceAccountingMessage entity 41822 atthe first level 41802. The InvoiceAccountingMessage entity 41822 is ofdata type MDT 41824 named InvoiceAccountingMessage 41825.

The InvoiceAccountingMessage package 41820 includes a InvoiceAccountingpackage 41826. The InvoiceAccounting package 41826 includes a Partypackage 41868, a BusinessTransactionDocumentReference package 41870, anItem package 41872, and an InvoiceAccounting entity 41828 at the secondlevel 41804. The InvoiceAccounting entity 41828 has one occurrence 41830and is of data type AGDT 41832 named MessageHeader 41834. The InvoiceAccounting entity 41828 includes an ID 41836, a TypeCode 41844, a Date41852, and a PostingDate 41860 at the third level 41806. The ID 41836has one occurrence 41838 and is of data type BGDT 41840 with a data typename of BusinessTransactionDocumentID 41842. The TypeCode 41844 has oneoccurrence 41846 and is of a data type of BGDT 41848 with a data typename of BusinessTransactionDocumentTypeCode41850. The Date 41852 has oneoccurrence 41854 and is of data type BGDT 41856 with a data type name ofDate 41858. The PostingDate 41860 has zero or one occurrence and is ofdata type BGDT 41864 with a data type name of Date 41866.

The Party package 41868 includes a Debtor Party entity 41874 and aCreditorParty entity 41890 at the third level 41806. The DebtorPartyentity 41874 includes an InternalID 41882 at the fourth level 41808. TheDebtorParty entity 41874 has one occurrence 41876, and is of data type418AGDT 41878 with a data type name of BusinessTransactionDocumentParty41880. The InternalID 41882 has one occurrence 41884 and a data type ofBGDT 41886 with a data type name of PartyID 41888. The CreditorPartyentity 41890 also includes an InternalID 41892 at the fourth level41808. The CreditorParty 41890 has one occurrence 41892 and is of datatype AGDT 41894 with a data type name ofBusinessTransactionDocumentParty 41896. The InternalID 41898 has oneoccurrence 41800A with a data type of BGDT 41802A and a data type namePartyID 41804A.

The BusinessTransactionDocumentReference package 41870 includes anOriginInvoiceReference entity 41806A and an OriginVendorInvoiceReferenceentity 41822A at the third level 41806. The OriginInvoiceReferenceentity 41806A includes an ID 41814A at the fourth level 41808. TheOriginVendorInvoiceReference entity 41822A includes an ID 41830A at thefourth level 41808. The OriginInvoiceReference 41806A has zero or oneoccurrences 41808A and is of a data type AGDT 41810A with a data typename of BusinessTransactionDocumentReference 41812A. The ID 41814A hasone occurrence 41816A and is of data type BGDT 41818A with a data typename of BusinessTransactionDocumentID 41820A. TheOriginVendorInvoiceReference 41822A has zero or one occurrence 41824Aand is of data type AGDT 41826A with a data type name ofBusinessTransactionDocumentReference 41828A. The ID 41830A has oneoccurrence 41832A and is of data type BGDT 41834A with a data type nameof BusinessTransactionDocumentID 41836A.

The Item package 41872 includes a DueItem package 41840A, a TaxItempackage 41842A, an ExpenseRevenueItem 41844A, and an Item entity 41838Aat the third level 41806. The DueItem package 41840A includes a DueItementity 41846A at the fourth level 41808. The DueItem entity 41846Aincludes an Amount 41854A at the fifth level 41810. The DueItem 41846Ahas at least one occurrence 41848A and is of data type AGDT 41850A witha data type name of InvoiceAccountingDueItem 41852A. The Amount 41854Ahas one occurrence 41856A and is of data type BGDT 41858A with a datatype name of Amount 41860A.

The TaxItem package 41842A includes a TaxItem entity 41862A at thefourth level 41808. The TaxItem entity 41862A includes an Amount 41870Aand a ProductTaxEventTypeCode 41878A at the fifth level 41810. TheTaxItem entity 41862A has any number of occurrences 41864A and is of adata type AGDT 41866A with a data type name of InvoiceAccountingTaxItem41868A. The Amount 41870A has one occurrence 41872A and is of a datatype of BGDT 41874A with the data type name of Amount 41876A. TheProductTaxEventTypeCode 41878A has one occurrence 41880A and is of datatype BGDT 41882A with a data type name of ProductTaxEventTypeCode41884A.

The ExpenseRevenueItem 41844A includes a ProductInformation package41818B, a BusinessTransactionDocumentReference package 41820B, anAccountingObjectSet package 41822B, and an ExpenseRevenueItem entity41886A at the fourth level 41808. The Expense RevenueItem entity 41886Aincludes an Amount 41894A, a PriceComponentTypeCode 41802B, and aQuantity 41810B at the fifth level 41810. The ExpenseRevenueItem entity41886A has at least one occurrence 41888A and is of data type AGDT41890A with a data type name of InvoiceAccountingExpenseRevenueItem41892A. The Amount 41894A has one occurrence 41896A and is of data typeBGDT 41898A with a data type name of Amount 41800B. ThePriceComponentTypeCode 41802B has one occurrence 41804B and is of datatype BGDT 41806B with a data type name of PriceComponentTypeCode 41808B.The Quantity 41810B has zero or one occurrences 41812B and is of datatype BGDT 41814B with a data type name of Quantity 41816B.

The ProductInformation package 41818B includes a Product entity 41824Bat the fifth level 41810. The Product entity 41824B includes anInternalID 41832 at the sixth level 41812, which has one occurrence41834B and is of data type BGDT 41836B with a data type name ofProductID 41838B. The Product entity 41824B has zero or one occurrences41826B and is of data type BGDT 41828B with a data type name ofBusinessTransactionDocumentProduct 41830B.

The BusinessTransactionDocumentReference package 41820B includes aPurchaseOrderReference entity 41840B and a SalesOrderReference 41848B atthe fifth level 41810. The PurchaseOrderReference entity 41840B has zeroor one occurrences 41842B and is of data type AGDT 41844B with a datatype name of BusinessTransactionDocumentReference 41846B. TheSalesOrderReference 41848B has zero or one occurrences 41850B and is ofdata type AGDT 41852B with a data type name ofBusinessTransactionDocumentReference 41854B.

The AccountingObjectSet package 41822B includes an AccountingObjectSetentity 41856B at the fifth level 41810. The AccountingObjectSet entity41856B has zero or one occurrences 41858B and is of data type AGDT41860B with a data type name of AccountingObjectSet 41862B.

s) Delivery Execution Request

FIG. 419 depicts a graphical representation 41900 of aDeliveryExecutionRequest 41912 between business entities in accordancewith methods and systems consistent with the subject matter describedherein. The illustrative message choreography is a logical sequence ofmessages that is not dependent on actual scenarios. In theimplementation shown in FIG. 419, the illustrative business entitiesinclude an Ordering Application 41902, a Fulfillment Coordination 41904,and a Supply Chain Execution 41906. The request to supply chainexecution to carry out an action, or to make preparations to do so, canbe made in the form of a DeliveryExecutionRequest 41912 via FulfillmentCoordination or directly from the order entry system or purchase ordersystem. Deliveries to be executed or expected deliveries are created oradapted from a DeliveryExecutionRequest 41912. Interested applicationsare informed by DeliveryInformation 41914 that deliveries to be executedor expected deliveries have been created or changed.

Fulfillment Coordination 41904 is optional in this message choreography.Corresponding messages from the sales order system (such asSalesOrderFulfillmentRequest 41908 from CRM) can be mapped to theDeliveryRequest.

In a DeliveryExecutionRequest 41912, items and schedule lines may betransmitted with complete data at object level, i.e., if an item or aschedule line is transmitted, all data specified in the interface forthe item or schedule line must be transmitted.

In a DeliveryExecutionRequest 41912, the ActionCode may be used atheader level and at item level in order to display whether theDeliveryExecutionRequest 41912 or individual items are to be created,changed, or deleted. It is checked against the transmitted ActionCode.The CompleteTransmissionIndicator controls whether all items weretransmitted or explicitly changed items. If theCompleteTransmissionIndicator is set, the ActionCode may be set to“Create.” In this case, items not transmitted may be implicitly deleted.

A DeliveryExecutionConfirmation or aDeliveryExecutionFulfillmentNotification 41910 can be sent in order toinform the requesting system that a DeliveryExecutionRequest cannot beexecuted, cannot be executed in full, or that an incoming change cannotbe accepted and executed. It may be sufficient to transmit the detailsabout the delivery using the DeliveryInformation 41914, since therequesting system can decide itself, by means of completion rules orpartial delivery agreements, whether a retrospective change is stillbeing processed or has been processed.

Motivating business scenarios for the DeliveryExecutionRequest interfaceinclude “Sell From Stock” and “Procure To Stock.” In the “Sell fromStock” scenario, purchase orders are accepted from the customer andgenerate a request to Logistics to fulfill the order. In this scenario,the order is fulfilled by delivering the ordered goods to the customerfrom a goods warehouse. A delivery request to the relevant goodswarehouse is generated, which results in a delivery to be executed at aspecific time. In the “ProcureToStock” scenario, goods are ordered froma vendor. The purchase order or confirmation of the purchase order bythe vendor generates a request to Logistics to receive the goods on therequested or confirmed date and place them in storage. The vendor sendsan advanced shipping notification, which specifies further detailsregarding quantities and dates for the request to the warehouse.

A DeliveryExecutionRequest is a request to a warehouse or to supplychain execution to prepare and execute the outbound delivery of goods orthe receipt of a expected or announced inbound goods delivery. Thestructure of the message type DeliveryExecutionRequest is specified inthe message data type DeliveryExecutionRequestMessage.

In the case of outbound deliveries (sales orders or purchase orderreturns to a vendor), this message type represents a request to stagegoods and execute a delivery of particular products to a customer or avendor for a particular point in time. In the case of inbound deliveries(purchase orders to a vendor or returns by a customer), this messagetype represents a request to prepare for goods receipt at a particulardate and to accept and receive the goods. In the following relevantpassages, the term “delivery” refers to outbound as well as inbounddeliveries, i.e., the direction in which the goods flow is irrelevantfor the basic document, but it is controlled from the context of themessage by an indicator.

The message choreography describes the possible logical sequence inwhich different types of messages can appear. This choreography isindependent of the actual process or scenario.

The request to supply chain execution to carry out an action, or makepreparations to do so can be made in the form of aDeliveryExecutionRequest by Fulfillment Coordination or directly fromthe order entry system or purchase order system. Deliveries to beexecuted or expected deliveries are created or adapted from aDeliveryExecutionRequest. The interested applications are informed byDeliveryInformation that deliveries to be executed or expecteddeliveries have been created or changed. The corresponding messages fromthe sales order system (such as SalesOrderFulfillmentRequest from CRM)can be mapped to the DeliveryRequest.

In one implementation, in a DeliveryExecutionRequest, items and schedulelines are transferred with complete data at object level, i.e., if anitem or a schedule line is transferred, the data specified in theinterface for the item or schedule line has to be transferred. In aDeliveryExecutionRequest, the ActionCode is used at header and itemlevel in order to display whether the DeliveryExecutionRequest orindividual items are to be created, changed, or deleted. It is checkedagainst the transferred ActionCode. The CompleteTransmissionIndicatorcontrols whether items were transferred or explicitly changed items. Ifthe CompleteTransmissionIndicator is set, the ActionCode by definitionhas to be set to “Create.” In this case, items not transferred areimplicitly deleted.

In order to inform the requesting system that a DeliveryExecutionRequestcannot be executed, cannot be executed in full, or that an incomingchange cannot be accepted and executed, a DeliveryExecutionConfirmationor a DeliveryExecutionFulfillmentNotification can be sent. Initially, itis sufficient to transfer the details about the delivery using theDeliveryInfo, since the requesting system can decide itself by means ofcompletion rules or partial delivery arrangements if a retrospectivechange is still being processed or has been processed.

(1) Message Data Type Delivery Execution Request Message

The message data type DeliveryExecutionRequestMessage is included in aDelivery Execution Request Message package 42000. The Delivery ExecutionRequest Message package 42000 includes a DeliveryExecutionRequestMessageentity 42006, which is included in the business document and thebusiness information that is relevant for sending a business document ina message. The message data type DeliveryExecutionRequestMessageincludes a MessageHeader package 42002 and a DeliveryExecutionRequestpackage 42004. The message data type DeliveryExecutionRequestMessagemakes the structure available for the message typeDeliveryExecutionRequest and the relevant interfaces.

(a) Message Header Package

A MessageHeader package 42002 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader groups together the business information from the point ofview of the sending application to identify the business document in amessage, to provide information about the sender, and to provide anyinformation about the recipient.

The MessageHeader entity is divided into a SenderParty entity and aRecipientParty entity, and is of type GDT:BusinessDocumentMessageHeaderParty. The MessageHeader includes an ID anda CreationDateTime. The ID is the identification of the businessdocument in the technical message. The CreationDateTime is the creationdate of a business document in the technical message. A MessageHeader isnot required.

(b) Delivery Execution Request Package

The DeliveryExecutionRequest package 42004 groups together data forcreating an outbound or inbound delivery. It includes a Party package42008, a Location package 42010, a DeliveryInformation package 42012, aFollowUpMessage package 42014, an Attachment package 42016, aDescription package 42018, and an Item package 42020. TheDeliveryExecutionRequest package 42004 also includes aDeliveryExecutionRequest entity 42022. There is a 1:n relationship 42024between the DeliveryExecutionRequestMessage 42006 and theDeliveryExecutionRequest entity 42022.

The DeliveryExecutionRequest entity 42022 is a request to supply chainexecution (e.g., Logistics or the warehouse) to stage goods and todeliver them or prepare goods arrivals and receive incoming goods. Therequests to supply chain execution can be derived from sales orders orcustomer returns, purchase orders or returns to vendors, service ordersor the need to stage raw materials, semifinished and finished productsfor production. A DeliveryExecutionRequest entity 42022 operationincludes request items with the requested products, partners, locations,and schedule lines. This specifies when and where, and by whom productsare to be staged and delivered (from and to) and received.

The DeliveryExecutionRequest entity 42022 includes aBaseBusinessTransactionDocumentID, aBaseBusinessTransactionDocumentTypeCode, an ActionCode, aCreationDateTime, a LastChangeDateTime, and anItemListCompleteTransmissionIndicator. TheBaseBusinessTransactionDocumentID is an identifier of the base businessdocument for the DeliveryExecutionRequest, and is of type GDT:BusinessTransactionDocumentID. TheBaseBusinessTransactionDocumentTypeCode is a coded representation of thepreviously identified business document type, such as PurchaseOrder andSalesOrder, and is of type GDT: BusinessTransactionDocumentTypeCode. TheActionCode is a coded representation of the actions that controlcreating, changing, and deleting the requesting document at a messagerecipient, and is of type GDT: ActionCode. The CreationDateTime is thecalendar day and time on which the document was created, and is of typeGDT: DateTime. The LastChangeDateTime is the calendar day and time onwhich the document was changed, and is of type GDT: DateTime. TheItemListCompleteTransmissionIndicator is theItemListCompleteTransmissionIndicator specifies whether the items in thedocument are to be transmitted (items that are not transmitted areimplicitly classed as cancelled) or whether new, changed items that havebeen cancelled since the last transmission are to be transmitted, and isof type GDT: CompleteTransmissionIndicator. “Create,” “Change,” and“Delete” are permitted as ActionCodes.

(i) Party Package

The Party package 42008 groups together the business partners that canbe involved in a business delivery process. It includes a BuyerPartyentity 42026, a SellerParty entity 42028, a ProductRecipientParty entity42030, a VendorParty entity 42032, and a CarrierParty entity 42034. Adefault logic is used from the header to the items for businesspartners. Business partners specified at the header level are used forthe items for which a corresponding partner is not explicitlytransferred. The default logic is used for the partner as a whole,including the contact persons. In one implementation, parts of a partnerspecified at header level cannot be specified in more detail at itemlevel. The default logic is a simplified version of the transferredmessage. As regards logic, partners at header level behave as if theyhave been explicitly transferred for the items of the message. Changesto partners at header level are changes to the items for which thesepartners are valid.

In one implementation, either the ID or the ID and address can betransferred for each partner. If the ID is transferred, the addressdefined in the master data is used. If the ID and address aretransferred, the ID identifies the partner and the address is deemed tobe a document address that is different than the master data address.

The BuyerParty entity 42026 is the buying company or person. TheBuyerParty entity 42026 is of type GDT:BusinessTransactionDocumentParty. Initially, the internal ID serves asidentification, i.e., the InternalID has to and can be transferred. TheBuyerParty entity 42026 includes an Address entity 42046 and a Contactentity 42048. There is a 1:c relationship 42050 between the BuyerPartyentity 42026 and the Address entity 42046. There is also a 1:crelationship 42052 between the BuyerParty entity 42026 and the Contactentity 42048.

The Address entity 42046 includes a PersonName entity 42054, an Officeentity 42056, a PhysicalAddress entity 42058, a GeoCoordinates entity42060, and a Communication entity 42062. There is a 1:c relationship42064 between the Address entity 42046 and the PersonName entity 42054.There is a 1:c relationship 42066 between the Address entity 42046 andthe Office entity 42056. There is a 1:c relationship 42068 between theAddress entity 42046 and the PhysicalAddress entity 42058. There is a1:c relationship 42070 between the Address entity 42046 and theGeoCoordinates entity 42062. There is a 1:c relationship 42072 betweenthe Address entity 42046 and the Communication entity 42062.

The Contact entity 42048 includes an Address entity 42074. There is a1:c relationship 42076 between the Contact entity 42048 and the Addressentity 42074. The Address entity 42074 in the Contact entity 42048includes the same elements as the Address entity 42046 in the BuyerPartyentity 42026. For example, Address entity 42074 includes a PersonNameentity 42078, an Office entity 42080, a PhysicalAddress entity 42082, aGeoCoordinates entity 42084, and a Communication entity 42086. There isa 1:c relationship 42088 between the Address entity 42074 and thePersonName entity 42078. There is a 1:c relationship 42090 between theAddress entity 42074 and the Office entity 42080. There is a 1:crelationship 42092 between the Address entity 42074 and thePhysicalAddress entity 42082. There is a 1:c relationship 42094 betweenthe Address entity 42074 and the GeoCoordinates entity 42084. There is a1:c relationship 42096 between the Address entity 42074 and theCommunication entity 42086.

The SellerParty entity 42028 is the selling company. The SellerPartyentity 42028 is of type GDT: BusinessTransactionDocumentParty.Initially, the internal ID serves as identification, i.e., theInternalID can be transferred. The SellerParty entity 42028 includes thesame elements 42098 as the BuyerParty entity 42026.

The ProductRecipientParty 42030 is the company or person to which goodsare to be delivered. The ProductRecipientParty entity 42030 is of typeGDT: BusinessTransactionDocumentDocumentParty. In a delivery process insupply chain execution, the ShipToLocation is used as the deliveryaddress rather than the address of the ProductRecipientParty entity42030. Initially, the internal ID serves as identification, i.e., theInternaliD can be transferred. In one implementation, one part of theProductRecipientParty entity 42030 in the delivery process, however, isthe specified contact person for any queries relating to a delivery. TheProductRecipientParty entity 42030 includes the same elements 42000A asthe BuyerParty entity 42026.

The VendorParty entity 42032 is the company or person who is to delivergoods. The VendorParty entity 42032 is of type GDT:BusinessTransactionDocumentParty. In a delivery process in supply chainexecution, the ShipFromLocation is used as the delivery address ratherthan the address of the VendorParty entity 42032. Initially, theinternal ID serves as identification, i.e., the InternalID can betransferred. In one implementation, one part of the VendorParty entity42032 in the delivery process, however, is the specified contact personfor any queries relating to a delivery. The VendorParty entity 42032includes the same elements 42002A as the BuyerParty entity 42026.

The CarrierParty entity 42034 is the company or person that transportsthe goods. The CarrierParty entity 42034 is of type GDT:BusinessTransactionDocumentParty: Initially, the internal ID serves asidentification, i.e., the InternalID can be transferred. TheCarrierParty entity 42034 includes the same elements 42004A as theBuyerParty entity 42026.

(ii) Location Package

The Location package 42010 groups together the locations that can occurin a delivery process. It includes a ShipToLocation entity 42006A and aShipFromLocation entity 42008A. There is a 1:c relationship 42010Abetween the DeliveryExecutionRequest entity and the ShipToLocationentity 42006A. Similarly, there is a 1:c relationship 42012A between theDeliveryExecutionRequest entity 42022 and the ShipFromLocation entity42008A.

In one implementation, the Location package 42010 transfers either theID, the address, or both the ID and address for each location. If the IDis transferred, the system uses the address defined in the master data.If the address is transferred, the system uses this address (a locationmay be assigned at the address recipient). If the ID and address aretransferred, the ID identifies the location and the address is deemed tobe a document address that is different than the master data address.

The ShipToLocation entity 42006A and the ShipFromLocation entity 42008Acan be used to provide a detailed description of the flow of goodsbetween the ship-to and ship-from location. A default logic is used forlocations from the header to the items. Locations specified at headerlevel are valid for the items for which a corresponding location is notexplicitly transferred. The default logic applies for the location as awhole, including the contact persons. In one implementation, parts of alocation specified at header level are not specified more precisely atthe item level. The default logic is a simplified version of thetransferred message. Locations at the header level act as if they havebeen explicitly transferred for of the items of the message. Changes tothe locations at the header level are changes to the items that arevalid for this location.

The ShipToLocation entity 42006A is the location to which goods areshipped. The ShipToLocation entity 42006 is of type GDT:BusinessTransactionDocumentLocation. The ShipToLocation entity 42006A isthe delivery address. If the ShipToLocation entity 42006A is notspecified in the header of the Order package, it is specified at itemlevel in the Item package 42020 and vice versa. Initially, the internalID serves as identification, i.e., the InternalID can be transferred.The ShipToLocation entity includes an Address entity. There is a 1:crelationship 42016A between the ShipToLocation entity 42006A and theAddress entity 42014A. The Address entity 42014A includes a PersonNameentity 42018A, an Office entity 42020A, a PhysicalAddress entity 42022A,a GeoCoordinates entity 42024A and a Communication entity 42026A. Thereis a 1:c relationship 42028A between the Address entity 42014A and thePersonName entity 42018A. There is a 1:c relationship between theAddress entity 42014A and the Office entity. There is a 1:c relationship42032A between the Address entity 42014A and the PhysicalAddress entity42022A. There is a 1:c relationship 42034A between the Address entity42014A and the GeoCoordinates entity 42024A. There is a 1:c relationship42036A between the Address entity 42014A and the Communication entity42026A.

The ShipFromLocation entity 42008A is the location from which goods areshipped. The ShipFromLocation entity 42008A is of type GDT:BusinessTransactionDocumentLocation. Initially, the internal ID servesas identification, i.e., the InternalID can be transferred. TheShipFromLocation entity 42008A includes the same elements 42038A as theShipToLocation entity 42006A.

(iii) Delivery Information Package

The DeliveryInformation package 42012 groups together controllingdelivery parameters for one or more requested or announced deliveries ina delivery process. It includes a DeliveryTerms entity 42040A and aDeliveryControl entity 42042A. There is a 1:c relationship 42044Abetween the DeliveryExecutionRequest entity 42022 and the DeliveryTermsentity 42040A. There is a 1:c relationship 42046A between theDeliveryExecutionRequest entity and the DeliveryControl entity 42042A.

The DeliveryTerms entity 42040A is the conditions and agreements thatare to be valid for executing the delivery and transporting the orderedgoods and for the desired services and activities. The DeliveryTermsentity 42040 Ais of type GDT: DeliveryTerms. DeliveryTerms entity 42040Auses the default logic from the header to the items. Thus, items forwhich a deviating DeliveryTerm entity 42040A is not explicitlytransferred use the DeliveryTerms entity 42040A specified at headerlevel. The default logic is a simplified version of the transferredmessage. As regards logic, DeliveryTerms entity 42040A at the headerlevel behave as if they have been explicitly transferred for the itemsof the message. Changes to DeliveryTerms entity 42040A at header levelare changes to the items for which these DeliveryTerms entity 42040A arevalid.

The DeliveryTerms entity 42040A includes an Incoterms entity 42048A, aPartialDelivery entity 42050A, a QuantityTolerance entity, 42052A aTransport entity 42054A, and a Description entity 42056A. There is a 1:crelationship 42058A between the DeliveryTerms entity 42040A and theIncoterms entity. There is a 1:c relationship 42060A between theDeliveryTerms entity 42040A and the PartialDelivery entity 42050A. Thereis a 1:c relationship 42064A between the DeliveryTerms entity 42040A andthe QuantityTolerance entity 42052A. There is a 1:c relationship 42066Abetween the DeliveryTerms entity 42040A and the Transport entity 42054A.There is a 1:c relationship 42066A between the DeliveryTerms entity42040A and the Description entity 42056A.

The DeliveryControl entity 42042A is the set of internal controllingdelivery parameters for one or more requested deliveries in a deliveryprocess. The DeliveryControl entity 42042A is a structuring package andincludes a DeliveryBlockedIndicator, which is of type GDTBusinessTransactionBlockedIndicator, and an Indicator that indicateswhether the sales order or the sales order item has been blocked fordelivery.

DeliveryControl entity 42042A uses the default logic from the header tothe items. Thus, items for which a deviating DeliveryControl entity42042A is not explicitly transferred use the DeliveryControl entity42042A specified at header level. The default logic is a simplifiedversion of the transferred message. As regards logic, DeliveryControlentity 42042A at header level behaves as if it has been explicitlytransferred for the items of the message. Changes to DeliveryControlentity 42042A at header level are changes to the items for which thisDeliveryControl entity 42042A is valid. An example of a DeliveryControlentity 42042A is delivery block with blocking reason, such as creditlimit check.

(iv) Follow-Up Message Package

The FollowUpMessage package 42014 groups together the information thatdefines if or which types of follow-up messages are expected during thesubsequent process. It includes a FollowUpDespatchedDeliveryNotificationentity 42068A, a FollowUpBillingDueNotification entity 42070A, and aFollowUpInvoicingDueNotification entity 42072A. There is a 1:crelationship 42074A between the DeliveryExecutionRequest entity 42022and the FollowUpDespatchedDeliveryNotification entity 42068A. There is a1:c relationship 42076A between the DeliveryExecutionRequest entity42022 and the FollowUpBillingDueNotification entity 42070A. There is a1:c relationship 42078A between the DeliveryExecutionRequest entity42022 and the FollowUpInvoicingDueNotification entity 42072A. The factthat a follow-up message is expected does not mean that the requestingpartner of the delivery is informed or wants to be informed of thisfollow-up message.

The FollowUpDespatchedDeliveryNotification entity 42068A is informationabout how and if the buyer would like to be informed by the seller of adelivery and specifies if a advanced shipping notification (ASN) isexpected or is to be sent. The FollowUpDespatchedDeliveryNotificationentity 42068A includes a RequirementCode, which is a codedrepresentation of the type or the extent to which a follow-up message isexpected, and is of type GDT: FollowUpMessageRequirementCode. The sellercan transfer the confirmation of the outbound delivery eitherelectronically using a DespatchedDeliveryNotification message or bytraditional methods of communication, such as e-mail or fax. The values“Expected” and “Unexpected” are permitted for the RequirementCode.

The FollowUpBillingNotification entity 42070A is information aboutwhether an invoice is to be created during the subsequent process andwhether the delivery data is required for invoice creation. TheFollowUpBillingNotification entity 42070A includes a RequirementCode,which is a coded representation of the type or the extent to which afollow-up message is expected, and is of type GDT:FollowUpMessageRequirementCode. The values “Required” and “Forbidden”are permitted for the RequirementCode.

The FollowUplnvoicingNotification entity 42072A is information aboutwhether an invoice is expected during the subsequent process and if thedelivery data is desired for invoice verification. TheFollowUpInvoicingNotification entity 42072A includes a RequirementCode,which is a coded representation of the type or the extent to which afollow-up message is expected, and is of type GDT:FollowUpMessageRequirementCode. The values “Required” and “Forbidden”are permitted for the RequirementCode.

(v) Attachment Package

The Attachment package 42016 groups together the attachment informationregarding the requesting sales order. It includes anAttachmentWebAddress entity 42080A. There is a 1:cn relationship 42082Abetween the DeliveryExecutionRequest entity 42022 and theAttachmentWebAddress entity 42080A.

The AttachmentWebAddress entity 42080A refers to a web address for adocument of any type that is assigned to a DeliveryExecutionRequestentity 42022 as an attachment. The AttachmentWebAddress entity 42080A isof type GDT: WebAddress.

(vi) Description Package

The Description package 42018 groups together the explanatory textsregarding the sales order or the purchase order or the requestingdocument generally. It includes an InternalDescription entity 42084A anda Description entity 42086A. There is a 1:c relationship 42088A betweenthe DeliveryExecutionRequest entity 42022 and the InternalDescriptionentity 42084A. There is a 1:c relationship 42090A between theDeliveryExecutionRequest entity 42022 and the Description entity 42086A.

The InternalDescription entity 42084A is a natural-language textregarding the sales order or the purchase order. The InternalDescriptionentity 42084A is of type GDT: Description. The InternalDescriptionentity 42084A can be used for different types of textual informationabout the transferred sales order or the transferred purchase order andnot just the current message. It is intended for “internal” use and inone implementation, is not visible to external business partners.

A Description entity 42086A is a natural-language text regarding thesales order or the purchase order, which is visible to businesspartners. The Description entity 42086A is of type GDT: Description. TheDescription entity 42086A can be used for different types of textualinformation about the transferred sales order or the transferredpurchase order and not just the current message.

(vii) Delivery Execution Request Item Package

The DeliveryExecutionRequestItem package 42020 groups together the datathat describes the delivery type, quantity, and circumstances for aproduct to be delivered or received. It includes a ProductInformationpackage 42092A, a Batch package 42094A, a Party package 42096A, aLocation package 42098A, a DeliveryInformation package 42000B, anAttachment package 42002B, a Description package 42004B, and aScheduleLine package 42006B. The DeliveryExecutionRequestItem package42020 also includes a DeliveryExecutionRequestItem entity 42008B. Thereis a 1:n relationship 42010B between the DeliveryExecutionRequest entity42022 and the DeliveryExecutionRequestItem entity 42008B.DeliveryExecutionRequestItem entities 42008B are arranged hierarchicallyusing a Hierarchy Relationship entity 42012B. The Hierarchy Relationshipentity 42012B is the relationship between a sub-item and a higher-levelparent item in an item hierarchy.

DeliveryExecutionRequestItem entity 42008B is the part of a deliveryrequest that includes an actual product, quantities, and dates as wellas the location to which the product is to be delivered. TheDeliveryExecutionRequestItem entity 42008B includes aBaseBusinessTransactionDocumentitemID, aBaseBusinessTransactionDocumentItemTypeCode, an ActionCode, aCreationDateTime, a LastChangeDateTime, a HierarchyRelationship, and aScheduleLineListCompleteTransmissionIndicator.

The BaseBusinessTransactionDocumentItemID is an identifier of the itemin the base business document for the DeliveryExecutionRequest, and isof type GDT: BusinessTransactionDocumentItemID. TheBaseBusinessTransactionDocumentItemTypeCode is a coded representation ofthe previously identified item, and is of type GDT:BusinessTransactionDocumentItemTypeCode. The ActionCode is a codedrepresentation of the actions that control creating, changing, anddeleting the document items at a message recipient, and is of type GDT:ActionCode. The CreationDateTime is the calendar day and time when theitem was created, and is of type GDT: DateTime. The LastChangeDateTimeis the calendar day and time on which the item was changed, and is oftype GDT: DateTime. HierarchyRelationship includes a ParentItemld, whichis of type GDT BusinessTransactionDocumentItemID, and a TypeCode, whichis of type GDT BTDItemHierarchyRelationshipTypeCode. TheScheduleLineListCompleteTransmissionIndicator specifies whether theschedule lines in the document are to be transmitted (schedule linesthat are not transmitted are implicitly classed as cancelled) or whethernew, changed schedule lines that have been cancelled since the lasttransmission are to be transmitted, and is of type GDT:CompleteTransmissionIndicator.

The TypeCode classifies the base document item. From a semantic point ofview, items can recursively contain other items. Item hierarchies aremapped in this way. From a technical point of view, the item type isgenerally not defined recursively, since this may not be handled by somecommonly-used XML tools. The hierarchies are mapped using a ParentItemIDand an ItemHierarchyTypeCode.

The values “001” (Sales Order) and “002” (Purchase Order) are permittedas TypeCodes. The constraints in the GDTBusinessTransactionDocumentItemTypeCode in connection with theDeliveryExecutionRequestTypeCode are applicable here. “Create,”“Change,” and “Delete” are permitted as ActionCodes, since a hardsemantic may initially be required. If theItemListCompleteTransmissionIndicator is set, the ActionCode has to beset to “Create.”

(a) Delivery Execution Request Item Product Information Package

The DeliveryExecutionRequestItemProductInformation package 42092A groupstogether the information for identifying and describing a product in apurchase requisition item for Logistics. It includes a Product entity42018B. There is a 1:c relationship 42020B between theDeliveryExecutionRequestItem entity 42008B and theDeliveryExecutionRequestItemProduct entity 42018B.

The Product entity 42018B identifies and describes the product to bedelivered or the announced product. The Product entity 42018B is of typeGDT: BusinessTransactionDocumentProduct. Initially, the internal IDserves as identification, i.e., the InternalID can be transferred.

(b) Delivery Execution Request Item Batch Package

The DeliveryExecutionRequestItemBatch package 42094A groups together thebatch information for the product ordered in a purchase order item orsales order item. It includes a Batch entity 42022B. There is a 1:crelationship 42024B between the Item entity 42008B and the Batch entity42022B.

The Batch entity 42022B includes a batch and its properties. A batch isa partial quantity of a particular material and is a homogeneous,non-reproducible unit with particular specifications. The Batch entity42022B includes a BatchID, which is of type GDT: BatchID.

(c) Delivery Execution Request Item Party Package

The DeliveryExecutionRequestItemParty Package 42096A is similar to theParty package 42008 at the header level. It includes a BuyerParty entity42026B, a SellerParty entity 42028B, a ProductRecipientParty entity42030B, a VendorParty entity 42032B, and a CarrierParty entity 42034B.There is a 1:c relationship 42036B, 42038B, 42040B, 42042B and 42044B,respectively between the DeliveryExecutionRequestItem entity 42008B andthese entities. These entities have a 1:c relationship 42046B, 42048B,42050B, 42052B and 42054B respectively with the corresponding Addressentities.

(d) Delivery Execution Request Item Location Package

The Delivery Execution Request Item Location Package is similar to theLocation package at the header level. The Location package 42098Aincludes a ShipToLocation entity 42006A and a ShipFromLocation entity42008A. There is a 1:c relationship 42060B between theDeliveryExecutionRequestItem entity 42008B and the ShipToLocation entity42056B. Similarly, there is a 1:c relationship 42060B between theDeliveryExecutionRequestItem entity 42008B and the ShipFromLocationentity 42058B. These entities have a 1:c relationship 42064B, 42066B,respectively with the corresponding Address entities.

(e) Delivery Execution Request Item Delivery Information Package

The Delivery Execution Request Item Delivery Information Package 42000Bis similar to the DeliveryInformation package at the header level. Itincludes a DeliveryTerms entity 42068B and a DeliveryControl entity42070B. There is a 1:c relationship 42044A between theDeliveryExecutionRequestItem entity 42008B and the DeliveryTerms entity42040A. There is a 1:c relationship between theDeliveryExecutionRequestItem entity 42008B and the DeliveryControlentity 42070B.

(f) Delivery Execution Request Item Attachment Package

The Delivery Execution Request Item Attachment Package 42096B is similarto the Attachment package at the header level. It includes anAttachmentWebAddress entity 42096B. There is a 1:cn relationship 42002Bbetween the DeliveryExecutionRequestItem entity 42008B and theAttachmentWebAddress entity 42096B.

(g) Delivery Execution Request Item Description Package

The Delivery Execution Request Item Description Package 42004B issimilar to the Description package at the header level. It includes anInternalDescription entity 42000C and a Description entity 42002C. Thereis a 1:c relationship 42004C between the DeliveryExecutionRequestItementity 42008B and the InternalDescription entity 42000C. There is a 1:crelationship 42006C between the DeliveryExecutionRequestItem entity42008B and the Description entity 42002C.

(h) Delivery Execution Request Item Schedule Line Package

The DeliveryExecutionRequestItemScheduleLine package 42006B groupstogether the information about quantities and dates for a purchaserequisition item that are relevant for a request to Logistics. Itincludes a ScheduleLine entity 42008C and a ConfirmedScheduleLine entity42010C. There is a 1:n relationship 42012C between the Item entity42008B and the ScheduleLine entity 42008C. There is a 1:n relationship42014C between the Item entity 42008B and the ConfirmedScheduleLineentity 42010C.

The ScheduleLine entity 42008C is information about the deliveryquantities and various dates of the schedule expected by Sales orPurchasing in a DeliveryExecutionRequest entity 42022. The ScheduleLineentity 42008C includes an ID, an ActionCode, a Quantity, and aDeliveryDateTimePeriod. The ID is a key for a schedule line, and is oftype GDT ScheduleLineID. The ActionCode is a coded representation of theactions that control creating, changing, and deleting the schedule lineat a message recipient, and is of type GDT: ActionCode. The Quantity isthe required or expected quantity in the sales or order unit, and is oftype GDT: Quantity. The DeliveryDateTimePeriod is the (planned) deliveryperiod: expected or confirmed delivery date/time or delivery period, andis of type GDT: DateTimePeriod. “Create,” “Change,” and “Delete” arepermitted as ActionCodes, since initially a hard semantic may berequired. If ActionCodes are used, IDs are specified. If theScheduleLineListCompleteTransmissionIndicator is set, the ActionCode isset to “Create.” The ScheduleLine entity 42008C includes aDeliveryPeriod entity 42016C. There is a 1:c relationship 42018C betweenthe ScheduleLine entity and the DeliveryPeriod entity 42016C.

The ConfirmedScheduleLine entity 42010C is information about thedelivery quantities and various dates of the schedule expected by Salesor Purchasing in a DeliveryExecutionRequest entity 42022. TheConfirmedScheduleLine entity 42010C includes a DeliveryPeriod entity42020C. There is a 1:c relationship 42022C between theConfirmedScheduleLine entity 42010C and the DeliveryPeriod entity42020C.

(2) Element Structure

The message data type element structure for the DeliveryExecutionRequestmessage is depicted in FIG. 421. The element structure is similar to thedata model, but provides additional information regarding the details ofthe interface. The element structure identifies the different packages42100 in the interface, and represents the entities at various levelswithin the interface. As depicted in FIG. 421, the interface forDeliveryExecutionRequest includes five levels 42102, 42104, 42106,42108, and 42110. The outermost package of this interface is aDeliveryExecutionRequestMessage package 42116, which includes aDeliveryExecutionRequestMessage entity 42118 at the first level 42102.The DeliveryExecutionRequestMessage entity 42118 is of a type“DeliveryExecutionRequestMessage” 42120. TheDeliveryExecutionRequestMessage package 42116 includes a MessageHeaderpackage 42122 and a DeliveryExecutionRequest package 42124.

The MessageHeader package 42122 includes a MessageHeader entity 42126 atthe second level 42104. The MessageHeader entity 42126 is of a type“MessageHeader” 42130, and there is zero or one 42128 MessageHeaderentity 42126 for each MessageHeader package 42122.

The DeliveryExecutionRequest package 42124 includes one 42134DeliveryExecutionRequest entity 42132 at the second level 42104 and thefollowing packages: a Party package 42174, a Location package 42176, aDeliveryInformation package 42178, a FollowUpMessage package 42180, anAttachment package 42182, a Description package 42184, and aDeliveryRequestItem package 42186.

The DeliveryExecutionRequest entity 42132 includes aBaseBusinessTransactionID entity 42138, aBaseBusinessTransactionTypeCode entity 42144, an ActionCode entity42150, a CreationDateTime entity 42156, a LastChangeDateTime entity42162, and an ItemListCompleteTransmissionIndicator entity 42168. TheBaseBusinessTransactionID entity 42138 is of type“BusinessTransactionDocumentID” 42142, and there is one 42140BaseBusinessTransactionID entity 42138 for each DeliveryExecutionRequestentity 42132. The BaseBusinessTransactionTypeCode entity 42144 is oftype “BusinessTransactionDocumentTypeCode” 42148, and there is one 42146BaseBusinessTransactionTypeCode 42144 for each DeliveryExecutionRequestentity 42132. The ActionCode entity 42150 is of type “ActionCode” 42154,and there is zero or one 42152 ActionCode 42150 for eachDeliveryExecutionRequest entity 42132. The CreationDateTime entity 42156is of type “DateTime” 42160, and there is zero or one 42158CreationDateTime entity 42156 for each DeliveryExecutionRequest entity42132. The LastChangeDateTime entity 42162 is of type “DateTime” 42166,and there is zero or one 42164 LastChangeDateTime entity 42162 for eachDeliveryExecutionRequest entity 42132. TheItemListCompleteTransmissionIndicator entity 42168 is of type“CompleteTransmissionIndicator” 42172, and there is zero or one 42170ItemListCompleteTransmissionIndicator entity 42168 for eachDeliveryExecutionRequest entity 42132.

The Party package 42174 includes a BuyerParty entity 42188, aSellerParty entity 42124A, a ProductRecipientParty entity 42132A, aVendorParty entity 42140A, and a CarrierParty entity 42148A at the thirdlevel 42106.

The BuyerParty entity 42188 is of the type“BusinessTransactionDocumentParty” 42192, and there is one or zero 42190BuyerParty entity 42188 for each Party package 42174. The SellerPartyentity 42124A is of the type “BusinessTransactionDocumentParty” 42130A,and there is zero or one 42128A SellerParty entity 42124A for each Partypackage 42174. The ProductRecipientParty entity 42132A is of the type“BusinessTransactionDocumentParty” 42138A, and there is one or zero42136A ProductRecipientParty entity 42132A for each Party package 42174.The VendorParty entity 42140A is of the type“BusinessTransactionDocumentParty” 42146A, and there is zero or one42144A VendorParty entity 42140A for each Party package 42174. TheCarrierParty entity 42148A is of the type“BusinessTransactionDocumentParty” 42154A, and there is zero or one42152A CarrierParty entity 42148A for each Party package 42174.

The BuyerParty entity 42188 includes an InternalID entity 42194, anAddress entity 42100A, and a Contact entity 42106A at the fourth level42108. The InternalID entity 42194 is of the type “PartyInternalID”42198, and there is one 42196 InternalID entity 42194 for eachBuyerParty entity 42188. The Address entity 42100A is of the type“Address” 42104A, and there is zero or one 42102A Address entity 42100Afor each BuyerParty entity 42104A. The Contact entity 42106A is of thetype “BusinessTransactionDocumentContact” 42110A, and there is zero orone 42108A Contact entity 42106A for each BuyerParty entity 42188.

The Contact entity 42106A in BuyerParty entity 42188 includes anInternalID entity 42112A and an Address entity 42118A at the fifth level42110. The InternalID entity 42112A is of the type “PartyInternalID”42116A, and there is one 42114A InternalID entity 42112A for eachContact entity 42106A. The Address entity 42118A is of the type“Address” 42122A, and there is zero or one 42120A Address entity 42118Afor each Contact entity 42106A.

The SellerParty entity 42124A contains the same elements 42126A at thefourth level 42108 as found for the BuyerParty entity 42188.ProductRecipientParty entity 42132A contains the same elements 42134A atthe fourth level 42108 as found for the BuyerParty entity 42188.VendorParty entity 40A contains the same elements 42140A at the fourthlevel 42108 as found for the BuyerParty entity 42188. CarrierPartyentity contains the same elements 42148A at the fourth level 42108 asfound for the BuyerParty entity 42188.

The Location package 42176 includes a ShipToLocation entity 42156A and aShipFromLocation entity 42174A at the third level 42106. TheShipToLocation entity 42156A is of a type“BusinessTransactionDocumentLocation” 42160A, and there is one or zero42158A ShipToLocation 42156A for each Location package 42176. TheShipFromLocation entity 42174A is of a type“BusinessTransactionDocumentLocation” 42180A, and there is one 42178AShipFromLocation entity 42174A for each Location package 42176.

The ShipToLocation entity 42186A includes an InternalID entity 42162A,and an Address entity 42168A at the fourth level 42108. The InternalIDentity 42162A is of the type “LocationInternalID” 42166A, and there isone 42164A InternalID entity 42162A for each ShipToLocation entity42156A. The Address entity 42168A is of the type “Address” 42172A, andthere is zero or one 42170A Address entity 42168A for eachShipToLocation entity 42156A.

The ShipFromLocation entity 42174A contains the same elements 42176A atthe fourth level 42108 as found for the ShipToLocation entity 42156A.

The DeliveryInformation package 42178 includes a DeliveryTerms entity42182A and a DeliveryControl entity 42128B. There is one or zero 42184ADeliveryTerms entity 42182A for each DeliveryInformation package 42178.The DeliveryTerms entity 42182A is of type DeliveryTerms 42186A. TheDeliveryTerms entity 42182A includes a DeliveryItemGroupID entity 42188Awhich is of type BusinessTransactionDocumentItemGroupID 42192A and thereis one or zero occurrences 42190A. The DeliveryTerms entity 42182Aincludes a DeliveryPriorityCode 42194A which has one or zero occurrences42196A and a data type of BusinessTransactionPriorityCode 42198A. TheDeliveryTerms entity 42182A includes an IncoTerms 42100B which has oneor zero occurrences 42102B and a data type of IncoTerms 42104B. TheDeliveryTerms entity 42182A includes a PartialDelivery 42106B which hasone or zero occurrences 42108B and a data type of PartialDelivery42110B. The DeliveryTerms entity 42182A includes a QuantityTolerance42112B which has one or zero occurrences 42114B and a data type ofQuantityTolerance 42116B. The DeliveryTerms entity 42182A includes aTransport 42118B which has one or zero occurrences 42120B. TheDeliveryTerms entity 42182A includes a Description 42122B which has oneor zero occurrences 42124B and a data type of Description 42126B.

There is one or zero 42130B DeliveryControl entity 42128B for eachDeliveryInformation package 42178. The DeliveryControl entity 42128Bincludes a DeliveryBlockedIndicator 42132B which is of typeBusinessTransactionBlockedIndicator 42136B and there is one or zerooccurrences 42134B.

The FollowUpMessage package 42180 includes aFollowUpDespatchedDeliveryNotification entity 42138B, aFollowUpBillingDueNotification entity 42148B, and aFollowUpInvoicingDueNotification entity 42158B. There is zero or oneoccurrence 42140B of the FollowUpDespatchedDeliveryNotification entity.The FollowUpDespatchedDeliveryNotification entity 42138B includes aRequirementCode 42142B having one occurrence 42144B and having a datatype of FollowUpMessageRequirementCode 42146B. TheFollowUpBillingDueNotification entity 42148B has one or zero occurrences42150B. It includes a RequirementCode 42152B having one occurrence42154B and having a data type of FollowUpMessageRequirementCode 42156B.The FollowUplnvoicingDueNotification entity 42158B has one or zerooccurrences 42160B. It includes a RequirementCode 42162B having oneoccurrence 42164B and having a data type ofFollowUpMessageRequirementCode 42166B.

The Attachment package 42182 includes an AttachmentWebAddress entity42168B, which is of type WebAddress 42172B. There one or more 42170BAttachmentWebAddress entities 42168B for each Attachment 42182.

The Description package 42184 includes an InternalDescription entity42174B and a Description entity 42180B. The InternalDescription entity42174B is of type Description 42178B. There is one or zero 42176B ofInternalDescription entities 42174B for each Description package 42184.The Description entity 42180B is of type Description 42184B. There isone or zero 42182B Description entities 42180B for each Descriptionpackage 42184.

The DeliveryRequestItem package 42186 includes at least one 42188BDeliveryItem entity 42186B at the third level 42106, aProductInformation package 42144C, a Batch package 42146C, a Partypackage 42148C, a Location package 42150C, an Attachment package 42154C,a Description package 42156C, and a ScheduleLine package 42158C.

The Item entity 42186B includes a BaseBusinessTransactionID entity42192B, a BaseBusinessTransactionTypeCode entity 42198B, an ActionCodeentity 42104C, a CreationDateTime entity 42110C, a LastChangeDateTimeentity 42116C, a HierarchyRelationship entity 42122C and aScheduleLineListCompleteTransmissionIndicator entity 42138C. TheBaseBusinessTransactionID entity 42192B is of typeBusinessTransactionDocumentID 42196B, and there is one 42194CBaseBusinessTransactionID entity 42196B for each Item entity 42186B. TheBaseBusinessTransactionTypeCode entity 42198B is of type“BusinessTransactionDocumentTypeCode” 42102C, and there is one 42100CBaseBusinessTransactionTypeCode 42198B for each Item entity 42186B. TheActionCode entity 42104C is of type “ActionCode” 42108C, and there iszero or one 42106C ActionCode 42104C for each Item entity 42186B. TheCreationDateTime entity 42110C is of type “DateTime” 42114C, and thereis zero or one 42112C CreationDateTime entity 42110C for each Itementity 42186B. The LastChangeDateTime entity 42116C is of type“DateTime” 42120C, and there is zero or one 42118C LastChangeDateTimeentity 42116C for each Item entity 42186B. There is zero or one 42124CHierarchyRelationship entity 42122C for each Item entity 42186B.

The HierarchyRelationship entity 42122C includes a ParentItemID 42126Chaving one or zero occurrences 42128C and a data typeBusinessTransactionDocumentItemID 42130C. The HierarchyRelationshipentity 42122C includes a TypeCode 42132C having one occurrence 42134Cand a data typeBusinessTransactionDocumentItemHierarchyRelationshipTypeCode 42136C.

The ScheduleLineListCompleteTransmissionIndicator entity 42138C is oftype “CompleteTransmissionIndicator” 42142C, and there is zero or one42140C ScheduleLineListCompleteTransmissionIndicator entity 42138C foreach Item entity 42186B.

The ProductInformation package 42144C includes a Product entity 42160Cat the fourth level 42108. The Product entity 42160C is of a type“BusinessTransactionDocumentProduct” 42164C, and there is one 42162CProduct entity 42160C for each ProductInformation package 42144C.

The Product entity 42160C in the ProductInformation package 42144Cincludes an InternalID entity 42166C, and a Description entity 42172C.The InternalID entity 42166C is of a type “ProductInternalID” 42170C,and there is zero or one 42168C InternalID entity 42166C for eachProduct entity 42160C. The Description entity 42172C is of a type “Note”42176C, and there is zero or one 42174C Description entity 42172C foreach Product entity 42160C.

The Batch package 42146C includes a Batch entity 42178C at the fourthlevel 42108. The Batch entity 42178C is of a type “Batch” 42182C, andthere is zero or one 42180C Batch entity 42178C for each Batch package42146C. The Batch entity 42178C includes an ID entity 42184C at thefifth level 42110. The ID entity 42184C is of a type “BatchID” 42188C,and there is zero or one 42186C BatchID entity 42184C for each Batchentity 42178C.

The Party package 42148C includes a BuyerParty entity 42190C, aSellerParty entity 42198C, a ProductRecipientParty entity 42106D, aVendorParty entity 42114D, and a CarrierParty entity 42122D.

The BuyerParty entity 42190C is of the type“BusinessTransactionDocumentParty” 42196C, and there is one or zero42194C BuyerParty entity 42190C for each Party package 42148C. TheSellerParty entity 42198C is of the type“BusinessTransactionDocumentParty” 42104D, and there is zero or one42102D SellerParty entity 42198C for each Party package 42148C. TheProductRecipientParty entity 42106D is of the type“BusinessTransactionDocumentParty” 42112D, and there is one or zero42110D ProductRecipientParty entity 42106D for each Party package42148C. The VendorParty entity 42114D is of the type“BusinessTransactionDocumentParty” 42120D, and there is zero or one42118D VendorParty entity 42114D for each Party package 42148C. TheCarrierParty entity 42122D is of the type“BusinessTransactionDocumentParty” 42128D, and there is zero or one42126D CarrierParty entity 42122D for each Party package 42148C.

The BuyerParty entity 42190C contains the same elements 42192C at thefifth level 42110 as found in the fourth level 42108 for the BuyerPartyentity 42188. The SellerParty entity 42198C contains the same elements42100D at the fifth level 42110 as found in the fourth level 42108 forthe BuyerParty entity 42188. ProductRecipientParty entity 42106Dcontains the same elements 42108D at the fifth level 42110 as found inthe fourth level 42108 for the BuyerParty entity 42188. VendorPartyentity 42114D contains the same elements 42116D at the fifth level 42110as found in the fourth level 42108 for the BuyerParty entity 42188.CarrierParty entity 42122D contains the same elements 42124D at thefourth level 42108 as found for the BuyerParty entity 42188.

The Location package 42150C includes a ShipToLocation entity 42130D anda ShipFromLocation entity 42138D. The ShipToLocation entity 42130D is ofa type “BusinessTransactionDocumentLocation” 42136D, and there is one orzero 42134D ShipToLocation 42130D for each Location package 42150C. TheShipFromLocation entity 42138D is of a type“BusinessTransactionDocumentLocation” 42144D, and there is one 42142DShipFromLocation entity 42138D for each Location package 42150C.

The ShipToLocation entity 42130D contains the same elements 42132D atthe fifth level 42110 as found in the fourth level 42108 for theShipToLocation entity 42156A. The ShipFromLocation entity 42138Dcontains the same elements 42140D at the fifth level 42110 as found inthe fourth level 42108 for the ShipFromLocation entity 42174A.

The DeliveryInformation package 42152C includes a DeliveryTerms entity42146D and a DeliveryControl entity 42192D. There is one or zero 42148DDeliveryTerms entity 42146D for each DeliveryInformation package 42152Cand is of type DeliveryTerms 42150D. The DeliveryTerms entity 42146Dincludes a DeliveryItemGroupID entity 42152D which is of typeBusinessTransactionDocumentItemGroupID 42156D and there is one or zerooccurrences 42154D. The DeliveryTerms entity 42146D includes aDeliveryPriorityCode 42158D which has one or zero occurrences 42154D anda data type of BusinessTransactionPriorityCode 42162D. The DeliveryTermsentity 42146D includes an Incoterms 42164D which has one or zerooccurrences 42166D and a data type of Incoterms 42168D. TheDeliveryTerms entity 42146D includes a PartialDelivery 42170D which hasone or zero occurrences 42172D and a data type of PartialDelivery42174D. The DeliveryTemms entity 42146D includes a QuantityTolerance42176D which has one or zero occurrences 42178D and a data type ofQuantityTolerance 42180D. The DeliveryTerms entity 42146D includes aTransport 42182D which has one or zero occurrences 42184D. TheDeliveryTerms entity 42146D includes a Description 42186D which has oneor zero occurrences 42188D and a data type of Description 42190D.

There is one or zero 42194D DeliveryControl entity 42192D for eachDeliveryInformation package 52C. The DeliveryControl entity 42192Dincludes a DeliveryBlocked 42196D which is of typeBusinessTransactionBlockedIndicator 42100E and there is one or zerooccurrences 42198D.

The Attachment package 42154C includes an AttachmentWebAddress entity42102E. The AttachmentWebAddress entity 42102E is of the type“WebAddress” 42106E, and there is any number 42104E ofAttachmentWebAddress entities 42102E for each Attachment package 42154C.

The Description package 42156C includes an InternalDescription entity42108E and a Description entity 42114E. The InternalDescription entity42142008E is of type Description 42112E. There is one or zero 42110E ofInternalDescription entities 42108E. The Description entity 42114E is ofa type “Description” 42118E, and there is any number 42116E ofDescription entities 42114E for each Description package 42156C.

The ScheduleLine package 42158C includes a ScheduleLine entity 42120Ehaving an ID 42126E, ActionCode 42132E, Quantity 42138E, andDeliveryPeriod 42144E. The ScheduleLine entity 42120E has one or moreoccurrences 42122E and a data typeDeliveryExecutionRequestItemScheduleLine 42124E. The ID 42126E has oneoccurrence 42128E with a data type of ScheduleLineID 42138E. TheActionCode 42132E has one or zero occurrences 42134E with a data type ofActionCode 42136E. The Quantity 42138E has one occurrence 42140E with adata type of Quantity 42142E. The DeliveryPeriod 42144E has one or zerooccurrences 42146E with a data type of DateTimePeriod 42148E.

The ScheduleLine package 42158C includes a ConfirrnedScheduleLine entity42150E having an ID 42156E, ActionCode 42162E, Quantity 42168E, andDeliveryPeriod 42174E. The ConfirmedScheduleLine entity 42150E has zeroor more occurrences 42152E and a data typeDeliveryExecutionRequestItemScheduleLine 42154E. The ID 42156E has oneoccurrence 42158E with a data type of ScheduleLineID 42160E. TheActionCode 42162E has one or zero occurrences 42164E with a data type ofActionCode 42166E. The Quantity 42168E has one occurrence 42170E with adata type of Quantity 42172E. The DeliveryPeriod 42174E has one or zerooccurrences 42176E with a data type of DateTimePeriod 42178E.

t) Delivery Schedule Interface

The DeliveryScheduleNotification message—a “delivery schedule” is alsoreferred to as a “release”—is a tool that enables a buyer (sold-toparty) to send a vendor details of his or her product requirements fordeliveries in the short term and/or medium to long term. The liabilityof the deliveries can vary—from a binding purchase order, throughauthorization for production and/or material procurement release, to aforecast that is not binding. The delivery schedule refers to ascheduling agreement, that is, an outline agreement between the customerand vendor that sets out the conditions for purchase orders anddeliveries. The vendor uses the DeliveryScheduleConfirmation message toconfirm or reject the fulfillment of the product requirement transmittedin the delivery schedule for deliveries in the short term and/or mediumto long term.

A Release Processing business scenario describes how a manufacturer'spurchase orders are handled using delivery schedules. In this scenario,the manufacturer publishes the relevant delivery schedule on the“Inventory Collaboration Hub” for the vendor (supplier), who can view itover the Internet and can confirm it using theDeliveryScheduleConfirmation message. The vendor then uses the“DespatchedDeliveryNotification” to announce a delivery that is based onthe entire delivery schedule or one or more items in it. After the goodshave been received, the manufacturer can use the“ReceivedDeliveryNotification” message to confirm receipt of thedelivery to the vendor.

(1) Message Type

A DeliveryScheduleNotification is the notification from a buyer to avendor to notify the latter about the quantity of a product from ascheduling agreement item that is to be delivered with a certainliability on a certain date in accordance. The structure of the messagetype DeliveryScheduleNotification is specified in the message data typeDeliveryScheduleNotificationMessage. The legal liability for thedeliveries is specified by the ScheduleLineComittmentCode at scheduleline level in the message. Methods and systems consistent with thesubject matter herein use the package template for aBusinessTransactionDocument for an SCM Master Data depicted in FIG. 270Bto derive the DeliverySchedule interface.

A DeliveryScheduleConfirmation is the confirmation from a vendor to abuyer about what quantity of a product from a scheduling agreement itemis to be delivered and at what time. Changes to the delivery liabilitydefined by the buyer are not permitted. The structure of the messagetype DeliveryScheduleConfirmation is specified in the message data typeDeliveryScheduleConfirmationMessage.

(2) Message Choreography

FIG. 422 depicts the message choreography for an exemplaryDeliveryScheduleNotification process. The choreography involves twobusiness entities: a buyer (e.g., a manufacturer) 42202 and a vendor(e.g., a supplier) 42204. The buyer 42202 uses a delivery schedule(e.g., DeliveryScheduleNotification message 42206) to notify the vendor42204 about the buyer's 42202 replenishment requirements. The vendor42204 then has the option to send a purchase order confirmation(DeliveryScheduleConfirmation). The vendor then uses an advancedshipping notification (e.g. DespatchedDeliveryNotification message42208) to announce a delivery that is based on one or more schedulingagreement items. When the goods are received, the buyer 42202 mayconfirm receipt of the announced delivery to the vendor viaReceivedDeliveryNotification message 42210.

(3) Message Data Type Delivery Schedule Message

The data model for the message data type DeliveryScheduleMessagedepicted in FIG. 423 is used to implement a DeliveryScheduleNotificationmessage 42206 and a DeliveryScheduleConfirmation message. The messagedata type DeliveryScheduleMessage groups the business information thatis relevant for sending a business document in a message and theDeliverySchedule object in the business document. The message data typeDeliveryScheduleMessage includes a DeliveryScheduleMessage package42300. The DeliveryScheduleMessage 42300 includes a MessageHeaderPackage 42302, a DeliverySchedule Package 42304 and aDeliveryScheduleMessage entity 42306. The message data typeDeliveryScheduleMessage defines a template for the Deliver

(a) Message Header Package

The MessageHeader package 42302 groups the business information that isrelevant for sending a business document in a message. The MessageHeaderpackage 42302 includes a MessageHeader entity 42308. There is a 1:crelationship 42310 between the DeliveryScheduleMessage entity 42306 andthe MessageHeader entity 42308.

(i) Message Header

A MessageHeader package 42302 groups the business information from theperspective of the sending application to identify the business documentin a message, information about the sender, and information about therecipient. The MessageHeader entity 42308 includes a SenderParty entity42312 and a RecipientParty entity 42314. There is a respective 1:crelationship 42216 or 42218 between the MessageHeader entity 42208 andeach of the SenderParty entity 42308 and a RecipientParty entity 42310.The MessageHeader entity 42308 is of type GDT:BusinessDocumentMessageHeader. The MessageHeader entity 42308 includesan ID and a CreationDateTime. The ID is identification of the businessdocument in the message. The CreationDateTime is the creation date ofthe business document in the message.

(ii) Sender Party

The SenderParty entity 42312 is the party responsible for sending abusiness document at the business application level. The SenderPartyentity 42313 is of type GDT: BusinessDocumentMessageHeaderParty.

(iii) Recipient Party

The RecipientParty entity 42304 is the party responsible for receiving abusiness document at the business application level. The RecipientPartyentity 42314 is of type GDT: BusinessDocumentMessageHeaderParty.

(b) Delivery Schedule Package

The DeliverySchedule package 42304 summarizes data that describes thedelivery dates, products, quantities, and delivery locations. TheDeliverySchedule package 42304 includes a DeliverySchedule entity 42324,a Party package 42320, and a DeliveryScheduleItem package 42322.

(i) Delivery Schedule

The DeliverySchedule entity 42324 is a tool that is used by a customerto notify a vendor about the quantity of a material from a schedulingagreement item that is to be delivered and at what time. TheDeliverySchedule entity 42324 includes an ID, a TypeCode, aCreationDateTime, and a Note. The ID is a unique identifier for thedelivery schedule, and is of type GDT: BusinessTransactionDocumentID.The TypeCode is the coded representation of the type of a deliveryschedule, and is of type GDT: DeliveryScheduleTypeCode. TheCreationDateTime is the creation time of the delivery schedule, and isof type GDT: DateTime. The Note is a note for the delivery schedule, andis of type GDT: Note. There is a 1:1 relationship 42326 between theDeliveryScheduleMessage entity 42306 and the DeliverySchedule 42324.

(ii) Delivery Schedule Party Package

The Delivery Schedule Party Package 42320 is the grouping of thebusiness partners that may be relevant within the delivery schedule. TheDelivery Schedule Party Package 42320 includes a BuyerParty entity42328, a VendorParty entity 42330 and a BillToParty entity 42331. Thereis a 1:1 relationship between the DeliverySchedule entity 42324 and theBuyerParty entity 42328. There is a 1:c relationship 42334 between theDeliverySchedule entity 42324 and the VendorParty entity 42330. There isa 1:1 relationship 42335 between the DeliverySchedule entity 42324 andthe BillToParty entity 42331. In one implementation, the BillToParty,the Address and ContactPerson are not used in theDeliveryScheduleConfirmationMessage.

(a) Buyer Party

The BuyerParty entity 42328 is a party that buys goods or services. TheBuyerParty entity 42328 is of type GDT:BusinessTransactionDocumentParty, where the InternalID, the StandardID,the BuyerID, the VendorID Address and several Contact Persons are used.For intra-enterprise communication, the InternalID is used for partyentities. For intra-enterprise communication, party entities are usedfor either the StandardID or the partner-role-specific ID of thereceiving partner, in other words, the BuyerID is used for SupplierCollaboration scenarios, and the BuyerID is used for CustomerCollaboration scenarios. Due to the different possibilities for ID use,ID elements of the particular Party are optional. In one implementation,the address of the BuyerParty entity 42328 may not be intended to beused as the delivery address. In this implementation, the ShipToLocationis provided for this purpose.

(b) Vendor Party

VendorParty entity 42330 is the company or the person to deliver thegoods described in the delivery schedule. VendorParty entity 42330 is oftype GDT: BusinessTransactionDocumentParty, where the InternalID, theStandardID, the BuyerID, the VendorID, Address and several ContactPersons are used.

(c) BillToParty

BillToParty is the company or the person to be sent the invoice for thegoods ordered in the delivery schedule. The BillToParty entity 42331 isof type GDT: BusinessTransactionDocumentParty, whereby the InternalID,the StandardId, the BuyerID, the VendorID, and Address are used.

(iii) Delivery Schedule Item Package

The DeliveryScheduleItem package 42322 groups a DeliveryScheduleItem orItem entity 42348 with its packages. The DeliveryScheduleItem package42322 includes a BusinessTransactionDocumentReference package 42336, aRelease package 42338, a Party Package 42339 a Location Package 42340, aProductInformation Package 42342, a DeliveryInformation Package 42344,and a ScheduleLine Package 42346.

(a) Delivery Schedule Item

The DeliveryScheduleItem entity 42348 is a statement regarding therequirement for a specific product at a ship-to location with referenceto a scheduling agreement. There is a 1:cn relationship 42350 betweenDeliverySchedule entity 42324 and the DeliveryScheduleItem entity 42348.The DeliveryScheduleItem entity 42348 has the attribute actionCode, oftype GDT: ActionCode, which is a coded representation of an instructionto the message receipient as to how he or she should process the messageitem. DeliveryScheduleItem entity 42348 also includes an ID, aKanbanCardID, a ProductionAuthorizationPeriod, aPurchasingAuthorizationPeriod and a Note. The ID is the sequentialnumber for the item in the DeliverySchedule document, and is of typeGDT: BusinessTransactionDocumentItemID. The KanbanCardID is a uniqueidentifier for a replenishment or production signal that is sent from aconsumer to a supplier. It has a type of GDT: KanbanCardID. TheProductionAuthorizationPeriod is a Period in which the supplier islegally authorized by the buyer to product the finished products to bedelivered. It has a type of GDT: DateTimePeriod. ThePurchasingAuthorizationPeriod is a Period in which the supplier islegally authorized by the buyer to purchase the primary materials thatare needed to produce the finished products to e delivered. It has atype of GDT: DateTimePeriod. The Note is a note for the item in theDeliverySchedule, and is of type GDT: Note. In one implementation, theKanbanID, the ProductionAuthorizationPeriod and thePurchasingAuthorizationPeriod is not used in theDeliveryScheduleConfirmationMessage.

(b) Delivery Schedule Item Business Transaction Document ReferencePackage

The DeliveryScheduleItem BusinessTransactionDocumentReference package42336 groups references to business documents that are relevant for theDeliveryScheduleNotification message 42206. TheDeliveryScheduleItemBusinessTransactionDocumentReference package 42336includes a SchedulingAgreementReference entity 42356. There is a 1:1relationship 42358 between the DeliveryScheduleItem entity 42348 and theSchedulingAgreementReference entity 42356. TheSchedulingAgreementReference entity 42356 is the reference to an item ina scheduling agreement. SchedulingAgreementReference entity 42356 is oftype GDT: BusinessTransactionDocumentReference and should contain boththe scheduling agreement item and an ItemID.

(c) Release Package

The DeliveryScheduleItemRelease package 42338 groups the informationabout releases that are relevant for the DeliveryScheduleNotificationmessage 42206. The DeliveryScheduleItemRelease package 42338 includes aRelease entity 42360 and a PreviousRelease entity 42362. There is a 1:1relationship 42364 between the DeliveryScheduleItem entity 42348 and theRelease entity 42360 and a 1:1 relationship 42366 between thePreviousRelease entity 42362 and the DeliveryScheduleItem entity 42348.In one implementation, the PreviousRelease is not used in theDeliveryScheduleConfirmationMessage.

(i) Delivery Schedule Item Release

The Release entity 42360 is a statement about the identification andvalidity of a release instance transferred in a delivery schedule item.The Release entity 42360 includes an ID, a CreationDateTime, and aHorizonDateTime. The ID is an identifier for the release instancetransferred in the delivery schedule item. The ReleaseID is valid acrossmessages and is assigned for a release period, such as a fiscal year orquarter. The ReleaseID, therefore, does not identify a schedulingagreement item. The ID is of type GDT: BusinessTransactionDocumentID.The CreationDateTime is the creation date and time of the releaseinstance, and is of type GDT: DateTime. The HorizonDateTime is therelease horizon, that is, the end date of the release period, and is oftype GDT: DateTime.

(ii) Previous Release

The PreviousRelease entity 42362 is a statement about the identificationand validity of the last release instance previously transferred in adelivery schedule. The PreviousRelease entity 42362 includes an ID and aCreationDateTime. The ID is a unique identifier of the PreviousReleaseentity 42362, and is of type GDT: BusinessTransactionDocumentID. TheCreationDateTime is the Creation date and time of the PreviousReleaseentity 42362, and is of type GDT: DateTime.

(d) Delivery Schedule Item Party Package

The Party Package 42339 is a grouping of the business partners that maybe relevant within the delivery schedule. It contains the BuyerPartyentity 42392 and the ProductRecipientParty entity 43294. A BuyerPartyentity 42392 is a party that buys goods or services. The BuyerPartyentity 42392 is type GDT: BusinessTransactionDocumentParty, whereby theInternalID, the StandardID, the BuyerID, the VendorID, and Address areused. For intra-enterprise communication, use the InternalID for partyentities. For intra-enterprise communication, use for party entitieseither the StandardID or the partner-role-specific ID of the receivingpartner; in other words, use the BuyerID for Supplier Collaborationscenarios, and use the VendorID for Customer Collaboration scenarios.Due to different possibilities for ID use, ID elements of the particularparty are optional. In the case of BuyerParty, a default logic may existat header level for the items. This means that the buyerParty specifiedat header level is valid for items as long as the information specifiedat item level does not contradict this. The ProductRecipientParty entity43294 is the company or person who receives the goods delivery. TheProductRecipientParty entity 43294 is of type GDT:BusinessTransactionDocumentParty, whereby the InternalID, theStandardID, the BuyerID, the VendorID, and Address are used. Forintra-enterprise communication (with common master data), use InternalIDfor party entities. For intra-enterprise communication (withbusiness-partner-specific master data), use the StandardID or thepartner-role-specific ID of the receiving partner for party entities; inother words, use the Buyerld for Supplier Collaboration scenarios, anduse the VendorID for Customer Collaboration scenarios. Due to differentpossibilities for ID use, ID elements of the particular “Party” areoptional. There is a 1:c relationship 42376 between the BuyerPartyentity 42392 and the DeliveryScheduleItem entity 42348. There is a 1:1relationship 42378 between ProductRecipientParty entity 43294 and theDeliveryScheduleItem entity 42348.

(e) Location Package

The Location Package 42340 is a grouping of the locations that may berelevant within the delivery schedule. The Location package 42340includes a ShipFromLocation entity 42368, a TransshipmentLocation entity42370, and a ShipToLocation entity 42372. There is a 1:c relationship42374 between the DeliveryScheduleItem entity 42348 and theShipFromLocation entity 42368. There is a 1:c relationship 42376 betweenthe DeliveryScheduleItem entity 42348 and the TransshipmentLocationentity 42370. There is a 1:1 relationship 42378 between theDeliveryScheduleItem entity 42348 and the ShipToLocation entity 42372.For communication within an enterprise, the InternalID is used forlocation entities. For enterprisewide communication, location entitiesare used for either the StandardID or the partner-role-specific ID ofthe receiving partner. In other words, for Supplier Collaborationscenarios the BuyerID is used, and for Customer Collaboration scenarios,the VendorID is used. Due to the different possibilities for ID use, theID elements of the particular location are optional.

(i) Ship From Location

ShipFromLocation entity 42368 is the place from where the orderedproducts are delivered. ShipFromLocation entity 42368 is of type GDT:BusinessTransactionDocumentShipFromLocation, where the InternalID,StandardID, BuyerID, VendorID, and LoadingLocation and Address are used.For intra-enterprise communication, use the InternalID for locationentities. For inter-enterprise communication, use for location entitiesthe StandardID or the partner-role-specific ID of the sending orreceiving partner; in other words, the BuyerID or VendorID. Due todifferent poeeibilities for ID use, the ID elements of each location areoptional.

(ii) Transshipment Location

TransshipmentLocation entity 42370 is the location at which the orderedproducts are transshipped on their way to the product receipient.TransshipmentLocation entity 42370 is of type GDT:BusinessTransactionDocumentTransshipmentLocation, where the InternalID,StandardID, BuyerID, VendorID, and Address are used.

(iii) Ship To Location

ShipToLocation entity 42372 is the place to which the ordered productsare delivered. ShipToLocation entity 42372 is of type GDT:BusinessTransactionDocumentShipToLocation, where the InternalID,StandardID, BuyerID, VendorID, and UnloadingLocation and Address areused.

(f) Delivery Schedule Product Information Package

The DeliveryScheduleProductInformation package 42342 is a summary of theinformation that characterizes the product to be delivered in greaterdetail. The ProductInformation package 42342 includes a Product entity42380. There is a 1:1 relationship 42382 between theDeliveryScheduleItem entity 42348 and the product entity 42380. TheProduct entity 42380 is either a tangible or intangible good that is apart of the business activities of a company. The Product entity 42380may be traded and contributes directly or indirectly to value added. TheProduct entity 42380 is of type GDT: BusinessTransactionDocumentProduct,where the InternalID, the StandardID, the BuyerID, and the VendorID areused. For intra-enterprise communication, the InternalID is used forproduct entities. For inter-enterprise communication, product entitiesare used for either the StandardID or the partner-role-specific ID ofthe sending or the receiving partner; in other words, the BuyerID or theVendorID. Due to the different possibilities for ID use, ID elements ofeach particular product are optional.

(g) Delivery Schedule Item Delivery Information Package

The DeliveryInformation package 42344 summarizes the information aboutthe delivery schedule item. The DeliveryInformation package 42344includes a PreviousDelivery entity 42384 and a CumulativeDelivery entity42386. There is a respective 1:c relationship 42388 or 42390 between theDeliveryScheduleItem entity 42348 and each of the PreviousDeliveryentity 42384 and the CumulativeDelivery entity 42386. In oneimplementation, the PreviousDelivery and CumulativeDelivery are not usedin the DeliveryScheduleConfirmationMessage.

(i) Previous Delivery

PreviousDelivery entity 42384 includes data about the physical deliverythat was last received. PreviousDelivery entity 42384 include an ID, aReceivedQuantity, and a ReceiptDateTime. The ID is an identifier of thedelivery, and is of type GDT: BusinessTransactionDocumentID. TheReceivedQuantity is the quantity received, and is of type GDT: Quantity.The ReceiptDateTime is the time at which the delivery was received, andis of type GDT: DateTime.

(ii) Cumulative Delivery

CumulativeDelivery entity 42386 includes the cumulated quantities of thedeliveries for a product in the specified validity period.CumulativeDelivery entity 42386 includes a ValidityPeriod, aShippedQuantity a ReceivedQuantity, a ReconciliationDateTime, and aReconciliationQuantity. The ValidityPeriod is the validity period forthe cumulated delivery quantities, and is of type GDT: DateTimePeriod.The ShippedQuantity is a Cumulated shipped delivery quantity in thespecified validity period. This quantity is also referred to as thecumulative issued quantity. If the validity period is not specified, thecumulated quantity refers to the period in the referenced schedulingagreement item or to the current fiscal year. It is of type GDT:Quantity. The ReceivedQuantity is the cumulated received deliveryquantity in the specified validity period. This quantity is alsoreferred to as the cumulative received quantity. If a validity period isnot specified, the cumulated quantity refers to the period in thereferenced scheduling agreement item or to the current fiscal year, andis of type GDT: Quantity. The ReconciliationDateTime is the date andtime when the cumulative received quantity is reset or set to zero. Thisdate is also referred to as the reconciliation date. If theReconciliationDateTime is not specified, the agreed cumulative quantityrefers to the closing date/time of the fiscal year as specified in thereferenced scheduling agreement item. ReconciliationDateTime is of typeGDT: DateTime. The ReconciliationQuantity is the cumulated receivedquantity at the end of a delivery period in accordance with thedate/time specified in ReconciliationDateTime. This quantity (alsoreferred to as the agreed cumulative quantity) is used for informationpurposes and to provide legally binding synchronization for the deliveryquantities, that is, the goods receipts of the buyer party and the goodsissues of the vendor. ReconciliationQuantity is of type GDT: Quantity.

(h) Delivery Schedule Item Schedule Line Package

The DeliveryScheduleItemScheduleLine package 42346 is a collection ofone or more schedule lines for a delivery schedule item. TheDeliveryScheduleItemScheduleLine package 42346 includes aDeliveryScheduleItemScheduleLine entity 42352 and aDeliveryScheduleItemConfirmedScheduleLine 42353. There is a 1:cnrelationship 42354 between the DeliveryScheduleItem entity 42348 and theDeliveryScheduleItemScheduleLine entity 42352.

The DeliveryScheduleItemScheduleLine entity 42352 is a statement aboutthe quantity of a product to be delivered with a certain liabilitywithin a certain period of time. DeliveryScheduleItemScheduleLine entity42352 includes a CommittmentCode, a ProductChangeID, a DeliveryPeriod, aPickupPeriod, a Quantity, and a note. The CommittmentCode is the codedrepresentation that describes the planning significance of the scheduleline information and thus also specifies the (legal) liability withrespect to the ordered quantities and specified delivery dates for aproduct. CommittmentCode is of type GDT: ScheduleLineCommittmentCode.The ProductChangeID is an identifier of a change to a product that doesnot affect its features observed by a user. Since the ProductChangeIDcan vary between the different delivery dates, it is specified atschedule line level. ProductChangeID is of type GDT: ProductChangeID.The DeliveryPeriod is the period in which the product is to bedelivered, and is of type GDT: DateTimePeriod. The PickupPeriod is theperiod in which a product can or should be picked up from the vendor(for pickup scenarios), and is of type GDT: DateTimePeriod. The Quantityis the quantity of a product to be delivered or picked up, and is oftype GDT: Quantity. The Note is a note for the schedule line in theDeliveryScheduled document, and is of type GDT: Note. In oneimplementation, the ScheduleLine is not required in theDeliveryScheduleConfirmationMessage.

(i) Delivery Schedule Item Confirmed Schedule Line

ConfirmedScheduleLine is a confirmation from the vendor as to whichquantity of a product from a scheduling agreement item is deliveredwithin what time period. The DeliveryScheduleItemConfirmedScheduleLineentity contains a DeliveryPeriod, PickupPeriod and Quantity. TheDeliveryPeriod is a period in which the product is to be delivered, andis of type GDT: DateTimePeriod. PickupPeriod is a period in which aproduct can or should be picked up from the vendor (for pickupscenarios), and is of type GDT: DateTimePeriod. The Quantity is aquantity of a product to be delivered or picked up, and is of type GDT:Quantity. In one implementation, the ConfirmedScheduleLine is notrequired in the DeliveryScheduleNotificationMessage. TheConfirmedscheduleLine can contain different quantity and time values tothe original schedule line.

(4) Element Structure of Delivery Schedule Message

FIGS. 424A-U depicts the element structure for DeliveryScheduleMessage.The element structure is similar to the data model, but providesadditional information regarding the details of the interface. Theelement structure identifies the different packages 42400 in theinterface, and represents the entities at various levels within theinterface. As depicted in FIG. 424A, the interface forDeliveryScheduleMessage includes six levels 42402, 42404, 42406, 42408,42410, and 42412. The element structure identifies the occurrence orcardinality 42414 between the entities of the interface, and providesdata type information (i.e., G/CDT type 42416) regarding the data typethat provides the basis for the entity. The outermost package of thisinterface is a DeliveryScheduleMessage package 42424, which includes aDeliveryScheduleNotificationMessage entity 42422 at the first level42402. The DeliveryScheduleNotificationMessage entity 42422 is of type“DeliveryScheduleMessage” 42428.

The DeliveryScheduleMessage package 42424 includes a MessageHeaderpackage 42432 and a DeliverySchedule package 42434. The MessageHeaderpackage 42432 includes a MessageHeader entity 42436, which is of typegeneric data type “BusinessDocumentMessageHeader” 42440. There is one42438 MessageHeader entity 42436 for each DeliveryScheduleMessage entity42426.

The MessageHeader entity 42436 includes an ID 42446, a Reference ID42456, and a CreationDateTime 42466. The ID 42446 is of typeBusinessDocumentMessageID 42450. The CreationDateTime 42466 is of typeDateTime 42470. There is one 42448 ID 42446 for each MessageHeaderentity 42436, and one 42468 CreationDateTime 42466 for eachMessageHeader entity 42436.

The MessageHeader entity 42436 also includes a SenderParty entity 42474and a RecipientParty entity 42400A. The SenderParty entity 42474 is oftype BusinessDocumentMessageHeaderParty 42478. The RecipientParty entity42400A is also of type BusinessDocumentMessageHeaderParty 42404A. Thereis one or zero 42476 SenderParty entity 42474 for each MessageHeaderentity 42436, and there is one or zero 42402A RecipientParty entity42400A for each MessageHeader entity 42436.

The SenderParty entity 42474 includes an InternalID 42484 and aStandardID 42492. The InternalID 42484 has zero or one occurrences 42486for each SenderParty entity 42474 and a data type of PartyInternalID42488. The StandardID 42492 has zero or n occurrences 42494 for eachSenderParty entity 42474 and a data type of PartyStandardID 42496. TheRecipientParty entity 42400A includes an InternalID 42410A and aStandardID 42418A. The InternalID 42410A has zero or one occurrences 12Afor each Recipient Party 42400A and a data type of PartyInternalID42414A. The StandardID 42418A has zero or n occurrences 42420A for eachRecipient Party 42400A and a data type of PartyStandardID 42422A.

The DeliverySchedule package 42414A includes a DeliverySchedule entity42426A, a Party package 42462A, an Item package 42464A and a Note42486B. There is one or zero 42488B Note, and the Note 42486B is of typeNote 42490B. There is one 42428A DeliverySchedule entity 42426A for eachDeliveryScheduleNotificationMessage entity 42426. The DeliveryScheduleentity 42426A includes an ID 42434A, a TypeCode 42444A, and aCreationDateTime 42454A. There is one or zero 42436A ID 42434A for eachDeliverySchedule entity 42426A. The ID 42434A is of typeBusinessTransactionDocumentID 42438A. The TypeCode 42444A has zero orone 42446A occurrences for each DeliverySchedule entity 42426A and is oftype DeliveryScheduleTypeCode 42448AA. A CreationDateTime 42454A has oneoccurrence 42456A for each DeliverySchedule entity 42426A and is of typeDateTime 42458A.

The Party package 42462A includes a BuyerParty entity 42466A and aVendorParty entity 42426B. The BuyerParty 42466A is of typeBusinessTransactionDocumentParty 42466A. There is one or zero 42468ABuyerParty entity 42466A for each DeliverySchedule entity 42426A. TheVendorParty entity 42426B is of type BusinessTransactionDocumentParty42430B. There is one 42428B VendorParty entity 42426B for eachDeliverySchedule entity 42426A.

The BuyerParty entity 42466A includes an InternalID 42476A, a StandardID42486A, a BuyerID 42496A, a VendorID 42406B, an Address 42416B, and aContactPerson 42480H. The InternalID 42476A has zero or one occurrences42478A for the BuyerParty entity 42466A and a data type ofPartyInternalID 42480A. The StandardID 42486A has zero or n occurrences42488A for the BuyerParty entity 42466A and a data type ofPartyStandardID 42490A. The BuyerID 42496A has zero or one occurrences42498A for the BuyerParty entity 42466A and a data type of PartyPartyID42400B. The VendorID 42406B has zero or one occurrences 42408B for theBuyerParty entity 42466A and a data type of PartyPartyID 42410B. TheAddress 42416B has zero or one occurrences 42418B for each BuyerPartyentity 42466A and a data type of Address 42420B. The ContactPerson42480H has zero to n occurrences 42482H for the BuyerParty entity 42466Aand a data type of ContactPerson 42484H. The ContactPerson 42480Hincludes an InternalID 42486H, a BuyerID 42492H, a VendorID 42498H andan Address 42404I. The InternalID 42486H has zero or one occurrences42488H for the ContactPerson 42480H and a data type ofContactPersonInternalID 42490H. The BuyerID 42492H has zero or oneoccurrences 42494H for the ContactPerson 42480H and a data type ofContactPersonPartyID 42496H. The VendorID 42498H has zero or oneoccurrences 42400I for the ContactPerson 42480H and a data type ofContactPersoPartyID 42402I. The Address 42404I has zero or oneoccurrences 42406I for the ContactPerson 42480H and a data type ofAddress 42408I.

The VendorParty entity 42426B includes an InternalID 42436B, aStandardID 42446B, a BuyerID 42456B, a VendorID 42466B, an Address42476B, and a ContactPerson 42410I. The InternalID 42436B has zero orone occurrences 42438B for the VendorParty entity 42426B and a data typeof PartyInternalID 42440B. The StandardID 42446B has zero or noccurrences 42448B for the VendorParty entity 42426B and a data type ofPartyStandardID 42450B. The BuyerID 42456B has zero or one occurrences42458B for the VendorParty entity 42426B and a data type of PartyPartyID42460B. The VendorID 42466B has zero or one occurrences 42468B for theVendorParty entity 42426B and a data type of PartyPartyID 42470B. TheAddress 42476B has zero or one occurrences 42478B for the VendorPartyentity 42426B and a data type of Address 42480B. The ContactPerson42410I has zero to n occurrences 42412I for the BuyerParty entity 42466Aand a data type of ContactPerson 42414I. The ContactPerson 42410Iincludes an InternalID 42416I, a BuyerID 42422I, a VendorID 42428I andan Address 42434I. The InternalID 42416I has zero or one occurrences42418I for the ContactPerson 42420I and a data type ofContactPersonInternalID 42420I. The BuyerID 42422I has zero or oneoccurrences 42424I for the ContactPerson 42480H and a data type ofContactPersoPartyID 42426I. The VendorID 42428I has zero or oneoccurrences 42430I for the ContactPerson 42480H and a data type ofContactPersonPartyID 42432I. The Address 42434I has zero or oneoccurrences 42036I for the ContactPerson 42480H and a data type ofAddress 42438I.

The BillToParty entity 42440I includes an InternalID 42446I, aStandardID 42454I, a BuyerID 42462I, a VendorID 42470I, and an Address42478I. The InternalID 42446I has zero or one occurrences 42448I for theBillToParty entity 42440I and a data type of PartyInternalID 42450I. TheStandardID 42454I has zero or n occurrences 42456I for the BillToPartyentity 42440I and a data type of PartyStandardID 42458I. The BuyerID42462I has zero or one occurrences 42464I for the BillToParty entity42440I and a data type of PartyPartyID 42466I. The VendorID 42470I haszero or one occurrences 42472I for the BillToParty entity 42440I and adata type of PartyPartyID 42474I. The Address 42478I has zero or oneoccurrences 42480I for the BillToParty entity 42440I and a data type ofAddress 42482I.

The Item package 42464A includes an Item entity 42496B. There is one ormore 42498B Item entities 42496B for each DeliverySchedule entity42426A. The Item entity 42496B is of type DeliveryScheduleItem 42400C.The Item entity 42496B includes a @actionCode 42404C, and an ID 42414C.The @actionCode 42404C is of type ActionCode 42404C, and there is one orzero 42406C @actionCode 42404C for each Item entity 42496B. The ID42414C is of type BusinessTransactionDocumentItemID 42418C, and there isone 42416C ID 42414C for each Item entity 42496B.

The Item package 42464A also includes a Note entity 42468H, aKanBanCardID entity 42474J, a ProductAuthorizationPeriod entity 42482J,and a PurchasingAuthorizationPeriod 42488J. The Note entity 42468H is ofdata type Note 42472H. There is zero or one 42470H Note entity 42468Hfor each Item entity 42496B. The KanBanCardID entity 42474J is of datatype KanBanCardID 42478J. There is zero or one 42476J KanBanCardIDentity 42474J for each Item entity 42496B. TheProductAuthorizationPeriod entity 42482J is of data type DateTimePeriod42486J. There is zero or one 42484J ProductAuthorizationPeriod entity42482J for each Item entity 42496B. The PurchasingAuthorizationPeriod42488J is of data type DateTimePeriod 42492J. There is zero or one42490J PurchasingAuthorizationPeriod 42488J for each Item entity 42496B.

The Item package 42464A also includes aBusinessTransactionDocumentReference package 42424C, a Release package42426C, a Location package 28C, a ProductInformation package 42430C, aDeliveryInformation package 42432C, a ScheduleLine package 42434C and aPartyPackage 42472J.

The BusinessTransactionDocumentReference package 42424C includes aSchedulingAgreementReference entity 42436C of typeBusinessTransactionDocumentReference 42440C. There is one 42438CSchedulingAgreementReference entity 42436C for each Item entity 42496B.

The PartyPackage 42472J includes a BuyerParty entity 42484I, and aProductRecipientParty entity 42428J. There is zero to one 42486IBuyerParty entity 42484I for each Item entity 42496B. The BuyerPartyentity 42484I is of type BusinessTransactionDocumentParty 42488I. TheBuyerParty entity 42484I includes an InternalID 42490I, a StandardID42498I, a BuyerID 42406J, a VendorID 42414J, and an Address 42422J. TheInternalID 42490I has zero or one occurrences 42492I for the BuyerPartyentity 42484I and a data type of PartyInternalID 42494I. The StandardID42498I has zero or n occurrences 42400J for the BuyerParty entity 42484Iand a data type of PartyStandardID 42402J. The BuyerID 42406J has zeroor one occurrences 42408J for the BuyerParty entity 42484I and a datatype of PartyPartyID 42410J. The VendorID 42414J has zero or oneoccurrences 42416J for the BuyerParty entity 42484I and a data type ofPartyPartyID 42418J. The Address 42422J has zero or one occurrences42424J for the BuyerParty entity 42484I and a data type of Address42426J. There is zero to one 42430J ProductRecipientParty entity 42428Jfor each Item entity 42496B. The ProductRecipientParty entity 42428J isof type BusinessTransactionDocumentParty 42432J. TheProductRecipientParty entity 42428J includes an InternalID 42434J, aStandardID 42442J, a BuyerID 42450J, a VendorID 42458J, and an Address42466J. The InternalID 42434J has zero or one occurrences 42436J for theProductRecipientParty entity 42428J and a data type of PartyInternalID42438J. The StandardID 42442J has zero or n occurrences 42444J for theProductRecipientParty entity 42428J and a data type of PartyStandardID42446J. The BuyerID 42450J has zero or one occurrences 42452J for theProductRecipientParty entity 42428J and a data type of PartyPartyID42454J. The VendorID 42458J has zero or one occurrences 42460J for theProductRecipientParty entity 42428J and a data type of PartyPartyID42462J. The Address 42466J has zero or one occurrences 42468J for theProductRecipientParty entity 42428J and a data type of Address 42470J.

The Release package 42426C includes a Release entity 42444C, and aPreviousRelease entity 42476C. There is one 42446C Release entity 42444Cfor each Item entity 42496B. The Release entity 42444C includes an ID42450C, a CreationDataTime 42460C and a HorizonDataTime 42468C. The ID42450C is of type BusinessDocumentMessageID 42454C. The CreationDataTime42460C is of type DateTime 42464C. The HorizonDataTime 42468C is of typeDateTime 42472C. There is one 42452C ID 42450C for each Item entity42496B, one or zero 42462C CreationDataTime 42460C for each Item entity42496B, and one or zero 42470C HorizonDataTime 42468C for each Itementity 42496B. The PreviousRelease entity 42476C includes an ID 42482C,and a CreationDataTime 42492C. The ID 42482C is of typeBusinessDocumentMessageID 42486C. The CreationDataTime 42492C is of typeDateTime 42496C. There is one 42484C ID 42482C for each Item entity42496B, and one or zero 42494C CreationDataTime 42492C for each Itementity 42496B.

The Location package 42428C includes a ShipFromLocation entity 42400D,and a TransshipmentLocation entity 42410E, and a ShipToLocation entity42470E. The ShipFromLocation entity 42400D is of typeBusinessTransactionDocumentShipFromLocation 42404D. There is one or zero42402D ShipFromLocation entity 42400D for each Item entity 42496B. TheTransshipmentLocation entity 42410E is of type ofBusinessTransactionDocumentTransshipmentLocation 42414E. There is one orzero 42412E TransshipmentLocation entity 42410E for each Item entity42496B. The ShipToLocation entity 42470E is of typeBusinessTransactionDocumentLocation 42474E. There is one 42472EShipToLocation entity 42470E for each Item entity 42496B.

The ShipFromLocation entity 42400D includes an InternalID 42410D, aStandardID 42420D, a BuyerID 42430D, a VendorID 42440D, aLoadingLocation entity 42450D, and an Address 42400E. The InternalID42410D has zero or one occurrences 42412D for the ShipFromLocationentity 42400D and a data type of LocationInternalID 42414D. TheStandardID 42420D has zero or n occurrences 42422D for theShipFromLocation entity 42400D and a data type of LocationStandardID42424D. The BuyerID 42430D has zero or one occurrences 42432D and a datatype of LocationPartyID 42434D. The VendorID 42440D has zero or oneoccurrences 42442D for the ShipFromLocation entity 42400D and a datatype of LocationPartyID 42444D. The LoadingLocation entity 42450D haszero or one occurrences 42452D for the ShipFromLocation entity 42400Dand a data type of BusinessTransactionDocumentLocation 42454D. TheAddress 42400E has one or zero occurrences 42402E for theShipFromLocation entity 42400D and a data type of Address 42404E. TheLoadingLocation entity 42450D includes an InternalID 42460D, aStandardID 42470D, a BuyerID 42480D, and a VendorID 42490D. TheInternalID 42460D has zero or one occurrences 42462D for eachLoadingLocation entity 42450D and a data type of LocationInternalID42464D. The StandardID 42470D has zero or one occurrences 42472D foreach LoadingLocation entity 42450D and a data type of LocationStandardID42474D. The BuyerID 42480D has zero or one occurrences 42482D for eachLoadingLocation entity 42450D and a data type of LocationPartyID 42484D.The VendorID 42490D has zero or one occurrences 42492D for eachLoadingLocation entity 42450D and a data type of LocationPartyID 42494D.

The TransshipmentLocation entity 42410E includes an InternalID 42420E, aStandardID 42430E, a BuyerID 42440E, a VendorID 42450E and an Address42460E. The InternalID 42420E has zero or one occurrences 42422E foreach TransshipmentLocation entity 42410E and a data type ofLocationInternalID 42424E. The StandardID 42430E has zero or noccurrences 42432E for each TransshipmentLocation entity 42410E and adata type of LocationStandardID 42434E. The BuyerID 42440E has zero orone occurrences 42442E for each TransshipmentLocation entity 42410E anda data type of LocationPartyID 42444E. The VendorID 42450E has zero orone occurrences 42452E for each TransshipmentLocation entity 42410E anda data type of LocationPartyID 42454E. The Address 42460E has one orzero occurrences 42472E for each TransshipmentLocation entity 42410E anda data type of Address 42464E.

The ShipToLocation entity 42470E includes an InternalID 42480E, aStandardID 42490E, a BuyerID 42400F, a VendorID 42410F and an UnloadingLocation entity 42420F. The InternalID 42480E has zero or oneoccurrences 42482E for each ShipToLocation entity 42470E and a data typeof LocationInternalID 42484E. The StandardID 42490E has zero or noccurrences 42492E for each ShipToLocation entity 42470E and a data typeof LocationStandardID 94E. The BuyerID 42400F has zero or oneoccurrences 42402F for each ShipToLocation entity 42470E and a data typeof LocationPartyID 42404F. The VendorID 42410F has zero or oneoccurrences 42412F for each ShipToLocation entity 42470E and a data typeof LocationPartyID 42414F. The Unloading Location entity 42420F has oneor zero occurrences 42422F for each ShipToLocation entity 42470E and adata type of BusinessTransactionDocumentLocation 42424F.

The Unloading Location entity 42420F includes an InternalID 42430F oftype LocationInternalID 42434F, a StandardID 42440F of typeLocationStandardID 42444F, a BuyerID 42450F of type LocationPartyID42454F, and a VendorID 42460F of type LocationPartyID 42464F. In oneimplementation, for each Unloading Location entity 42420F, there is zeroor one 42432F InternalID 42430F, zero or n 42442F StandardIDs 42440F,zero or one 42452F BuyerID 42450F, and zero or one 42462F VendorID42460F.

The ProductInformation package 42430C includes a Product entity 42480Fof type BusinessTransactionDocumentProduct 42484F. There is one 42482FProduct entity 42480F for each Item entity 42496B. The Product entity42480F includes an InternalID 42490F of type ProductInternalID 42494F, aStandardID 42400G of type ProductStandardID 42404G, a BuyerID 42410G oftype ProductPartyID 42414G, and a VendorID 42420G of type ProductPartyID42424G. In one implementation, for each Product entity 42480F, there iszero or one 42492F InternalID 42490F, zero or one 42402G StandardIDs42400G, zero or one 42412G BuyerID 42410G, and zero or one VendorID42420G.

The DeliveryInformation package 42432C includes a PreviousDeliveryentity 42430G and a CumulativeDelivery entity 42462G. There is one orzero 42432G PreviousDelivery entity 42430G for each Item entity 42496B.There is one or zero 42464G CumulativeDelivery entity 42462G for eachItem entity 42496B.

The PreviousDelivery entity 42430G includes one 42438G ID entity 42436Gof type BusinessTransactionDocumentID 42440G. The PreviousDeliveryentity entity 42430G also includes one or zero 42448G ReceivedQuantity42446G of type Quantity 42449G. The PreviousDelivery entity 42430Gfurther includes one or zero 42456G ReceiptDateTime 42454G of typeDateTime 42458G.

The CumulativeDelivery entity 42462G includes a ValidityPeriod 42468G oftype DateTimePeriod 42472G, a ReceivedQuantity 42476G of type Quantity42480G, a ReconcilliationDateTime 42486G of type DateTime 42490G, aReconcilliationQuantity 42498G of type Quantity 42498G, and aShippedQuantity 42484I of type Quantity 42488I. In one implementation,for each CumulativeDelivery entity 42462G, there is zero or one 42470GValidityPeriod 42468G, zero or one 42486I ShippedQuantity 42484I, one42478G ReceivedQuantity 42476G, zero or one 42488GReconcilliationDateTime 42486G, and zero or one 42496GReconcilliationQuantity 42498G.

The ScheduleLine package 42434C includes a ScheduleLine entity 42404H oftype DeliveryScheduleItemLine 42408H. There is one or more 42406HScheduleLine entities 42404H for each Item 96B. Each ScheduleLine entity42404H includes a CommitrnentCode entity 42412H of typeScheduleLineCommitmentCode 42416H, a ProductChangeID 42422H of typeProductChangeID 42426H, a DeliveryPeriod 42432H of type DateTimePeriod42436H, a PickUpPeriod 42440H of type DateTimePeriod 42444H, a Quantity42448H of type Quantity 42452H, and a Note 42458H of type Note 42462H.In one implementation, for each ScheduleLine entity 42404H, there is one42414H CommitmentCode entity 42412H, zero or one 42424H ProductChangeID42422H, zero or one 42434H DeliveryPeriod 42432H, zero or one 42442HPickUpPeriod 42440H, one 42450H Quantity, and zero or one 42460H Note42458H.

As depicted in FIG. 424K, the Schedule Line package 42434C includes aConfirmedScheduleLine entity 42400K with any number 42402K ofConfirmedScheduleLine entities 42400K for a Schedule Line package42434C. The name is DeliveryScheduleItem-ConfirmedScheduleLine 42404K.The ConfirmedScheduleLine entity 42400K includes a DeliveryPeriod entity42406K, a PickUpPeriod entity 42412K, and a Quantity entity 42418K. TheDeliveryPeriod entity 42406K has zero or one 42408K DeliveryPeriodentities 42406K for a Schedule Line package 42434C and the name isDateTimePeriod 42410K. The PickUpPeriod entity 42412K has zero or one42414K PickUpPeriod entities 42412K for a Schedule Line package 42434C.The name is DateTimePeriod 42416K. The Quantity entity 42418K has one42420K Quantity entity 42418K for a Schedule Line package 42434C. Thename is Quantity 42422K.

(5) Element Structure of Delivery Schedule Notification Message

FIGS. 424AA-AU depict the element structure for DeliverySchedule. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 424A00 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 424AA, the interface for DeliverySchedule includes sixlevels 424A02, 424A04, 424A06, 424A08, 424A10, and 424A12. The elementstructure identifies the occurrence or cardinality 424A14 between theentities of the interface, and provides data type information (i.e.,G/CDT type 424A16) regarding the data type that provides the basis forthe entity. The outermost package of this interface is aDeliveryScheduleMessage package 424A24, which includes aDeliveryScheduleNotification entity 424A22 at the first level 424A02.The DeliveryScheduleNotification entity 424A22 is of type“DeliveryScheduleNotificationMessage” 424A28.

The DeliveryScheduleMessage package 424A26 includes a MessageHeaderpackage 424A32 and a DeliverySchedule package 424A34. The MessageHeaderpackage 424A32 includes a MessageHeader entity 424A36, which is of typegeneric data type “BusinessDocumentMessageHeader” 424A40. There is one424A38 MessageHeader entity 424A36 for each DeliveryScheduleMessageentity 424A26.

The MessageHeader entity 424A36 includes an ID 424A46, a Reference ID424A56, and a CreationDateTime 424A66. The ID 424A46 is of typeBusinessDocumentMessageID 424A50. The CreationDateTime 424A66 is of typeDateTime 424A70. There is one 424A48 ID 424A46 for each MessageHeaderentity 424A36, and one 424A68 CreationDateTime 424A66 for eachMessageHeader entity 424A36.

The MessageHeader entity 424A36 also includes a SenderParty entity424A74 and a RecipientParty entity 424A00A. The SenderParty entity424A74 is of type BusinessDocumentMessageHeaderParty 424A78. TheRecipientParty entity 424A00A is also of typeBusinessDocumentMessageHeaderParty 424A04A. There is one or zero 424A76SenderParty entity 424A74 for each MessageHeader entity 424A36, andthere is one or zero 424A02A RecipientParty entity 424A00A for eachMessageHeader entity 424A36.

The SenderParty entity 424A74 includes an InternalID 424A84 and aStandardID 424A92. The InternalID 424A84 has zero or one occurrences424A86 for each SenderParty entity 424A74 and a data type ofPartyInternalID 424A88. The StandardID 424A92 has zero or n occurrences424A94 for each SenderParty entity 424A74 and a data type ofPartyStandardID 424A96. The RecipientParty entity 424A00A includes anInternalID 424A10A and a StandardID 424A18A. The InternalID 424A10A haszero or one occurrences 12A for each Recipient Party 424A00A and a datatype of PartyInternalID 424A14A. The StandardID 424A18A has zero or noccurrences 424A20A for each Recipient Party 424A00A and a data type ofPartyStandardID 424A22A.

The DeliverySchedule package 424A14A includes a DeliverySchedule entity424A26A, a Party package 424A62A, an Item package 424A64A and a Note424A86B. There is one or zero 424A88B Note, and the Note 424A86B is oftype Note 424A90B. There is one 424A28A DeliverySchedule entity 424A26Afor each DeliverySchedule package 424A14A. The DeliverySchedule entity424A26A is of type DeliverySchedule_Notification 424A32A. TheDeliverySchedule entity 424A26A includes an ID 424A34A, a TypeCode424A44A, and a CreationDateTime 424A54A. There is one or zero 424A36A ID424A34A for each DeliverySchedule entity 424A26A. The ID 424A34A is oftype BusinessTransactionDocumentID 424A38A. The TypeCode 424A44A haszero or one 424A46A occurrences for each DeliverySchedule entity 424A26Aand is of type DeliveryScheduleTypeCode 424A48AA. A CreationDateTime424A54A has one occurrence 424A56A for each DeliverySchedule entity424A26A and is of type DateTime 424A58A.

The Party package 424A62A includes a BuyerParty entity 424A66A and aVendorParty entity 424A26B. The BuyerParty 424A66A is of typeBusinessTransactionDocumentParty 424A66A. There is one or zero 424A68ABuyerParty entity 424A66A for each DeliverySchedule entity 424A26A. TheVendorParty entity 424A26B is of type BusinessTransactionDocumentParty424A30B. There is one 424A28B VendorParty entity 424A26B for eachDeliverySchedule entity 424A26A.

The BuyerParty entity 424A66A includes an InternalID 424A76A, aStandardID 424A86A, a BuyerID 424A96A, a VendorID 424A06B, and anAddress 424A16B. The InternalID 424A76A has zero or one occurrences424A78A for the BuyerParty entity 424A66A and a data type ofPartyInternalID 424A80A. The StandardID 424A86A has zero or noccurrences 424A88A for the BuyerParty entity 424A66A and a data type ofPartyStandardID 424A90A. The BuyerID 424A96A has zero or one occurrences424A98A for the BuyerParty entity 424A66A and a data type ofPartyPartyID 424A00B. The VendorID 424A06B has zero or one occurrences424A08B for the BuyerParty entity 424A66A and a data type ofPartyPartyID 424A10B. The Address 424A16B has zero or one occurrences424A18B for each BuyerParty entity 424A66A and a data type of Address424A20B.

The VendorParty entity 424A26B includes an InternalID 424A36B, aStandardID 424A46B, a BuyerID 424A56B, a VendorID 424A66B, and anAddress 424A76B. The InternalID 424A3 6B has zero or one occurrences424A3 8B for the VendorParty entity 424A26B and a data type ofPartyInternalID 424A40B. The StandardID 424A46B has zero or noccurrences 424A48B for the VendorParty entity 424A26B and a data typeof PartyStandardID 424A50B. The BuyerID 424A56B has zero or oneoccurrences 424A58B for the VendorParty entity 424A26B and a data typeof PartyPartyID 424A60B. The VendorID 424A66B has zero or oneoccurrences 424A68B for the VendorParty entity 424A26B and a data typeof PartyPartyID 424A70B. The Address 424A76B has zero or one occurrences424A78B for the VendorParty entity 424A26B and a data type of Address424A80B.

The Item package 424A64A includes an Item entity 424A96B. There is oneor more 424A98B Item entities 424A96B for each DeliverySchedule entity424A26A. The Item entity 424A96B is of typeDeliveryScheduleItem_Notification 424A00C. The Item entity 424A96Bincludes a @actionCode 424A04C, and an ID 424A14C. The @actionCode424A04C is of type ActionCode 424A04C, and there is one or zero 424A06C@actionCode 424A04C for each Item entity 424A96B. The ID 424A14C is oftype BusinessTransactionDocumentItemID 424A18C, and there is one 424A16CID 424A14C for each Item entity 424A96B.

The Item package 424A64A also includes aBusinessTransactionDocumentReference package 424A24C, a Release package424A26C, a Location package 28C, a ProductInformation package 424A30C, aDeliveryInformation package 424A32C, a ScheduleLine package 424A34C anda Note entity 424A68H of data type Note 424A72H. There is zero or one424A70H Note entity 424A68H for each Item entity 424A96B.

The BusinessTransactionDocumentReference package 424A24C includes aSchedulingAgreementReference entity 424A36C of typeBusinessTransactionDocumentReference 424A40C. There is one 424A38CSchedulingAgreementReference entity 424A36Cfor each Item entity 424A96B.

The Release package 424A26C includes a Release entity 424A44C, and aPreviousRelease entity 424A76C. There is one 424A46C Release entity424A44C for each Item entity 424A96B. The Release entity 424A44Cincludes an ID 424A50C, a CreationDataTime 424A60C and a HorizonDataTime424A68C. The ID 424A50C is of type BusinessDocumentMessageID 424A54C.The CreationDataTime 424A60C is of type DateTime 424A64C. TheHorizonDataTime 424A68C is of type DateTime 424A72C. There is one424A52C ID 424A50C for each Item entity 424A96B, one or zero 424A62CCreationDataTime 424A60C for each Item entity 424A96B, and one or zero424A70C HorizonDataTime 424A68C for each Item entity 424A96B. ThePreviousRelease entity 424A76C includes an ID 424A82C, and aCreationDataTime 424A92C. The ID 424A82C is of typeBusinessDocumentMessageID 424A86C. The CreationDataTime 424A92C is oftype DateTime 424A96C. There is one 424A84C ID 424A82C for each Itementity 424A96B, and one or zero 424A94C CreationDataTime 424A92C foreach Item entity 424A96B.

The Location package 424A28C includes a ShipFromLocation entity 424A00D,and a TransshipmentLocation entity 424A10E, and a ShipToLocation entity424A70E. The ShipFromLocation entity 424A00D is of typeBusinessTransactionDocumentShipFromLocation 424A04D. There is one orzero 424A02D ShipFromLocation entity 424A00D for each Item entity424A96B. The TransshipmentLocation entity 424A10E is of type ofBusinessTransactionDocumentTransshipmentLocation 424A14E. There is oneor zero 424A12E TransshipmentLocation entity 424A10E for each Itementity 424A96B. The ShipToLocation entity 424A70E is of typeBusinessTransactionDocumentLocation 424A74E. There is one 424A72EShipToLocation entity 424A70E for each Item entity 424A96B.

The ShipFromLocation entity 424A00D includes an InternalID 424A10D, aStandardID 424A20D, a BuyerID 424A30D, a VendorID 424A40D, aLoadingLocation entity 424A50D, and an Address 424A00E. The InternalID424A10D has zero or one occurrences 424A12D for the ShipFromLocationentity 424A00D and a data type of LocationInternalID 424A14D. TheStandardID 424A20D has zero or n occurrences 424A22D for theShipFromLocation entity 424A00D and a data type of LocationStandardID424A24D. The BuyerID 424A30D has zero or one occurrences 424A32D and adata type of LocationPartyID 424A34D. The VendorID 424A40D has zero orone occurrences 424A42D for the ShipFromLocation entity 424A00D and adata type of LocationPartyID 424A44D. The LoadingLocation entity 424A50Dhas zero or one occurrences 424A52D for the ShipFromLocation entity424A00D and a data type of BusinessTransactionDocumentLocation 424A54D.The Address 424A00E has one or zero occurrences 424A02E for theShipFromLocation entity 424A00D and a data type of Address 424A04E. TheLoadingLocation entity 424A50D includes an InternalID 424A60D, aStandardID 424A70D, a BuyerID 424A80D, and a VendorID 424A90D. TheInternalID 424A60D has zero or one occurrences 424A62D for eachLoadingLocation entity 424A50D and a data type of LocationInternalID424A64D. The StandardID 424A70D has zero or one occurrences 424A72D foreach LoadingLocation entity 424A50D and a data type ofLocationStandardID 424A74D. The BuyerID 424A80D has zero or oneoccurrences 424A82D for each LoadingLocation entity 424A50D and a datatype of LocationPartyID 424A84D. The VendorID 424A90D has zero or oneoccurrences 424A92D for each LoadingLocation entity 424A50D and a datatype of LocationPartyID 424A94D.

The TransshipmentLocation entity 424A10E includes an InternalID 424A20E,a StandardID 424A30E, a BuyerID 424A40E, a VendorID 424A50E and anAddress 424A60E. The InternalID 424A20E has zero or one occurrences424A22E for each TransshipmentLocation entity 424A10E and a data type ofLocationInternalID 424A24E. The StandardID 424A30E has zero or noccurrences 424A32E for each TransshipmentLocation entity 424A10E and adata type of LocationStandardID 424A34E. The BuyerID 424A40E has zero orone occurrences 424A42E for each TransshipmentLocation entity 424A10Eand a data type of LocationPartyID 424A44E. The VendorID 424A50E haszero or one occurrences 424A52E for each TransshipmentLocation entity424A10E and a data type of LocationPartyID 424A54E. The Address 424A60Ehas one or zero occurrences 424A72E for each TransshipmentLocationentity 424A10E and a data type of Address 424A64E.

The ShipToLocation entity 424A70E includes an InternalID 424A80E, aStandardID 424A90E, a BuyerID 424A00F, a VendorID 424A10F and anUnloading Location entity 424A20F. The InternalID 424A80E has zero orone occurrences 424A82E for each ShipToLocation entity 424A70E and adata type of LocationInternalID 424A84E. The StandardID 424A90E has zeroor n occurrences 424A92E for each ShipToLocation entity 424A70E and adata type of LocationStandardID 94E. The BuyerID 424A00F has zero or oneoccurrences 424A02F for each ShipToLocation entity 424A70E and a datatype of LocationPartyID 424A04F. The VendorID 424A10F has zero or oneoccurrences 424A12F for each ShipToLocation entity 424A70E and a datatype of LocationPartyID 424A14F. The Unloading Location entity 424A20Fhas one or zero occurrences 424A22F for each ShipToLocation entity424A70E and a data type of BusinessTransactionDocumentLocation 424A24F.

The Unloading Location entity 424A20F includes an InternalID 424A30F oftype LocationInternalID 424A34F, a StandardID 424A40F of typeLocationStandardID 424A44F, a BuyerID 424A50F of type LocationPartyID424A54F, and a VendorID 424A60F of type LocationPartyID 424A64F. In oneimplementation, for each Unloading Location entity 424A20F, there iszero or one 424A32F InternalID 424A30F, zero or n 424A42F StandardIDs424A40F, zero or one 424A52F BuyerID 424A50F, and zero or one 424A62FVendorID 424A60F.

The ProductInformation package 424A30C includes a Product entity 424A80Fof type BusinessTransactionDocumentProduct 424A84F. There is one 424A82FProduct entity 424A80F for each Item entity 424A96B. The Product entity424A80F includes an InternalID 424A90F of type ProductInternalID424A94F, a StandardID 424A00G of type ProductStandardID 424A04G, aBuyerID 424A10G of type ProductPartyID 424A14G, and a VendorID 424A20Gof type ProductPartyID 424A24G. In one implementation, for each Productentity 424A80F, there is zero or one 424A92F InternalID 424A90F, zero orone 424A02G StandardIDs 424A00G, zero or one 424A12G BuyerID 424A10G,and zero or one VendorID 424A20G.

The DeliveryInformation package 424A32C includes a PreviousDeliveryentity 424A30G and a CumulativeDelivery entity 424A62G. There is one orzero 424A32G PreviousDelivery entity 424A30G for each Item entity424A96B. There is one or zero 424A64G CumulativeDelivery entity 424A62Gfor each Item entity 424A96B.

The PreviousDelivery entity 424A30G includes one 424A38G ID entity424A36G of type BusinessTransactionDocumentID 424A40G. ThePreviousDelivery entity entity 424A30G also includes one or zero 424A48GReceivedQuantity 424A46G of type Quantity 424A49G. The PreviousDeliveryentity 424A30G further includes one or zero 424A56G ReceiptDateTime424A54G of type DateTime 424A58G.

The CumulativeDelivery entity 424A62G includes a ValidityPeriod 424A68Gof type DateTimePeriod 424A72G, a ReceivedQuantity 424A76G of typeQuantity 424A80G, a ReconcilliationDateTime 424A86G of type DateTime424A90G, and a ReconcilliationQuantity 424A98G of type Quantity 424A98G.In one implementation, for each CumulativeDelivery entity 424A62G, thereis zero or one 424A70G ValidityPeriod 424A68G, one 424A78GReceivedQuantity 424A76G, zero or one 424A88G ReconcilliationDateTime424A86G, and zero or one 424A96G ReconcilliationQuantity 424A98G.

The ScheduleLine package 424A34C includes a ScheduleLine entity 424A04Hof type DeliveryScheduleItemScheduleLine_Notification 424A08H. There isone or more 424A06H ScheduleLine entities 424A04H for each Item 96B.Each ScheduleLine entity 424A04H includes a CommitmentCode entity424A12H of type ScheduleLineCommitmentCode 424A16H, a ProductChangeID424A22H of type ProductChangeID 424A26H, a DeliveryPeriod 424A32H oftype DateTimePeriod 424A36H, a PickUpPeriod 424A40H of typeDateTimePeriod 424A44H, a Quantity 424A48H of type Quantity 424A52H, anda Note 424A58H of type Note 424A62H. In one implementation, for eachScheduleLine entity 424A04H, there is one 424A14H CommitmentCode entity424A12H, zero or one 424A24H ProductChangeID 424A22H, zero or one424A34H DeliveryPeriod 424A32H, zero or one 424A42H PickUpPeriod424A40H, one 424A50H Quantity, and zero or one 424A60H Note 424A58H.

(6) Element Structure of Delivery Schedule Confirmation Message

The message data type element structure for theDeliveryScheduleConfirmation message is depicted in FIG. 424BA-BH. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 424B00 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 424BA, the interface for DeliveryScheduleConfirmationMessage includes five levels 424B013, 424B02, 424B03, 424B04, 424B05,424B06. The outermost package of this interface is aDeliveryScheduleMessage package 424B09, which includes aDeliveryScheduleConfirmation entity 424B110 at the first level 424B0land packages: BusinessDocumentMessageHeader 424B112 andDeliverySchedule 424B40.

The DeliveryScheduleConfirmation 424B10 is of typeDeliveryScheduleConfirmationMessage 424B11.

There is one 424B14 MessageHeader 424B13 for eachBusinessDocumentMessageHeader 424B12. The MessageHeader 424B13 is oftype BusinessDocumentMessageHeader 424B15. The MessageHeader 424B13includes elements: ID 424B16 and CreationDateTime 424B19. TheMessageHeader 424B13 includes entities: SenderParty 424B22 andRecipientParty 424B33. There is one 424B37 ID 424B16 for eachMessageHeader 424B13. The ID 424B16 is of typeBusinessDocumentMess.ageID 424B18. There is one 424B20 CreafionDateTime424B19 for each MessageHeader 424B13. The CreationDateTime 424B19 is oftype DateTime 424B21. There is zero or one 424B23 SenderParty 424B22 foreach MessageHeader 424B13. The SenderParty 424B22 is of typeBusinessDocument-MessageHeaderParty 424B24. The SenderParty 424B22includes elements: InternalID 424B25 and StandardID 424B28.

There is zero or one 424B26 InternalID 424B25 for each SenderParty424B22. The InternalID 424B25 is of type PartyInternalID 424B27. Theremay be any number 424B29 of StandardID 424B28 for each SenderParty424B22. The StandardID 424B28 is of type PartyStandardID 424B30.

There is zero or one 424B32 RecipientParty 424B31 for each MessageHeader424B13. The RecipientParty 424B31 is of typeBusinessDocumentMessageHeaderParty 424B33. The RecipientParty 424B31includes elements: InternalID 424B34 and StandardID 424B37. There iszero or one 424B35 InternalID 424B34 for each RecipientParty 424B31. TheInternalID 424B34 is of type PartyInternalID 424B36. There may be anynumber 424B38 of StandardID 424B37 for each RecipientParty 424B31. TheStandardID 424B37 is of type PartyStandardID 424B39.

The DeliverySchedule 424B40 includes an entity DeliverySchedule 424B41.There is one 424B42 DeliverySchedule 424B41 for each DeliverySchedule424B40. The DeliverySchedule 424B41 is of typeDeliverySchedule_Confirmation 424B43. The DeliverySchedule 424B41includes elements: ID 424B44, TypeCode 424B47, and CreationDateTime424B50.

There is zero or one 424B45 ID 424B44 for each DeliverySchedule 424B41.The ID 424B44 is of type BusinessTransactionDocumentID 424B46. There iszero or one 424B48 TypeCode 424B47 for each DeliverySchedule 424B41. TheTypeCode 424B47 is of type DeliveryScheduleTypeCode 424B49. There is one424B51 CreationDateTime 424B50 for each DeliverySchedule 424B41. TheCreationDateTime 424B50 is of type DateTime 424B52.

The Party package 424B53 includes entities: BuyerParty 424B54 andVendorParty 424B69. There is zero or one 424B55 BuyerParty 424B54 foreach Party 424B53. The BuyerParty 424B54 is of typeBusinessTransactionDocumentParty 424B56. The BuyerParty 424B54 includeselements: InternalID 424B57, StandardID 424B60, BuyerID 424B63, andVendorID 424B66.

There is zero or one 424B58 InternalID 424B57 for each BuyerParty424B54. The InternalID 424B57 is of type PartyInternalID 424B59. Theremay be any number 424B61 of StandardID 424B60 for each BuyerParty424B54. The StandardID 424B60 is of type PartyStandardID 424B62. Thereis zero or one 424B64 BuyerID 424B63 for each BuyerParty 424B54. TheBuyerID 424B63 is of type PartyPartyID 424B65. There is zero or one424B67 VendorID 424B66 for each BuyerParty 424B54. The VendorID 424B66is of type PartyPartyID 424B68.

There is one 424B70 VendorParty 424B69 for each Party 424B53. TheVendorParty 424B69 is of type BusinessTransactionDocumentParty 424B71.The VendorParty 424B69 includes elements: InternalID 424B72, StandardID424B75, BuyerID 424B78, and VendorID 424B81. There is zero or one 424B73InternalID 424B72 for each VendorParty 424B69. The InternalID 424B72 isof type PartyInternalID 424B74. There may be any number 424B76 ofStandardID 424B75 for each VendorParty 424B69. The StandardID 424B75 isof type PartyStandardID 424B77. There is zero or one 424B79 BuyerID424B78 for each VendorParty 424B69. The BuyerID 424B78 is of typePartyPartyID 424B80. There is zero or one 424B82 VendorID 424B81 foreach VendorParty 424B69. The VendorID 424B81 is of type PartyPartyID424B83.

There is zero or one 424B85 Note 424B84 for each DeliverySchedule424B40. The Note 424B84 is of type Note 424B86.

The Item package 424B87 includes entities: Item 424B88 and Note 424B06B.The Item package 424B87 includes packages:BusinessTransactionDocumentReference 424B97, Release 424B013A, Party424B133A, Location 424B44A, ProductInformation 424B90A, and ScheduleLine424B09B. There is one or more 424B89 Item 424B88 for each Item 424B87.The Item 424B88 is of type DeliveryScheduleItem_Confirmation 424B90. TheItem 424B88 includes elements: @actionCode 424B91 and ID 424B94.

There is zero or one 424B92 @actionCode 424B91 for each Item 424B88. The@actionCode 424B91 is of type ActionCode 424B93. There is one 424B95 ID424B94 for each Item 424B88. The ID 424B94 is of typeBusinessTransactionDocumentItemID 424B96. TheBusinessTransactionDocumentReference package 424B97 includes aSchedulingAgreementReference entity 424B98. There is one 424B99SchedulingAgreementReference 424B98 for eachBusinessTransactionDocumentReference 424B97. TheSchedulingAgreementReference 424B98 is of typeBusinessTransactionDocumentReference 424B00A.

The Release package 424B01A includes a Release entity 424B02A.

There is one 424B03A Release 424B02A for each Release 424B01A. TheRelease 424B02A includes elements: ID 424B04A, CreationDateTime 424B07A,and HorizonDateTime 424B10A. There is one 424B05A ID 424B04A for eachRelease 424B02A. The ID 424B04A is of type BusinessTransactionDocumentID424B06A. There is zero or one 424B08A CreationDateTime 424B07A for eachRelease 424B02A. The CreationDateTime 424B07A is of type DateTime424B09A. There is zero or one 424B11A HorizonDateTime 424B10A for eachRelease 424B02A. The HorizonDateTime 424B10A is of type DateTime424B12A.

The Party package 424B13A includes entities: BuyerParty 424B14A andProductRecipientParty 424B29A. There is zero or one 424B15A BuyerParty424B14A for each Party 424B13A. The BuyerParty 424B14A is of typeBusinessTransactionDocumentParty 424B16A. The BuyerParty 424B14Aincludes elements: InternalID 424B17A, StandardID 424B20A, BuyerID424B23A, and VendorID 424B26A. There is zero or one 424B18A InternalID424B17A for each BuyerParty 424B14A. The InternalID 424B17A is of typePartyInternalID 424B19A.

There may be any number 424B21A of StandardID 424B20A for eachBuyerParty 424B14A. The StandardID 424B20A is of type PartyStandardID424B22A. There is zero or one 424B24A BuyerID 424B23A for eachBuyerParty 424B14A. The BuyerID 424B23A is of type PartyPartyID 424B25A.There is zero or one 424B27A VendorID 424B26A for each BuyerParty424B14A. The VendorID 424B26A is of type PartyPartyID 424B28A.

There is zero or one 424B30A ProductRecipientParty 424B29A for eachParty 424B13A. The ProductRecipientParty 424B29A is of typeBusinessTransactionDocumentParty 424B31A. The ProductRecipientParty424B29A includes elements: InternalID 424B32A, StandardID 424B35A,BuyerID 424B38A, and VendorID 424B41A. There is zero or one 424B33AInternalID 424B32A for each ProductRecipientParty 424B29A. TheInternalID 424B32A is of type PartyInternalID 424B34A. There may be anynumber 424B36A of StandardID 424B35A for each ProductRecipientParty424B29A. The StandardID 424B35A is of type PartyStandardID 424B37A.There is zero or one 424B39A BuyerID 424B38A for eachProductRecipientParty 424B29A. The BuyerID 424B38A is of typePartyPartyID 424B40A. There is zero or one 424B42A VendorID 424B41A foreach ProductRecipientParty 424B29A. The VendorID 424B41A is of typePartyPartyID 424B43A.

The Location package 424B44A includes entities: ShipFromLocation424B45A, TransshhipmentLocation 424B60A, and ShipToLocation 424B75A.There is zero or one 424B46A ShipFromLocation 424B45A for each Location424B44A. The ShipFromLocation 424B45A is of typeBusinessTransaction-DocumentShipFromLocation 424B47A. TheShipFromLocation 424B45A includes elements: InternalID 424B48A,StandardID 424B51A, BuyerID 424B54A, and VendorID 424B57A. There is zeroor one 424B49A InternalID 424B48A for each ShipFromLocation 424B45A. TheInternalID 424B48A is of type LocationInternalID 424B50A. There may beany number 424B52A of StandardID 424B51A for each ShipFromLocation424B45A. The StandardID 424B51A is of type LocationStandardID 424B53A.There is zero or one 424B55A BuyerID 424B54A for each ShipFromLocation424B45A. The BuyerID 424B54A is of type LocationPartyID 424B56A. Thereis zero or one 424B58A VendorID 424B57A for each ShipFromLocation424B45A. The VendorID 424B57A is of type LocationPartyID 424B59A. Thereis zero or one 424B61A TransshhipmentLocation 424B60A for each Location424B44A. The TransshhipmentLocation 424B60A is of typeBusinessTransactionDocumentTransshipmentLocation 424B62A. TheTransshhipmentLocation 424B60A includes elements: InternalID 424B63A,StandardID 424B66A, BuyerID 424B69A, and VendorID 424B72A.There is zeroor one 424B64A InternalID 424B63A for each TransshhipmentLocation424B60A. The InternalID 424B63A is of type LocationInternalID 424B65A.There may be any number 424B67A of StandardID 424B66A for eachTransshhipmentLocation 424B60A. The StandardID 424B66A is of typeLocationStandardID 424B68A. There is zero or one 424B70A BuyerID 424B69Afor each TransshhipmentLocation 424B60A. The BuyerID 424B69A is of typeLocationPartyID 424B71A.

There is zero or one 424B73A VendorID 424B72A for eachTransshhipmentLocation 424B60A. The VendorID 424B72A is of typeLocationPartyID 424B74A.

There is zero or one 424B76A ShipToLocation 424B75A for each Location424B44A. The ShipToLocation 424B75A is of typeBusinessTransactionDocumentShipToLocation 424B77A. The ShipToLocation424B75A includes elements: InternalID 424B78A, StandardID 424B81A,BuyerID 424B84A, and VendorID 424B87A.

There is zero or one 424B79A InternalID 424B78A for each ShipToLocation.The InternalID 424B78A is of type LocationInternalID 424B80A. There maybe any number 424B82A of StandardID 424B81A for each ShipToLocation. TheStandardID 424B81A is of type LocationStandardID 424B83A. There is zeroor one 424B85A BuyerID 424B84A for each ShipToLocation. The BuyerID424B84A is of type LocationPartyID 424B86A. There is zero or one 424B88AVendorID 424B87A for each ShipToLocation. The VendorID 424B87A is oftype LocationPartyID 424B89A.

The ProductInformation package 424B90A includes an entity Product424B91A. There is one 424B92A Product 424B91A for eachProductInformation 424B90A. The Product 424B91A is of typeBusinessTransactionDocumentProduct 424B93A. The Product entity 424B91Aincludes elements: InternalID 424B94A, StandardID 424B97A, BuyerID424B00B, and VendorID 424B03B.

There is zero or one 424B95A InternalID 424B94A for each Product424B91A. The InternalID 424B94A is of type ProductInternalID 424B96A.There is zero or one 424B98A StandardID 424B97A for each Product424B91A. The StandardID 424B97A is of type ProductStandardID 424B99A.There is zero or one 424B01B BuyerID 424B00B for each Product 424B91A.The BuyerID 424B00B is of type ProductPartyID 424B02B. There is zero orone 424B04B VendorID 424B03B for each Product 424B91A. The VendorID424B03B is of type ProductPartyID 424B05B.

There is zero or one 424B07B Note 424B06B for each Item 424B87. The Note424B06B is of type Note 424B08B.

The ScheduleLine package 424B09B includes an entityConfirmedScheduleLine 424B10B. There is one or more 424B11BConfirmedScheduleLine 424B10B for each ScheduleLine 424B09B. TheConfirmedScheduleLine 424B10B is of typeDeliveryScheduleItem-ConfirmedScheduleLine_Confirmation 424B12B. TheConfirmedScheduleLine entity 424B10B includes elements: DeliveryPeriod424B13B, PickUpPeriod 424B16B, and Quantity 424B19B. There is zero orone 424B14B DeliveryPeriod 424B13B for each ConfirmedScheduleLine424B10B. The DeliveryPeriod 424B13B is of type DateTimePeriod 424B15B.There is zero or one 424B17B PickUpPeriod 424B16B for eachConfirmedScheduleLine 424B10B. The PickUpPeriod 424B16B is of typeDateTimePeriod 424B18B. There is one 424B20B Quantity 424B19B for eachConfirmedScheduleLine 424B10B. The Quantity 424B19B is of type Quantity424B21B.

u) Invoice Issued Information

One motivating business scenario for the InvoicelssuedInformationinterface is the Sell From Stock scenario. In the Sell From Stockscenario, accepting and creating an order may be the first stage in theprocess. The elements of the order relevant for the delivery arecommunicated to the FC for the purposes of order fulfillment. At thesame time, the elements of the order that are relevant for billing aretransferred to the billing due list in BAC Billing. After the deliveryhas been made, the elements of the delivery that are relevant forbilling are transferred to the billing due list in Billing, whichgenerates invoices (and credit memos) on the basis of these.

In the Sell From Stock scenario, several specific recipients will thenprovide information about the invoices that have been generated. Inparticular Recipient: BAC CRM will provide information about theInvoicelssuedInformation, Recipient: BAC Accounting will provideinformation about the InvoiceAccountingInformation, and Recipient: BACPayment will provide information about the PaymentDueNotification.

(1) Message Type Invoice Issued

InvoiceIssuedInformation provides information about the invoice itemsused for billing, the services provided, the products delivered, and thecredit memo or debit memo requests that have been billed, and thequantities or the values that have been billed. The message typeInvoicelssuedInformation is based on the message data typeInvoicelssuedMessage. Contract management/sales may require informationabout billing that has been carried out, in order to adapt the status oforder items (partially billed, billed) and be able to trigger follow-upactions if they are required (for example, updating credit information).

(2) Message Choreography

FIG. 425 depicts a graphical representation 42500 of anInvoicelssuedInformation 42510 between business entities in accordancewith methods and systems consistent with the subject matter describedherein. The illustrative message choreography is a logical sequence ofmessages that is not dependent on actual scenarios. In theimplementation shown in FIG. 425, the illustrative business entitiesinclude Customer 42502, Billing 42504, and Customer RelationshipManagement 42506. In the illustrative example, Billing 42504 (invoicecreation) uses InvoicelssuedInformation 42510 to inform CustomerRelationship Management 42506 about the contents of an invoice(InvoiceRequest 42508) that has been sent to a customer.

(3) Message Data Type Invoice Issued Message

As shown in FIG. 426, the message data type InvoiceIssuedMessage 42602includes the InvoiceIssued object included in the business document andthe business information that is relevant for sending a businessdocument in a message. It includes a MessageHeader package 42604 and anInvoiceIssued package 42606. The message data type InvoicelssuedMessagemakes the structure available for the message type InvoiceIssued and therelevant interfaces.

(a) Message Header Package

A MessageHeader package 42604 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader 42604 may not be required for the InvoiceIssuedInformationbecause there may be no intention to reference messages or communicatewith several instances of the components involved.

(b) Invoice Issued Package

The InvoiceIssued package 42606 summarizes the invoice informationrelevant for contract management/sales. It includes an InvoicelssuedItempackage 42610. The InvoiceIssued Message entity 42608 includes anInvoiceIssued entity 42612 and has a 1:1 relationship 42614 with it.

The InvoiceIssued entity 42612 summarizes the invoice informationrelevant for contract management/sales. The InvoiceIssued entity 42612includes information about which order items, items in credit and debitmemo requests or delivery items have been billed to what extent. TheInvoiceIssued entity 42612 includes a BaseInvoiceID, aCancellationInvoiceIndicator, and an IntraCorporateIndicator. TheBaseInvoiceID may be a unique identifier for the base invoice for theInvoicelssueNotification, and is of type GDT:BusinessTransactionDocumentID. The CancellationInvoiceIndicator is theindicator that specifies whether the invoice is a cancellation invoice.This can affect the status of the order item. For example, canceling aninvoice can sometimes mean that a billed order item is no longer billedor partially billed (milestone billing). TheCancellationInvoiceIndicator is of type GDT:InvoiceCancellationInvoiceIndicator. The IntraCorporateIndicator is theindicator that specifies whether the invoice is an intracorporateinvoice (intercompany billing). In contrast to a billing document, anintracorporate invoice has no effect on the status of the order item.The IntraCorporateIndicator is of type GDT:InvoiceIntraCorporateIndicator. The base invoice is specified using theBaseInvoiceID.

(c) Invoice Issued Item Package

The InvoicelssuedItem package 42610 groups together items from anInvoiceIssued message. It includes aBusinessTransactionDocumentReference package 42616.

(i) Invoice Issued Item

An InvoicelssuedItem entity 42618 specifies the quantity or the partialvalue of a product billed with respect to a business transaction. TheInvoiceIssued entity 42612 includes the InvoicelssuedItem entity 42618and has a 1:n relationship 42620 with it. Item 42618 includes aBaseInvoiceItemID, a BilledQuantity, and a BilledValue. TheBaseInvoiceItemID is the number of the item in the base invoice for theInvoiceIssued, and is of type GDT: BusinessTransactionDocumentItemID.The BilledQuantity is of type GDT: Quantity. With respect toBilledValue, in general, the net value is used to describe the billedvalue. However, the term NetValue is deliberately not used to emphasizethe particular semantic of the “billed value.” The BilledValue is oftype GDT: Amount.

The BaseInvoiceItemID is specified, together with either a billedquantity or a billed value. An InvoicelssuedItem entity 42618 is usuallynot regarded as being the same as an InvoiceItem. Rather it includesdetailed information from an invoice item. Usually, businesstransactions are (partial) deliveries for an order item. However, theycan also be items from credit and debit memo requests or deliverieswithout orders.

(ii) Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 42616 groups togetherthe references to business documents that have been billed. It includesa SalesOrderReference entity 42622 and a DeliveryReference entity 42624.The InvoicelssuedItem entity 42618 includes the SalesOrderReferenceentity 42622 and the DeliveryReference entity 42624 and has a 1:crelationship (42626 and 42628 respectively) with them.

(a) Sales Order Reference

The SalesOrderReference entity 42622 is the reference to an order or anitem within an order. The SalesOrderReference entity 42622 is of typeGDT: BusinessTransactionDocumentReference. The SalesOrderReferenceentity 42622 includes the order number assigned by the seller. The itemis specified in the order. Contract management/sales uses theinformation to adapt the status of individual items and therefore findsout which items in the order have already been billed.

(b) Delivery Reference

The DeliveryReference entity 42624 is the reference to a delivery or anitem within a delivery. The DeliveryReference entity 42624 is of typeGDT: BusinessTransactionDocumentReference. In one implementation, thisreference cannot be specified in the case of order-related billing.

(4) Element Structure

FIGS. 427A and B depict the element structure forInvoicelssuedInformation. The element structure is similar to the datamodel, but provides additional information regarding the details of theinterface. The element structure identifies the different packages 42700in the interface, and represents the entities at various levels withinthe interface. As depicted in FIGS. 427A and B, the interface forInvoiceIssuedInformation includes four levels 42702, 42704, 42706, and42708. The element structure identifies the cardinality 42710 betweenthe entities of the interface, and provides information 42712 (i.e.,type and name) regarding the data type that provides the basis for theentity. The outermost package of this interface is anInvoicelssuedMessage package 42714, which includes anInvoicelssuedMessage entity 42716 at the first level 42702. TheInvoicelssuedMessage entity 42716 is of type message data type (“MDT”)“InvoicelssuedMessage” 42720.

The InvoiceIssuedMessage package 42714 includes an InvoiceIssued package42722. The InvoiceIssued package 42722 includes an InvoiceIssued entity42724. There is one 42726 InvoiceIssued entity 42724 for eachInvoicelssuedMessage entity 42716 and the InvoiceIssued entity 42724 isof type GDT InvoiceIssued 42728. The InvoiceIssued entity 42724 includesa BaseInvoiceID 42730, a CancellationInvoiceIndicator 42736, and anIntraCorporateIndicator 42742.

There is one 42732 BaseInvoiceID 42730 for each InvoiceIssued entity42724. The BaseInvoiceID 42730 is of type GDTBusinessTransactionDocumentID 42734. A CancellationInvoiceIndicator42736 has one occurrence 42738 and is of type GDTInvoiceCancellationInvoiceIndicator 42740. IntraCorporateIndicator 42742has one occurrence 42744 and is of type GDT IntraCorporateIndicator42746.

The Item package 42748 includes an Item entity 42750. There is one ormore 42752 Item entities 42750 for each InvoiceIssued entity 42724, andthe Item entity 42750 is of type GDT Item 42754. The Item entity 42750includes a BaseInvoiceItemID 42756, a BilledQuantity 42762, and aBilledValue 42768. The BaseInvoiceItemID 42756 is of type GDTBusinessTransactionDocumentItemID 42760, and there is one 42758BaseInvoiceItemID 42756 for each Item entity 42750. The BilledQuantity42762 is of type GDT Quantity 42769, and there is one or zero 42764BilledQuantity 42762 for each Item entity 42750. There is one or zero42770 BilledValue 42768 for each Item entity 42750. The BilledValue42768 is of type GDT Amount 42772.

The Item package 42748 also includes aBusinessTransactionDocumentReference package 42774. TheBusinessTransactionDocumentReference package 42774 includes aSalesOrderReference entity 42776 and a DeliveryReference entity 42782.The SalesOrderReference entity 42776 is of type GDTBusinessTransactionDocumentReference 42780. There is one or zero 42778SalesOrderReference entities 42776 for each Item entity 42750. TheDeliveryReference entity 42782 is of type GDTBusinessTransactionDocumentItemID 42786 and there is one or zerooccurrences 42784.

v) Product Activity Interface

The ProductActivityNotification message is intended for planning andinformation purposes, generally for a supplier. It can containindividual entries and time series to specify the stock, demand, andconsumption of products of a buyer (retailers, wholesalers, ormanufacturers) in reference to a ship-to location. The message itselfimplies no authorization from the message recipient for the manufactureor shipping of products. Such an authorization can be made by schedulingagreements or other agreements.

In an interenterprise variant, the ProductActivityNotification messageis sent within the Business Scenarios Responsive Replenishment andCollaborative Planning, Forecasting, and Replenishment (CPFR) from abuyer (retail company) to a vendor (consumer products manufacturer). Inan intra-enterprise variant, this message is sent within the frameworkof the Business Scenarios Supplier Managed Inventory from an executivesystem (ERP) to the Inventory Collaboration Hub (ICH) for the planningand development of replenishment deliveries from the supplier. Thesupplier receives data about the existing stock and the forecastedconsumption of a product.

(1) Message Type Product Activity Notification

A ProductActivityNotification is a message that transfersproduct-related activities of a buyer (retailer, wholesaler, ormanufacturer) to a vendor (supplier). On that basis, the vendor can thentake on the replenishment planning for the buyer. Product-relatedactivities include, for example, current or planned product sales,current or planned product consumptions, stockouts, or open purchaseorder quantities.

The structure of the message type ProductActivityNotification isspecified in the message data type ProductActivityMessage. Methods andsystems consistent with the subject matter described herein use thepackage template for a BusinessTransactionDocument for an SCM MasterData depicted in FIG. 270B to derive the ProductActivity interface.

The notification transfer is complete (“complete transmission”). For theEAN.UCC, the equivalent for this notification is called a“ProductActivity.”

(2) Message Choreography

FIG. 428 depicts the message choreography for scenario “CPFR.” Itdescribes the possible logical sequence of the message types necessaryfor the scenario realization.

As depicted in FIG. 428, a buyer 42802 sends aProductDemandlnfluencingEventNotification 42806 to a vendor 42804. TheProductDemandInfluencingEventNotification 42806 includes long tomid-term demand information that is linked to an activity. Together withthe product forecast information, i.e., ProductForecastNotification42808, that is also sent by the buyer 42802, or, with short-termincidental current sales information, i.e., ProductActivityNotification42810, this information can be used by the vendor 42804 for the creationof a forecast for the product demands of the buyer 42802. In the case ofa cooperative settlement process between the buyer 42802 and vendor42804, the vendor 42804 can send a ProductForecastRevisionNotification42812 back to the buyer. The ProductForecastRevisionNotification 42812is a revision of the product forecast that was sent by the buyer 42802.In turn, the buyer 42802 can respond with aProductForecastRevisionNotification 42814, which is an updated revision.

(3) Message Data Type Product Activity Message

The message data type ProductActivityMessage groups the businessinformation that is relevant for sending a business document in amessage and the object ProductActivity included in the businessdocument. As depicted in FIG. 429, the message data typeProductActivityMessage includes a ProductActivityMessage package 42902,which includes a MessageHeader package 42904 and a ProductActivitypackage 42906. The ProductActivityMessage package 42902 also includes aProductActivityMessage entity 42908. The structure of the message datatype ProductActivity is available for the message typeProductActivityNotification and the relevant interfaces.

(a) Message Header Package

A MessageHeader package 42904 groups the business information that isrelevant for sending a business document in a message. It includes aMessageHeader entity 42910. There is a 1:1 relationship 42912 betweenthe ProductActivityMessage entity 42908 and the MessageHeader entity42910.

(i) Message Header

The MessageHeader groups the business information from the view of thesending application. The MessageHeader entity 42910 includes informationto identify the business document in a message, information about thesender, and, possibly, information about the recipient.

The MessageHeader entity 42910 includes a SenderParty entity 42914 and aRecipientParty entity 42916. There is a 1:c relationship 42918 betweenthe MessageHeader entity 42910 and the SenderParty entity 42914, and a1:c relationship 42920 between the MessageHeader entity 42910 and theRecipientParty entity 42916. The MessageHeader entity 42910 is of typeGDT: BusinessDocumentMessageHeader. The MessageHeader entity 42910 alsoincludes an ID and a CreationDateTime. The ID is the identification ofthe business document in the technical message. The CreationDateTime isthe creation date of the business document in the technical message.

(ii) Sender Party

The SenderParty is responsible for sending a business document at thebusiness application level. The SenderParty entity 42914 is of type GDT:BusinessDocumentMessageHeaderParty.

(iii) Recipient Party

The RecipientParty is responsible for receiving a business document atthe business application level. The RecipientParty entity 42916 is oftype GDT: BusinessDocumentMessageHeaderParty.

(b) Product Activity Package

The ProductActivity package 42906 groups the ProductActivity entity42928 with its packages. It includes a Party package 42922, aBusinessTransactionDocumentReference package 42924, and a ProductActivity Item package 42926. There is a 1:1 relationship 42930 betweenthe ProductActivityMessage entity 42908 and the ProductActivity entity42928.

ProductActivity includes information about the stock, demand, andconsumption of products of a buyer (retailers, wholesalers, ormanufacturers) at a ship-to location, and about the involved parties,for other relevant business documents and (optionally) for a ship-fromlocation. The ProductActivity entity 42928 includes a ValidityPeriod anda Note. The ValidityPeriod is the validity period for the specificationstransferred in the ProductActivityNotification, and is of type GDT:DateTimePeriod. The Note is a language-independent note, and is of typeGDT: Note.

(c) Party Package

The Party Package 42922 includes the grouping of the business partnersthat may be relevant within the ProductActivityNotification. It includesa BuyerParty entity 42932 and a VendorParty entity 42934. There is a 1:crelationship 42936 between the ProductActivity entity 42928 and theBuyerParty entity 42932, and a 1:c relationship 42938 between theProductActivity entity 42928 and the VendorParty entity 42934.

For an internal communication (with common master data), the InternalIDfor the party entities should be used. For an interenterprisecommunication (with business-partner-specific master data),either theStandardID or the partner-role-specific ID of the receiving partnershould be used for the party entities. In other words, for SupplierCollaboration scenarios the BuyerID should be used, and for CustomerCollaboration scenarios, the VendorID should be used. Due to thedifferent possibilities for ID use, all ID elements of the particular“Party” are optional. In an internal scenario, it is not a requirementto enter the business partner in the message; both party entities areoptional.

(i) Buyer Party

The BuyerParty is a company that buys goods. The BuyerParty entity 42932is of type GDT: BusinessTransactionDocumentParty. Typically theInternalID, the StandardID, the BuyerID, and the VendorID should beused.

(ii) Vendor Party

The VendorParty is a company that delivers goods. The VendorParty entity42934 is of type GDT: BusinessTransactionDocumentParty. Typically theInternalID, the StandardID, the BuyerID, and the VendorID should beused.

(d) Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 42924 is a grouping ofreferences to business documents that may occur in theProductActivityNotification. The BusinessTransactionDocumentReferencepackage 42924 includes an InboundDeliveryReference entity 42940. Thereis a 1:cn relationship 42942 between the ProductActivity entity 42928and the InboundDeliveryReference entity 42940.

The InboundDeliveryReference is the reference to an inbound delivery oran item within one. The InboundDeliveryReference entity 42940 is of typeGDT: BusinessTransactionDocumentReference.

(e) Product Activity Item Package

The ProductActivityItem package 42926 groups the ProductActivityItem42950 with its packages. It includes a Location package 42944, aProductInformation package 42946, and an Inventory package 42948. Thereis a 1:n relationship 42952 between the ProductActivity entity 42928 andthe ProductActivityItem entity 42950.

(i) Product Activity Item

The ProductActivityItem includes specifications about the stock, demand,and/or consumption of a product in reference to a ship-to location and(optionally) a ship-from location. The ProductActivityItem entity 42950includes a SalesTimeSeries, a PromotionSalesTimeSeries, aSalesForecastTimeSeries, a PromotionSalesForecastTimeSeries, anOrderForecastTimeSeries, a PromotionOrderForecastTimeSeries, aConsumptionTimeSeries, a ConsumptionForecastTimeSeries, anOnOrderTimeSeries, and an OutOfStockTimeSeries. The SalesTimeSeries isthe time series for the sale of products, and is of type GDT:QuantityTimeSeries, where the FixedIndicator is not used. ThePromotionSalesTimeSeries is the time series for the promotional sale ofproducts, and is of type GDT: QuantityTimeSeries, where theFixedIndicator is not used. The SalesForecastTimeSeries is the timeseries for the forecasted sale of products, and is of type GDT:QuantityTimeSeries, where the FixedIndicator is not used. ThePromotionSalesForecastTimeSeries is the time series for the forecastedpromotional sale of products, and is of type GDT: QuantityTimeSeries,where the FixedIndicator is not used. The OrderForecastTimeSeries is thetime series for the forecasted purchase orders of products, and is oftype GDT: QuantityTimeSeries, where the FixedIndicator is not used. ThePromotionOrderForecastTimeSeries is the time series for the forecastedpromotional purchase orders of products, and is of type GDT:QuantityTimeSeries, where the FixedIndicator is not used. TheConsumptionTimeSeries is the time series for the product consumptioninduced by production, and is of type GDT: QuantityTimeSeries, where theFixedIndicator is not used. The ConsumptionForecastTimeSeries is thetime series for the forecasted product consumption induced byproduction, and is of type GDT: QuantityTimeSeries, where theFixedIndicator is not used. The OnOrderTimeSeries is the time series forthe open purchase orders of products, and is of type GDT:QuantityTimeSeries, where the FixedIndicator is not used. TheOutOfStockTimeSeries is the time series for gaps in the warehouse stockof products that are based on the current product demand, and is of typeGDT: QuantityTimeSeries, where the FixedIndicator is not used.

(ii) Location Package

The Location Package 42944 includes a summary of the specifications onlocations that may be relevant for the delivery of the product specifiedin a ProductActivityItem. It includes a ShipFromLocation entity 42954and a ShipToLocation entity 42956. There is a 1:c relationship 42958between the Item entity 42950 and the ShipFromLocation entity 42954, anda 1:c relationship 42960 between the Item entity 42950 and theShipToLocation entity 42956.

For an internal communication (with common master data), the InternalIDfor location entities should be used. For a B2B communication (withbusiness-partner-specific master data), either the StandardID or thepartner-role-specific ID of the receiving partner should be used forlocation entities. In other words, for Supplier Collaboration scenarios,the BuyerID should be used, and for Customer Collaboration scenarios,the VendorID should be used. Due to the different possibilities for IDuse, ID elements of the particular “location” are optional.

(a) Ship From Location

The ShipFromLocation is the place from where the product specified inthe item of the ProductActivity is to be delivered. The ShipFromLocationentity 42954 is of type GDT:BusinessTransactionDocumentShipFromLocation. The InternalID, theStandardID, the BuyerID, and the VendorID in the ShipFromLocation entity42954 should be used.

(b) Ship To Location

The ShipToLocation is the place to where the product specified in theitem of the ProductActivitiy is to be delivered. The ShipToLocationentity 42956 is of type GDT: BusinessTransactionDocumentShipToLocation.The InternalID, the StandardID, the BuyerID, and the VendorID should beused in the ShipToLocation entity 42956.

(iii) Product Information Package

The ProductInformation package 42962 includes a summary of theinformation that characterizes a product in detail. It includes aProduct entity 42962. There is a 1:1 relationship 42964 between the Itementity 42950 and the Product entity 42962.

The Product is a tangible good for which the buyer makes specificationsfor the stock, demands, and/or consumption in aProductActivityNotification. The Product entity 42962 is of type GDT:BusinessTransactionDocumentProduct. The InternalID, the StandardID, theBuyerID, the VendorID, and PackageQuantity and DiscontinuationIndicatorin the Product entity 42962 should be used. For an internalcommunication (with common master data), the InternalID should be usedfor all product entities. For an interenterprise communication (withpartner-specific master data), either the StandardID or thepartner-role-specific ID of the receiving partner should be used for allproduct entities. In other words, for Supplier Collaboration scenarios,the BuyerID should be used, and for Customer Collaboration scenarios,the VendorID should be used. Due to the different possibilities for IDuse, all ID elements of the particular product are optional. Generally,a product is either a tangible or intangible good, and is a part of thebusiness activities of a company. It can be traded and contributesdirectly or indirectly to value added.

(iv) Inventory Package

The Inventory Package 42948 includes a summary of information about thewarehouse stock of a product at a buyer. It includes an Inventory entity42966 and a ConsignmentInventory entity 42968. There is a 1:crelationship 42970 between the Item entity 42950 and the Inventoryentity 42966, and a 1:c relationship 42972 between the Item entity 42950and the ConsignmentInventory entity 42968.

(a) Inventory

The Inventory identifies the warehouse stock of a product at a buyer.The Inventory entity 42966 includes a StatusDateTime, anUnrestrictedUseQuantity, a QualityInspectionQuantity, a BlockedQuantity,and a PromotionQuantity. The StatusDateTime is the date and time atwhich the warehouse stock was determined, and is of type GDT:InventoryStatusDateTime. The UnrestrictedUseQuantity is the quantitythat has an unlimited use, and is of type GDT: Quantity. TheQualitylnspectionQuantity is the quantity intended for qualityinspection, and is of type GDT: Quantity. The BlockedQuantity is thequantity that may not be used, and is of type GDT: Quantity. ThePromotionQuantity is the quantity intended for promotional purposes, andis of type GDT: Quantity. The specified stock information shows absolutevalues, not difference values.

(b) Consignment Inventory

The ConsignmentInventory identifies the consignment store stock of aproduct, in other words, the part of the stock that remains the propertyof the vendor until it is procured (and paid for). TheConsignmentInventory entity 42968 includes a StatusDateTime, anUnrestrictedUseQuantity, a QualitylnspectionQuantity, a BlockedQuantity,and a PromotionQuantity. The StatusDateTime is the date and time atwhich the goods receipt is posted into the warehouse stock, and is oftype GDT: InventoryStatusDateTime. The UnrestrictedUseQuantity is thequantity that has an unlimited use, and is of type GDT: Quantity. TheQualityInspectionQuantity is the quantity intended for qualityinspection, and is of type GDT: Quantity. The BlockedQuantity is thequantity that may not be used, and is of type GDT: Quantity. ThePromotionQuantity is the quantity intended for promotional purposes, andis of type GDT: Quantity. The specified stock information shows absolutevalues, not difference values.

(4) Element Structure of Product Activity Message

FIGS. 430A-L depict the element structure for aProductActivityNotification. The element structure is similar to theabove described data model of the message data type ProductActivityMessage as reflected in FIG. 429, but provides additional informationregarding the details for interfacing with or implementing aProductActivity Message, such as a ProductActivityNotification. As shownin FIGS. 430, the element structure identifies the different packages43000 that may be in a respective ProductActivityNotification. Theelement structure for the ProductActivityNotification includes sixlevels 43002, 43004, 43006, 43008, 43010, and 43012 each of which isassociated with a respective package 43000. The element structureidentifies the cardinality or occurrence 43014 and the data type 43016information for the elements at the respective levels 43002, 43004,43006, 43008, 43010, and 43012 in the respective package 43000.

The outermost package of this interface is a ProductActivityMessagepackage 43026, which includes a ProductActivityMessage entity 43028 atthe first level 43002. The ProductActivityMessage entity 43028 is oftype GDT: ProductActivityMessage 43030. The ProductActivityMessagepackage 43026 includes a MessageHeader package 43036 and aProductActivity package 43038.

The MessageHeader package 43036 includes a MessageHeader entity 43040,which is of type BusinessDocumenMessageHeader 43044. There is one 43042MessageHeader entity 43040 for each ProductActivityMessage entity 43028.The MessageHeader entity 43040 includes an ID 43052, a CreationDateTime43064, a SenderParty entity 43072, and a RecipientParty entity 43002A.The ID 43052 is of type BusinessDocumentMessageID 43056, and there isone 43054 ID 43052 for each MessageHeader entity 43040. TheCreationDateTime43064 is of type DateTime 43068, and there is one 43066CreationDateTime 43064 for each MessageHeader entity 43040. TheSenderParty entity 43072 is of type BusinessDocumentMessageHeaderParty43076, and there is zero or one 43074 SenderParty entity 43072 for eachMessageHeader entity 43040. The RecipientParty entity 43002A is of typeBusinessDocumentMessageHeaderParty 43006A, and there is zero or one43004A RecipientParty entity 43002A for each MessageHeader entity 43040.

The SenderParty entity 43072 includes an InternalID 43084 and a StandardID 43092. The InternalID 43084 is of type PartyInternalID 43088, andthere is zero or one 43086 InternalID 43084 for each SenderParty entity43072. The StandardID 43092 is of type PartyStandardID 43096, and thereis any number 43094 of StandardID 43092 for each SenderParty entity43072.

The RecipientParty entity 43002A includes an InternalID 43014A and aStandard ID 43022A. The InternalID 43014A is of type PartyInternalID43018A, and there is zero or one 43016A InternalID 43014A for eachRecipientParty entity 43002A. The StandardID 43022A is of typePartyStandardID 43026A, and there is any number 43024A of StandardID43022A for each RecipientParty entity 43002A.

The ProductActivity Package 43038 includes a ProductActivity entity43032A of type ProductActivity 43036A. There is one 43034AProductActivity entity 43032A for each ProductActivityMessage entity43028. The ProductActivity entity 43032A includes a ValidityPeriod43040A of DateTimePeriod 43044A. There is one or zero 43042AValidityPeriod 43040A for each ProductActivity entity 43032A. TheValidityPeriod 43040A includes a StartDateTime 43052A of type DateTime43056A and an EndDateTime 43062A of type DateTime 43066A. For eachProductActivity entity 43032A, there is one or zero 43054A StartDateTime43052A and one or zero 43064A EndDateTime 43062A. The ProductActiveyPackage 43038 also includes a SubContractingIndicator entity 43067A,there is one or zero 43069A SubContractingIndicators 43067A, and thetype is GDT 43071A.

The ProductActivity Package 43038 also includes a Party package 43072A,a BusinessTransactionDocumentRequest package 43074A, an Item package43076A, and a Note 43002C. The Note 43002C is of type Note 43006C. Thereis one or zero 43004C Note 43002C for each ProductActivity entity43032A.

The Party package 43072A includes a BuyerParty entity 43078A and aVendorParty entity 43036B. The BuyerParty 43078A is of typeBusinessTransactionDocumentParty 43082A. There is one or zero 43080ABuyerParty entity 43078A for each ProductActivity entity 43032A. TheVendorParty entity 43036B is of type BusinessTransactionDocumentParty43040B. There is one 43038B VendorParty entity 43036B for eachProductActivity entity 43032A.

The BuyerParty entity 43078A includes an InternalID 43090A, a StandardID43000B, a BuyerID 43012B, and a VendorID 43024B. The InternalID 43090Ais of type PartyInternalID 43094A. The StandardID 43086A is of typePartyStandardID 43004B. The BuyerID 43096A is of type PartyPartyID43016B. The VendorID 43006B is of type PartyPartyID 43028B. In oneimplementation, for each ProductActivity entity 43032A, there is one orzero 43092A InternalID 43090A, any number 43092A of StandardIDs 43000B,one or zero 43014B BuyerID 43012B, and one or zero 43026B VendorID43024B.

The VendorParty entity 43036B includes an InternalID 43048B, aStandardID 43058B, a BuyerID 43070B, and a VendorID 43082B. TheInternalID 43048B is of type PartyInternalID 43052B. The StandardID43058B is of type PartyStandardID 43062B. The BuyerID 43070B is of typePartyPartyID 43074B. The VendorID 43082B is of type PartyPartyID 43086B.In one implementation, for each ProductActivity entity 43032A, there isone or zero 43050B InternalID 43048B, any number 43060B of StandardIDs43058B, one or zero 43072B BuyerID 43070B, and one or zero 43084BVendorID 43082B.

The BusinessTransactionDocumentRequest package 43074A includes anInboundDeliveryReference entity 43094B of typeBusinessTransactionDocumentReference 43098B. There is any number 43096Bof InboundDeliveryReference entities 43094B for each ProductActivityentity 43032A.

The Item package 43076A includes an Item entity 43012C of typeProductActivityItem 43016C. There is one or more 43004C of Item entities43012C for each ProductActivity entity 43032A. The Item package 43076Aalso includes a Location package 43022C, a ProductInformation package42924C, and an Inventory package 42926C.

The Location package 43022C includes a ShipFromLocation entity 43028Cand a ShipToLocation entity 43086C. The ShipFromLocation entity 43028Cis of type BusinessTransactionDocumentShipFromLocation 43032C. There isone or zero 43030C ShipFromLocation entity 43028C for each Item entity43012C. The ShipToLocation entity 43086C is of typeBusinessTransactionDocumentLocation 43090C. There is one 43088CShipToLocation entity 43086C for each Item entity 43012C.

The ShipFromLocation entity 43028C includes an InternalID 43040C, aStandardID 43050C, a BuyerID 43062C, and a VendorID 43074C. TheInternalID 43040C is of type LocationInternalID 43044C. The StandardID43050C is of type of LocationStandardID 43054C. The BuyerID 43062C is oftype LocationPartyID 43066C. The VendorID 43074C is of typeLocationPartyID 43078C. In one implementation, for each ShipFromLocationentity 43028C, there is one or zero 43042C InternalID 43040C, one orzero 43052C StandardID 43050C, one or zero 43064C BuyerID 43062C, andone or zero 43076C VendorID 43074C.

The ShipToLocation entity 43086C includes an InternalID 43098C, aStandardID 43008D, a BuyerID 43020D, and a VendorID 43032D. TheInternalID 43098C is of type LocationInternalID 43002D. The StandardID43008D is of type of LocationStandardID 43012D. The BuyerID 43020D is oftype LocationPartyID 43024D. The VendorID 43032D is of typeLocationPartyID 43036D. In one implementation, for each ShipFromLocationentity 43028C, there is one or zero 43000D InternalID 43098C, one orzero 43010D StandardID 43008D, one or zero 43022D BuyerID 43020D, andone or zero 43034D VendorID 43032D.

The ProductInformation package 43024C includes a Product entity 43044Dof type BusinessTransactionDocumentProduct 43048D. There is one 46DProduct entity 43044D for each Item entity 43012C.

The Product entity 43044D includes an InternalID 43056D, a StandardID43066D, a BuyerID 43078D, a VendorID 43090D, a PackageQuantity 43002E,and a DiscontinuationIndicator 43012E. The InternalID 43056D is of typeProductInternalID 43060D. The StandardID 43066D is of type ofProductStandardID 43070D. The BuyerID 43078D is of type ProductPartyID43082D. The VendorID 43090D is of type ProductPartyID 43094D. ThePackageQuantity 43002E is of type Quantity 43006E. TheDiscontinuationIndicator 43012E is of typeProductDiscontinuationIndicator 43016E. In one implementation, for eachProduct entity 43044D, there is one or zero 43058D InternalID 43056D,one or zero 43068D StandardID 43066D, one or zero 43080D BuyerID 43078D,one or zero 43092D VendorID 43090D, one or zero 43004E PackageQuantity43002E, and one or zero 43014E DiscontinuationIndicator 43012E.

The Inventory package 42926C includes an Inventory entity 43020E of typeProductActivityItemInventory 43024E and a ConsigmentInventory entity43082E of type ProductActivityItemInventory 43086E. There is one or zero43022D Inventory entity 43020E for each Item entity 43012C and one orzero 43022D ConsignmentInventory entity 43082E for each Item entity43012C.

The Inventory entity 43020E includes a VendorDependent Indicator 43023D,a StatusDateTime 43030E of type DateTime 43034E, anUnrestrictedUseQuantity 43040E of type Quantity 43044E, aQuanlityInspectionQuantity 43052E of type Quantity 43056E, aBlockedQuantity 43062E of type Quantity 43066E, and a PromotionQuantity43072E of type Quantity 43076E. The VendorDependent Indicator 43023D hasa cardanality of zero or one 43025D, and the type is GDT. In oneimplementation, for each Inventory entity 43020E, there is one or zero43032E StatusDateTime 43030E, one or zero 43042E UnrestrictedUseQuantity43040E, one or zero 43054E QuanlitylnspectionQuantity 43052E, one orzero 43064E BlockedQuantity 43062E, and one or zero 43072EPromotionQuantity 43072E.

The ConsignmentInventory entity 43082E includes a StatusDateTime 43090Eof type DateTime 43094E, an UnrestrictedUseQuantity 43098E of typeQuantity 43002F, a QuanlitylnspectionQuantity 43008F of type Quantity43012F, a BlockedQuantity 43018E of type Quantity 43022F, and aPromotionQuantity 43028F of type Quantity 43032F. In one implementation,for each ConsignmentInventory entity 43082E, there is one or zero 43092EStatusDateTime 43090E, one or zero 43000F UnrestrictedUseQuantity43098E, one or zero 43010F QuanlitylnspectionQuantity 43008F, one orzero 43020E BlockedQuantity 43018E, and one or zero 43030FPromotionQuantity 43028F.

The Item entity 43012C includes a SalesTimeSeries 43038F, aPromotionSalesTimeSeries 43076F, a SalesForecastTimeSeries 43008G, aPromotionSalesForecastTimeSeries 43040G, an OrderForecastTimeSeries43072G, a PromotionOrderForecastTimeSeries 43010H, aConsumptionTimeSeries 43042H, a ConsumptionForecastTimeSeries 43074H, anOnOrderTimeSeries 43006I, and an OutofStockTimeSeries 43038I. TheSalesTimeSeries 43038F is of type QuantityTimeSeries 43042F. ThePromotionSalesTimeSeries 43076F is of type QuantityTimeSeries 43080F.The SalesForecastTimeSeries 43008G is of type QuantityTimeSeries 43012G.The PromotionSalesForecastTimeSeries 43040G is of typeQuantityTimeSeries 43044G. The OrderForecastTimeSeries 43072G is of typeQuantityTimeSeries 43076G. The PromotionOrderForecastTimeSeries 43010His of type QuantityTimeSeries 43014H. The ConsumptionTimeSeries 43042His of type QuantityTimeSeries 43046H. The ConsumptionForecastTimeSeries43074H is of type QuantityTimeSeries 43078H. The OnOrderTimeSeries43006I is of type QuantityTimeSeries 43010I. The OutofStockTimeSeries43038I is of type QuantityTimeSeries 43042I. In one implementation, foreach Item entity 43012C, there is one or zero 43040F SalesTimeSeries43038F, one or zero 43078F PromotionSalesTimeSeries 43076F, one or zero43010G SalesForecastTimeSeries 43008G, one or zero 43042GPromotionSalesForecastTimeSeries 43040G, one or zero 43074GOrderForecastTimeSeries 43072G, one or zero 43012HPromotionOrderForecastTimeSeries 43010H, one or zero 43044HConsumptionTimeSeries 43042H, one or zero 43076HConsumptionForecastTimeSeries 43074H, one or zero 43008IOnOrderTimeSeries 43006I, and one or zero 43040I OutofStockTimeSeries43038I.

The SalesTimeSeries 43038F includes any number 43050F of SalesTimeSeriesItems 43048F. Each SalesTimeSeries Item 43048F includes one 43058FValidityPeriod 43056F of type DateTimePeriod 43060F and one 43068FQuantity 43066F of type Quantity 43070F.

The PromotionSalesTimeSeries 43076F includes any number 43078F ofPromotionSalesTimeSeries Items 43086F. Each PromotionSalesTimeSeriesItem 43086F includes one 43094F ValidityPeriod 43092F of typeDateTimePeriod 43098F and one 43000G Quantity 43000G of type Quantity43004G.

The SalesForecastTimeSeries 43008G includes any number 43020G ofSalesForecastTimeSeries Items 43018G. Each SalesForecastTimeSeries Item43018G includes one 43026G ValidityPeriod 43024G of type DateTimePeriod43028G and one 43034G Quantity 43032G of type Quantity 43036G.

The PromotionSalesForecastTimeSeries 43040G includes any number 43052Gof PromotionSalesForecastTimeSeries Items 43050G. EachPromotionSalesForecastTimeSeries Item 43050G includes one 43058GValidityPeriod 43056G of type DateTimePeriod 43060G and one 43066GQuantity 43064G of type Quantity 43068G.

The OrderForecastTimeSeries 43072G includes any number 43084G ofOrderForecastTimeSeries Items 43082G. Each OrderForecastTimeSeries Item43082G includes one 43092G ValidityPeriod 43090G of type DateTimePeriod43094G and one 43002H Quantity 43000H of type Quantity 43004H.

The PromotionOrderForecastTimeSeries 43010H includes any number 43022Hof PromotionOrderForecastTimeSeries Items 43020H. EachPromotionOrderForecastTimeSeries Item 43020H includes one 43028HValidityPeriod 43026H of type DateTimePeriod 43030H and one 43036HQuantity 43034H of type Quantity 43038H.

The ConsumptionTimeSeries 43042H includes any number 43054H ofConsumptionTimeSeries Items 43052H. Each ConsumptionTimeSeries Item43052H includes one 43060H ValidityPeriod 43058H of type DateTimePeriod43062H and one 43068H Quantity 43066H of type Quantity 43070H.

The ConsumptionForecastTimeSeries 43074H includes any number 43086H ofConsumptionForecastTimeSeries Items 43084H. EachConsumptionForecastTimeSeries Item 43084H includes one 43092HValidityPeriod 43090H of type DateTimePeriod 43094H and one 43000IQuantity 43098H of type Quantity 43002H.

The OnOrderTimeSeries 43006I includes any number 43018I ofOnOrderTimeSeries Items 43016I. Each OnOrderTimeSeries Item 43016Iincludes one 43024I ValidityPeriod 43022I of type DateTimePeriod 43026Iand one 43032I Quantity 43030I of type Quantity 43034I.

The OutofStockTimeSeries 43038I includes any number 43050I ofOutofStockTimeSeries Items 43048I. Each OutofStockTimeSeries Item 43048Iincludes one 43058I ValidityPeriod 43056I of type DateTimePeriod 43060Iand one 43068I Quantity 43066I of type Quantity 43070I.

w) Payment Due Interface

FIG. 431 depicts the message choreography for Payment Due Notificationbetween to business entities, Invoice/Billing 43102 and Payment 43104.

The motivating business scenarios for the Payment Due Notification arethe Procure to Stock and Sell from Stock (SFS) scenarios. After anincoming invoice is checked in BAC Invoicing, a message is sent to BACPayment, generating an open payable there and thus triggering thesubsequent payment process. Similarly, when a billing document is sentin BAC Billing, a message is sent to BAC Payment, generating an openreceivable item there and thus enabling the assignment of incomingpayments.

(1) Message Type Payment Due Notification

A PaymentDueNotification 43106 notifies an application (paymentregister), in which subsequent operative processing of payments takesplace, about due dates (accounts receivable and accounts payable) ofbusiness partners. The message type PaymentDueNotification 43106 isbased on the message data type PaymentDueMessage 43200, which isdisclosed more fully in FIG. 432.

The PaymentDueNotification 43106 is used for checking an incominginvoice, creating an outgoing invoice, checking an incoming credit memo,and creating an outgoing credit memo. On receipt of a due date (accountsreceivable and accounts payable) in the payment register, one or moreopen due date items are generated. These open items form the basis forthe following process steps: (1) Clearing a business partner'sreceivables and payables; (2) A bank's payment orders; (3) Paymentcollections; (4) Assigning an incoming payment (account statement) to areceivable; (5) Dunning notices/reminders; and (6) Dispute management.

The creation and checking of an incoming invoice in Invoicing 43102 isindependent of the processing of payables for payment in Payment 43104.Payables are also generated from credit memos for outgoing invoices(billing documents). Receivables are generated through the shipment of abilling document in Billing 43102 or a credit memo in Invoicing 43102.If the invoice is incorrect, for instance wrong amounts, a new invoiceor credit memo is generally generated by Billing 43102 or received byInvoicing 43102 to correct the error. The sequence of messages sent toPayment 43104 is irrelevant for Payment 43104. If a reverse function isimplemented in Invoicing 43102 or Billing 43102, for example to let theaccounting clerk reverse an incorrect entry in an incoming invoice, thisreversal can be notified to Payment 43104 with thePaymentDueCancelNotification 43108 message. This message is thenprocessed by Payment 43104 after the related PaymentDueNotification43106. As this is not a typical situation, serialization is notrequired. The reversal function and the PaymentDueCancelNotification43108 message are not planned to be implemented initially; serializationcan be avoided by tolerant coding in Payment 43104.

(2) Message Data Type Data Model

The complete data model for the Payment Due Notification is depicted inFIG. 432. The message data type PaymentDueMessage 43200 includes thePaymentDue Message entity 43202 included in the business document andthe business information that is relevant for sending a businessdocument in a message. The message data type PaymentDueMessage 43200also includes a MessageHeader package 43204, and a PaymentDue package43206. The message data type PaymentDueMessage 43200 makes the structureavailable for the message type PaymentDue and the relevant interfaces.

(a) Message Header Package

A MessageHeader package 43204 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader 43204 is not required for PaymentDueNotification 43106. Aninvoice or credit memo is transferred to Payment 43104 once. A messageID is not required since the reference can always be established withthe ID of the invoice or credit memo. At most, the sender is known asthe “system ID.” The recipient is not known; Invoice and Billing 43102know that this message is to be sent to the Payment 43104 applicationthat is responsible for the payment process for the payment sender andpayment recipient.

(b) Payment Due Package

The PaymentDue package 43206 groups together all the information that isrequired to generate due dates in a payment register. It includes aPayment Due entity 43208, a Party package 43210, aBusinessTransactionDocumentReference package 43212, and an Item package43214.

(i) Payment Due Entity

PaymentDue entity 43208 indicates the type of due payments (for paymentor expected) and their amounts. There is a 1:1 relationship 43209between the PaymentDue entity 43208 and PaymentDueMessage 43202. Foreach invoice or credit memo that is uniquely identified as the basebusiness document, PaymentDue entity 43208 receives one or more due dateitem (PaymentDueItems 43216; see below) with details of the type andamount of the payment due, the payment terms and the business partnersinvolved.

PaymentDue 43208 includes a BaseBusinessTransactionDocumentID, aBaseBusinessTransactionDocumentTypeCode, and aBaseBusinessTransactionDocumentDate. TheBaseBusinessTransactionDocumentID is the identification of the businessdocument or source document on which the due date is based, and is oftype GDT: BusinessTransactionDocumentID. TheBaseBusinessTransactionDocumentTypeCode is the coded representation ofthe previously named business document or source document. Invoice andVendorInvoice are to be considered here. TheBaseBusinessTransactionDocumentTypeCode is of type GDT:BusinessTransactionDocumentTypeCode. TheBaseBusinessTransactionDocumentDate is the date of the business documentor source document on which the due date is based, and is of type GDT:Date.

(ii) Party package

The Party package 43210 is a grouping of all business parties that maybe involved in a due payment. It includes a PayerParty entity 43218, aPayeeParty entity 43220, a DebtorParty entity 43222, and a CreditorPartyentity 43224. Default logic is used for all business partners: businesspartners who are specified at header level are used for all the itemsfor which a corresponding partner is not explicitly transferred.

(a) Payer Party Entity

PayerParty entity 43218 (payment sender or payer) is a company or aperson that pays for goods or services. PayerParty entity 43218 is oftype GDT: BusinessTransactionDocumentParty, but includes the InternalIDelement. There is a 1:1 relationship 43219 between PaymentDue entity43208 and PayerParty entity 43218. No other elements are required sincethe master data exists in the sender and receiver system to be able tooperate correctly. PayerParty entity 43218 is always filled. The paymentsender is always mapped in this business partner role. The role ofPayerParty entity 43218 is known to CRM Billing (payer); in SRM InvoiceVerification the payer party is the buying company (BuyerParty).

(b) Payee Party Entity

PayeeParty entity 43220 (payee) is a company or a person that receivespayment for goods or services. PayeeParty entity 43220 is of type GDT:BusinessTransactionDocumentParty, but includes the InternalID element.There is a 1:1 relationship 43221 between PaymentDue entity 43208 andPayeeParty entity 43220. No other elements are required since the masterdata exists in the sender and receiver system to be able to operatecorrectly. PayeeParty entity 43220 is always filled. The payee is alwaysmapped in this business partner role. The role of payee is known to SRM;in CRM Billing the payee is the billing unit.

(c) Debtor Party Entity

DebtorParty entity 43222 (customer, debtor) is the owner of payables.DebtorParty entity 43222 is of type GDT:BusinessTransactionDocumentParty, but includes the InternalID element.There is a 1:c relationship 43223 between PaymentDue entity 43208 andDebtorParty entity 43222. No other elements are required since themaster data exists in the sender and receiver system to be able tooperate correctly. One does not have to specify DebtorParty 43222. IfDebtorParty entity 43222 is not filled, the payment sender (payer,BillFromParty) and DebtorParty entity 43222 (debtor) are identical. Foran incoming invoice or credit memo, the buying company (BuyerParty) ismapped in this business partner role if it is different from the paymentsender. For an outgoing invoice or credit memo, the sold-to party ismapped in this business partner role if it is different from the paymentsender.

(d) Creditor Party Entity

CreditorParty entity 43224 (vendor, creditor) is the owner of thereceivables. CreditorParty entity 43224 is of type GDT:BusinessTransactionDocumentParty, but includes the InternalID element.There is a 1:c relationship 43225 between PaymentDue entity 43208 andCreditorParty entity 43224. No other elements are required since themaster data exists in the sender and receiver system to be able tooperate correctly. One does not have to specify CreditorParty entity43224. If CreditorParty entity 43224 is not specified, the payee andCreditorParty 43224 (vendor) are identical. For an incoming invoice orcredit memo, the vendor is mapped in this business partner role if thevendor is different from the payee. For an outgoing invoice or creditmemo, the billing unit is mapped in this business partner role if thebilling unit is different from the payee.

(iii)Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 43212 groups all thereferences to business documents on which the due payments are based. Itincludes an OriginInvoiceReference entity 43226, anOriginVendorInvoiceReference entity 43228, and an InvoiceReferenceentity 43230.

(a) Origin Invoice Reference entity

OriginInvoiceReference entity 43226 is the reference to an outgoinginvoice for which the business document or primary entry on which thecurrent due date is based is a follow-up document.OriginInvoiceReference entity 43226 is of type GDT:BusinessTransactionDocumentParty, but includes the Element ID. There isa 1:c relationship 43227 between PaymentDue entity 43208 andOriginInvoiceReference entity 43226. The ItemID element is not requiredsince reference is made to the document and not to an item.OriginInvoiceReference entity 43226 is filled if the document on whichthe current due date is based (BaseBusinessTransactionDocument) is afollow-on document to an outgoing invoice. An OriginInvoiceReferenceentity 43226 may be the original invoice number of a current creditmemo.

(b) Origin Vendor Invoice Reference Entity

OriginVendorInvoiceReference entity 43228 is the reference to anincoming invoice for which the business document or primary entry onwhich the current due date is based is a follow-up document.OriginVendorInvoiceReference entity 43228 is of type GDT:BusinessTransactionDocumentReference, but includes the Element ID. Thereis a 1:c relationship 43229 between PaymentDue entity 43208 and OriginVendor Invoice Reference entity 43228. The ItemID element is notrequired since reference is made to the document and not to an item.OriginVendorInvoiceReference entity 43228 is filled if the document onwhich the current due date is based (BaseBusinessTransactionDocument) isa follow-on document to an incoming invoice. AnOriginVendorInvoiceReference entity 43228 may be the original invoicenumber of a current credit memo.

(c) Invoice Reference Entity

InvoiceReference entity 43230 is the reference to the invoice of theinvoicing party. InvoiceReference 43230 is of type GDT:BusinessTransactionDocumentReference, but includes the Element ID. Thereis a 1:c relationship 43231 between PaymentDue entity 43208 and InvoiceReference entity 43230. The ItemID element is not required sincereference is made to the document and not to an item. For incominginvoices, InvoiceReference entity 43230 is filled since the paymentrefers to this information. For incoming invoices, the ID of theincoming invoice (VendorInvoice) assigned by Invoicing is used inBaseBusinessTransactionDocumentID and not the ID of the invoice assignedby the invoicing party. For outgoing invoices, the payment referencesthe invoice number included in this case inBaseBusinessTransactionDocumentID, and InvoiceReference entity 43230need not be filled.

(iv) Payment Due Item Package

The PaymentDueItem package 43214 is a grouping of all information on asingle due date item (receivable or payable). It includes aPaymentDueItem entity 43216, a PaymentInformation package 43232 and aParty package 43224.

(a) Payment Due Item Entity

PaymentDueItem entity 43216 describes a due date item (receivable orpayable). A PaymentDueItem entity 43216 can contain additional detailson payment terms and participating business partners as well as the typeand amount of payment due. PaymentDueItem entity 43216 includes anAmount, a PaymentCurrency, a FixedExchangeRate, and a Group ID. TheAmount is the amount to be paid in transaction currency (invoicecurrency). Incoming invoices and credit memos (document type “101VendorInvoice”) are treated as payables, in other words a positiveamount means increased payables and a negative amount means decreasedpayables. Outgoing invoices and credit memos (document type “102Invoice”) are treated as receivables, in other words a positive amountmeans increased receivables and a negative amount means decreasedreceivables. The Amount is of type GDT: Amount. The PaymentCurrency isthe payment currency, if it is different from the transaction currency,and is of type GDT: CurrencyCode. The FixedExchangeRate is used if afixed exchange rate has been specified for payments in differentcurrencies. The FixedExchangeRate is of type GDT: ExchangeRate. TheGroup ID is the payment grouping that groups multiple due date itemsfrom different PaymentDueNotifications into one payments (if thisgrouping is to be determined by Invoicing or Billing), and is of typeGDT: BusinessTransactionDocumentItemGroupID. There is a 1:n relationship43215 between PaymentDue entity 43208 and PaymentDueItem entity 43216.

(b) Payment Information Package

The PaymentInformation package 43232 is a grouping of all paymentmethods on a due date item. It includes a CashDiscountTerms entity43236, which includes the payment conditions, and a PaymentForm entity43238, which is the payment form.

(i) Cash Discount Terms entity

CashDiscountTerms entity 43236 includes the payment conditions of thedue date item. CashDiscountTerms entity 43236 is of type GDT:CashDiscountTerms. There is a 1:1 relationship 43237 betweenPaymentDueItem entity 43216 and CashDiscountTerms entity 43236.CashDiscountTerms entity 43236 is always specified. ThePaymentBaselineDate element is mandatory.

(ii) Payment Form Entity

PaymentForm entity 43238 is the way in which due date items are paid.This includes credit card details as well as the actual form of payment(invoice, collection, credit card . . . ). PaymentForm entity 43238 isof type GDT: PaymentForm. There is a 1:c relationship 43239 betweenPaymentDueItem entity 43216 and PaymentForm entity 43238. If PaymentFormentity 43238 is not specified, the payment form stored in the masterdata of the business partner applies.

(c) Party Package

The Party package 43234 is a grouping of all business parties that maybe involved in the due payment of an item. It includes a PayerPartyentity 43240 and a PayeeParty entity 43242. The PaymentDueItemPartypackage 43234 is optional and overrides the header details.

(i) Payer Party Entity

PayerParty entity 43240 is the party who pays for the due items.PayerParty entity 43240 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 43241between PaymentDueItem entity 43216 and PayerParty entity 43240.PayerParty entity 43240 includes an InternalID, which is of type GDT:PartyID.

(ii) Payee Party Entity

PayeeParty entity 43242 is the party who receives payment for the dueitems. PayeeParty entity 43242 is of type GDT:BusinessTransactionDocumentParty. There is a 1:c relationship 43243between PaymentDueItem entity 43216 and PayeeParty entity 43242.

(3) Message Data Type Element Structure

FIG. 433 depicts the element structure for Payment Due Notification. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 43300 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 433, the interface for Payment Due Notificationincludes five levels 43302, 43304, 43306, 43308, and 43310. Theoutermost package of this interface is a PaymentDueMessage package43320, which includes a PaymentDueMessage entity 43322 at the firstlevel 43302. The PaymentDueMessage entity 43322 is of type message datatype (“MDT”) 43324 “PaymentDueMessage” 43326.

Referring to FIG. 433, the PaymentDueMessage package 43320 includes aPaymentDue package 43328. The PaymentDue package 43328 includes aPaymentDue entity 43330 at the second level 43304 and the followingpackages: a Party package 43362, a BusinessTransactionDocumentReference43364, and an Item package 43366.

The PaymentDue entity 43330 is of type AGDT 43334 “PaymentDue” 43336.There is one 43332 PaymentDue entity 43330 for each PaymentDue package43328.

The PaymentDue entity 43330 includes a BaseBusinessTransactionDocumentIDentity 43338, a BaseBusinessTransactionDocumentCode entity 43346, and aBaseBusinessTransactionDocumentDate entity 43354 at the third level43306. The BaseBusinessTransactionDocumentID entity 43338 is of typeBGDT 43342 “BaseBusinessTransactionDocumentID” 43344. There is one 43340BaseBusinessTransactionDocumentID entity 43338 for each PaymentDueentity 43330. The BaseBusinessTransactionDocumentCode entity 43346 is oftype BGDT 43350 “BaseBusinessTransactionDocumentCode” entity 43352.There is one 43348 BaseBusinessTransactionDocumentCode entity 43346 foreach PaymentDue entity 43330. The BaseBusinessTransactionDocumentDateentity 43354 is of type BGDT 43358 “Date” 43360. There is one 43356BaseBusinessTransactionDocumentDate entity 43354 for each PayrnentDueentity 43330.

Referring to FIG. 433, Party package 43362 includes four entities at thethird level 43306: a PayerParty entity 43368, a PayeeParty entity 43384,a DebtorParty entity 43300A, and a CreditorParty entity 43316A.PayerParty entity 43368 is of the type AGDT 43372,“BusinessTransactionDocumentParty” 43374. There is one 43370 PayerPartyentity 43368 for each Party package 43362. PayerParty entity 43368includes an InternalID entity 43376 at the fourth level 43308. TheInternalID entity 43376 is of the type BGDT 43380 “PartyIID” 43382.There is one 43378 InternalID entity 43376 for each PayerParty entity43368.

The PayeeParty entity 43384 is of the type AGDT 43388,“BusinessTransactionDocumentParty” 43390. There is one 43386 PayeePartyentity 43384 for each Party package 43362. PayeeParty entity 43384includes an InternalID entity 43392 at the fourth level 43308. TheInternalID entity 43392 is of the type BGDT 43396 “PartyID” 43398. Thereis one 43394 InternalID entity 43392 for each PayeeParty entity 43384.The DebtorParty entity 43300A is of the type AGDT 43304A,“BusinessTransactionDocumentParty” 43306A. There is zero or one 43302ADebtorParty entity 43300A for each Party package 43362. DebtorPartyentity 43300A includes an InternalID entity 43308A at the fourth level43208. The InternalID entity 43308A is of the type BGDT 43312A “PartyID”43314A. There is one 43310A InternalID entity 43308A for eachDebtorParty entity 43300A.

The CreditorParty entity 43316A is of the type AGDT 43320A,“BusinessTransactionDocumentParty” 43322A. There is zero or one 43318ACreditorParty entity 43316A for each Party package 43362. CreditorPartyentity 43316A includes an InternalID entity 43324A at the fourth level43308. The InternalID entity 43324A is of the type BGDT 43328A “PartyID”43330A. There is one 43326A InternalID entity 43324A for eachCreditorParty 43316A.

Referring to FIG. 433, the BusinessTransactionDocumentReference package43364 includes an OriginInvoiceReference entity 43332A, anOriginVendorInvoiceReference entity 43348A, and an InvoiceReferenceentity 43364A at the third level 43306.

The OriginInvoiceReference entity 43332A is of the type AGDT 43336A,“BusinessTransactionDocumentReference” 43338A. There is zero or one43334A OriginInvoiceReference entity 43332A for eachBusinessTransactionDocumentReference package 43364.OriginInvoiceReference entity 43332A includes an ID entity 43340A at thefourth level 43308. The ID entity 43340A is of the type BGDT 43344A“BusinessTransactionDocumentID” 43346A. There is one 43342A ID entity43340A for each OriginInvoiceReference entity 43332A.

The OriginVendorInvoiceReference entity 43348A is of the type AGDT43352A, “BusinessTransactionDocumentReference” 43354A. There is zero orone 43350A OriginVendorInvoiceReference entity 43348A for eachBusinessTransactionDocumentReference package43364.OriginVendorInvoiceReference entity 43348A includes an ID entity 43356Aat the fourth level 43308. The ID entity 43356A is of the type BGDT43360A “BusinessTransactionDocumentID” 43362A. There is one 43358A IDentity 43356A for each OriginVendorInvoiceReference entity 43348A. TheInvoiceReference entity 43364A is of the type AGDT 43368A,“BusinessTransactionDocumentReference” 43370A. There is zero or one43366A InvoiceReference entity 43364A for eachBusinessTransactionDocumentReference package 43364. InvoiceReferenceentity 43364A includes an ID entity 43372A at the fourth level 43308.The ID entity 43372A is of the type BGDT 43376A“BusinessTransactionDocumentID” 43378A. There is one 43374A ID entity43372A for each InvoiceReference entity 43364A.

Referring to FIG. 433, the Item package 43366 includes an Item entity43380A at the third level 43306 and two packages: a PaymentInformationpackage 43320B and a Party package 43322B. The Item entity 43380A is ofthe type AGDT 43384A “PaymentDueItem” 43386A.

There is at least one 43382A Item entity 43380A for each Item package43366.

The Item entity 43380A includes an Amount entity 43388A, a PaymentCurrency entity 43396A, a Fixed Exchange Rate entity 43304B, and aGroupID entity 43312B at the fourth level 43308. The Amount entity43388A is of the type BGDT 43392A “Amount” 43394A. There is one 43390AAmount entity 43388A for each Item entity 43380A. The Payment Currentyentity 43396A is of the type BGDT 43300B “CurrencyCode” 43302B.

There is zero or one 43398A PaymentCurrency entity 43396A for each Itementity 43380A.

The Fixed Exchange Rate entity 43304B is of the type AGDT 43308B“ExchangeRate” 43310B. There is zero or one 43306B FixedExchangeRateentity 43304B for each Item entity 43380A. The GroupID entity 43312B isof the type BGDT 43316B “BusinessTransactionDocumentItemGroupID” 43318B.There is zero or one 43314B GroupID entity 43312B for each Item entity43380A.

Referring to FIG. 433, the PaymentInformation package 43320B includes aCashDiscountTerms entity 43324B and a PaymentFormCode 43332B at thefourth level 43308. The CashDiscountTerms entity 43324B is of a typeAGDT 43328B “CashDiscountTerms” 43330B. There is one 43326BCashDiscountTerrns entity 43324B for each PaymentInformation package43320B. The PaymentFormCode 43332B is of a type AGDT 43336B“PaymentFormCode” 43338B. There is zero or one 43334B PaymentFormCode43332B for each PaymentInformation package 43320B.

Referring to FIG. 433, the Party package 43322B includes a PayerPartyentity 43340B and a PayeeParty entity 43356B at the fourth level 43308.The PayerParty entity 43340B is of a type AGDT 43344B“BusinessTransactionDocumentParty” 43346B. There is zero or one 43342BPayerParty entity 43340B for each Party package 43322B. The PayerPartyentity 43340B includes an InternalID entity 43348B at the fifth level43310.

The InternalID entity 43348B is of the type BGDT 43352B “PartyID”43354B. There is one 43350B InternalID entity 43348B for each PayerPartyentity 43340B.

The PayeeParty entity 43356B is of the type AGDT 43360B“BusinessTransactionDocumentParty” 43362B. There is zero or one 43358BPayeeParty entity 43356B for each Party package 43322B.

x) Order ID Assignment Interface

The OrderIDAssignmentNotification message allows a buyer to assign avendor order numbers for identifying “purchase orders triggered by thevendor.” This situation occurs in business scenarios where companiesdelegate planning of replenishment deliveries to their vendors. Contraryto the standard ordering process, the purchase orders in these scenariosare created by the vendors themselves rather than being triggered by thebuyer.

This means that the buyer and vendor first agree on the purchase ordernumbers that are to be used.

The OrderIDAssignmentNotification message is exchanged between theexecution system of a sold-to party (buyer) and the InventoryCollaboration Hub (ICH) of a vendor as part of the “ResponsiveReplenishment (RR)” business scenario. In this scenario, the ICHperforms the “planning” function, while the customer's/buyer's backendsystem performs the “purchasing” function.

(1) Message Type Order ID Assignment NotificationOrderIDAssignmentNotification is a message that allows a buyer to assigna vendor order numbers for identifying “purchase orders triggered by thevendor.” The structure of the message type OrderIDAssignmentNotificationis specified in the message data type OrderIDAssignmentMessage. Methodsand systems consistent with the subject matter described herein use thepackage template for a BusinessTransactionDocument for an SCM MasterData depicted in FIG. 270B to derive the OrderIDAssignment interface.

(2) Message Choreography

FIG. 434 shows the message choreography that describes the possiblelogical sequence of the messages that may be used to realize thescenario.

A buyer 43402 can use an OrderIDAssignmentNotification message 43408 totransfer valid purchase order numbers to a vendor's “Supply ChainPlanning” system 43404 for creating replenishment orders. Thesereplenishment orders are transferred from the vendor's “Supply ChainPlanning” system 43404 to his “Supply Chain Execution” system 43406using a ReplenishmentOrderNotification message 43410. The “Supply ChainExecution” system 43406 checks the availability of the required productsand uses a ReplenishmentOrderConfirmation message 43412 to confirm thatthe replenishment orders have been fulfilled. The buyer 43402 is theninformed of this with a VendorGeneratedOrderNotification message 43414.The buyer 43402 can then send an optional order confirmation to thevendor using a VendorGeneratedOrderConfirmation message 43416. If thetwo business partners collaborate very closely, this order confirmationmight not be necessary. In this case, theVendorGeneratedOrderNotification creates a purchase order directly onthe buyer side.

(3) Order ID Assignment Message Message Data Type

FIG. 435 depicts a data model of an OrderIDAssignmentNotificationprocess. An OrderIDAssignmentMessage message package 43500 includes theOrderIDAssignment object in the business document and the businessinformation that is relevant for sending a business document in amessage. The OrderIDAssignmentMessage message package 43500 includes aMessageHeader package 43502, a OrderIDAssignment package 43504, and anOrderIDAssignmentMessage entity 43506. The OrderIDAssignmentMessagemessage package 43500 makes the structure available for the relevantmessage types and message interfaces.

(a) Message Header Package

The MessageHeader package 43502 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader package 43502 includes a MessageHeader entity 43508, aSenderParty entity 43512 and a RecipientParty entity 43514. There is a1:1 relationship 43510 between the OrderIDAssignmentMessage entity 43506and the Message Header entity 43508. There is a 1:c relationship 43516between the Message Header entity 43508 and the SenderParty entity43512. There is a 1:c relationship 43518 between the Message Headerentity 43508 and the RecipientParty entity 43514.

(i) Message Header

The MessageHeader entity 43508 groups together the business informationfrom the point of view of the sending application to identify thebusiness document in a message, to provide information about the sender,and to provide any information about the recipient.

The MessageHeader entity 43508 is divided into a SenderParty entity43512 and a RecipientParty entity 43514. The header is of type GDT:BusinessDocumentMessageHeader, and includes an ID that identifies thebusiness document in the technical message and a CreationDateTime, whichis the creation date of a business document in the technical message.

(ii) Sender Party

A SenderParty is the party responsible for sending a business documentat business application level. The SenderParty entity 43512 is of typeGDT: BusinessDocumentMessageHeaderParty.

(iii) Recipient Party

A RecipientParty is the party responsible for receiving a businessdocument at business application level. The RecipientParty entity 43514is of type GDT: BusinessDocumentMessageHeaderParty.

(b) Order ID Assignment Package

The OrderIDAssignment package 43504 groups the OrderIDAssignment and itspackages. The OrderIDAssignment package 43504 includes a Party package43520, an OrderIDAssignmentItem package 43522 and an OrderIDAssignmententity 43524. There is a 1:1 relationship 43526 between theOrderIDAssignmentMessage entity 43506 and the OrderIDAssignment entity43524.

(i) Order ID Assignment

An OrderIDAssignment represents an assignment of order numbers from abuyer to a vendor/seller or, more generally, from an ordering party toan agent. The OrderIDAssignment entity 43524 includes a description atitem level of the order numbers that can or should be used to identifyorders created by the seller for a specific combination of deliverylocation, marketing promotion, and purchasing group at the buyer. Atpresent, purchase orders are supported as the order category. In thefuture, however, production orders, stock transport orders, shipmentorders, and so on, will also be possible.

(ii) Party Package

The Party package 43520 groups the business partners that are relevantfor assigning order numbers. It includes a BuyerParty entity 43528 and aVendorParty entity 43530. There is a 1:1 relationship 43532 between theOrderIDAssignment entity 43524 and the BuyerParty entity 43528. There isa 1:1 relationship 43534 between the OrderIDAssignment entity 43524 andthe VendorParty entity 43530.

(a) Buyer Party

BuyerParty is the purchasing company that assigns the order numbers. TheBuyerParty entity 43528 is of type GDT:BusinessTransactionDocumentParty, where the StandardID, BuyerID, andVendorID are used. Either the StandardID or the partner-role-specific IDof the receiving partner is used. In other words, for SupplierCollaboration scenarios, use the BuyerID, and for Customer Collaborationscenarios, use the VendorID. Due to the different possibilities for IDuse, all ID elements of the particular “Party” are optional.

(b) Vendor Party

VendorParty is the delivering company to which the order numbers areassigned. The VendorParty entity 43530 is of type GDT:BusinessTransactionDocumentParty, where the StandardID, BuyerID, andVendorID are used.

(c) ProductRecipientParty

ProductRecipientParty 43089B includes an InternalID 43091B, a StandardID43099B, a PartyStandardID, and a BuyerID 43007C.

(iii) Order ID Assignment Item Package

The OrderIDAssignmentItem package 43522 groups the OrderIDAssignmentItemand its packages. It includes a Location package 43536, a Promotionpackage 43538, and an OrderIDAssignmentItem entity 43540. There is a 1:nrelationship 43542 between the OrderIDAssignment entity 43524 and theOrderIDAssignmentItem entity 43540.

The OrderIDAssignmentItem entity 43540 describes the order numbers thatare admissable and should be used to identify orders created by theseller for a specific combination of delivery location, marketingpromotion, and purchasing group at the buyer.

The OrderIDAssignmentItem entity 43540 includes a BuyerPurchasingGroupIDand a PurchaseOrderIDRange. The BuyerPurchasingGroupID is a uniqueidentifier for a group of purchasers at the buyer who are responsiblefor certain purchasing activities. In-house, the purchasing group isresponsible for procuring a particular product or class of products;externally, the group acts as a contact person for vendors. TheBuyerPurchasingGroupID is of type GDT: PurchasingGroupID. ThePurchaseOrderIDRange is the value range for permitted purchase ordernumbers with a FromID and a ToID. The FromID is the first purchase orderpermitted, and is of type GDT: BusinessTransactionDocumentID. The ToIDis the last purchase order permitted, and is of type GDT:BusinessTransactionDocumentID.

(iv) Location Package

The Location package 43536 groups the locations that are relevant forassigning order numbers. It includes a ShipToLocation entity 43544.There is a 1:c relationship 43546 between the OrderIDAssignment entity43540 and the ShipToLocation entity 43544.

The ShipToLocation is the place to which a product is to be delivered.ShipToLocation entity 43544 is of type GDT:BusinessTransactionDocumentShipToLocation, where the StandardID,BuyerID, and VendorID are used. Either the StandardID, BuyerID, orVendorID is used. Due to the different possibilities for ID use, all theID elements are optional.

(v) Promotion Package

The Promotion package 43538 groups all the data regarding marketingpromotions that are relevant for assigning order numbers. The Promotionpackage 43538 includes a Promotion entity 43548. There is a 1:crelationship 43550 between the OrderIDAssignmentItem entity 43540 andthe Promotion entity 43548.

Promotion includes data that identifies a marketing promotion that isplanned by the buyer for the product to be ordered. The Promotion entity43548 includes an InternalID, a BuyerID, and a VendorID. The InternalIDidentifies the marketing promotion (for communication within thecompany), and is of type GDT: PromotionInternalID. The BuyerIDidentifies the buyer of products for the marketing promotion, and is oftype GDT: PromotionPartyID. The VendoriD identifies the vendor ofproducts for the marketing promotion, and is of type GDT:PromotionPartyID.

(4) Element Structure for the Message Data Type

FIG. 436 depicts the element structure forOrderIDAssignmentNotification. The element structure identifies thedifferent packages 43600 in the interface, and represents the entitiesat various levels within the interface. As shown in FIG. 436, theinterface for OrderIDAssignmentNotification includes five levels 43602,43604, 43606, 43608, and 43610. The element structure identifies thecardinality 43612 of each element, provides a Data type name 43614 foreach element, and, where relevant, provides the length 43618 for anelement.

The outermost package of this interface is OrderIDAssignmentMessagepackage 43622, which includes an OrderIDAssignmentMessage entity 43624at the first level 43602. The OrderIDAssignmentMessage entity 43624 isof data type 43614 OrderIDAssignmentMessage 43626.

The OrderIDAssignmentMessage package 43622 includes a MessageHeaderpackage 43630 and an OrderIDAssignment package 43632. The MessageHeaderpackage 43630 includes a MessageHeader entity 43634 at the second level43604. The MessageHeader entity 43634 has a cardinality 43612 of one43636 and a data type 43614 BusinessDocumentMessageHeader 43638.

The MessageHeader entity 43634 includes an ID 43644, a ReferenceID43654, a CreationDateTime 43664, a SenderParty entity 43672, and aRecipientParty entity 43698 at the third level 43606. The ID 43644 has acardinality 43612 of one 43646, a data type 43614“BusinessDocumentMessageID 43648, and a length 43618 of 1 to 35 43650.The ReferenceID 43654 has a cardinality 43612 of zero or one 43656, adata type 43614 BusinessDocumentMessageID 43658 and a length 43618 of 1to 35 43660. The CreationDateTime 43664 has a cardinality 43612 of one43666 and a data type 43614 DateTime 43668. The Sender Party entity43672 has a cardinality 43612 of zero or one 43674 and a data type 43614BusinessDocumentMessageHeaderParty 43676. The RecipientParty entity43698 has a cardinality 43612 of zero or one 43600A and a data type43614 BusinessDocumentMessageHeaderParty 43602A.

The SenderParty entity 43672 includes an InternalID 43682 and aStandardID 43690 at the fourth level 43608. The InternalID 43682 has acardinality 43612 of zero or one 43684 and a data type 43614PartyInternalID 43686. The StandardID 43690 has a cardinality 43612 ofany number 43692 and a data type 43614 PartyStandardID 43694.

The RecipientParty entity 43698 includes an InternalID 43608A and aStandardID 43616A at the fourth level 43608. The InternalID 43608A has acardinality 43612 of zero or one 43610A and a data type 43614PartyInternalID 43612A. The StandardID 43616A has a cardinality 43612 ofany number 43618A and a data type 43614 PartyStandardID 43620A.

The OrderIDAssignment package 43632 includes an OrderIDAssignment entity43624A at the second level 43604, a Party package 43650A, and an Itempackage 43652A. The OrderIDAssignment entity 43624A has a cardinality43612 of one 43626A and a data type 43614 OrderIDAssignment 43628A. TheOrderIDAssignment entity 43624A includes an ID 43632A and aCreationDateTime 43642A at the third level 43606. The ID 43632A has acardinality 43612 of zero or one 43634A, a data type 43614BusinessTransactionDocumentID 43636A, and a length 43618 of 1 to 3543638A. The CreationDateTime 43642A has a cardinality 43612 of one43644A and a data type 43614 DateTime 43646A.

The Party package 43650A includes a BuyerParty entity 43654A and aVendorParty entity 43604B at the third level 43606. The BuyerPartyentity 43654A had a cardinality 43612 of one 43656A and a data type43614 BusinessTransactionDocumentParty 43658A. The VendorParty entity43604B had a cardinality 43612 of one 43606B and a data type 43614BusinessTransactionDocumentParty 43608B.

The Party package 43650A also includes a ProductRecipientParty entity43089B. The ProductRecipientParty entity 43089B includes an Internalentity 43091B, a StandardID entity 43099B, a BuyerID entity 43007C, anda VendorID 43015C. The InternalID entity 43091B with a cardinality ofzero or one 43093B, and a data type GDT 43095B and a namePartyInternalID 43097B. The StandardID entity 43099B may have any numberof cardinality 43001C, the data type is GDT 43003C, and the name isPartyStandardID 43005C. The BuyerID entity 43007C has a cardinality ofzero or one 43009C, the type is GDT 43011C, and the name is PartyPartyID43013C. The VendorID entity 43015C has a cardinality of zero or one43017C, the type is GDT 43019C, and the name is PartyPartyID 43021C.

The BuyerParty entity 43654A includes an InternalID 43664A, a StandardID43674A, a BuyerID 43684A, and a VendorID 43694A at the fourth level43608. The InternalID 43664A has a cardinality 43612 of zero or one43666A, a data type 43614 of PartyInternalID 43668A, and a length 43618of 1 to 20 43670A. The StandardID 43674A has a cardinality 43612 of anynumber 43676A, a data type 43614 PartyStandard ID 43678A, and a length43618 of 1 to 13 or 1 to 9 43680A. The BuyerID 43684A has a cardinality12 of zero or one 43686A, a data type 43614 PartyPartyID 43688A, and alength 43618 of 1 to 20 43690A. The VendorID 43694A has a cardinality43612 of zero or one 43696A, a data type 43614 PartyPartyID 43698A, anda length 43618 of 1 to 20 43600B.

The VendorParty entity 43604B includes an InternalID 43614B, aStandardID 43624B, a BuyerID 43634B, and a VendorID 43644B at the fourthlevel 43608. The InternalID 43614B has a cardinality 43612 of zero orone 43616B, a data type 43614 PartyInternalID 43618B, and a length 43618of 1 to 20 43620B. The StandardID 43624B has a cardinality 43612 of anynumber 43626B, a data type 43614 PartyStandardID 43628B, and a length43618 of 1 to 13 or 1 to 9 43630B. The BuyerID 43634B has a cardinality43612 of zero or one 43636B, a data type 43614 of PartyPartyID 43638B,and a length 43618 of 1 to 20 43640B. The VendorID 43644B has acardinality 43612 of zero or one 43646B, a data type 43614 PartyPartyID43648B, and a length 43618 of 1 to 20 43650B.

The Item package 43652A includes a Location package 43662B and aPromotion package 43664B, as well as a BuyerPurchasingGroupID 43656C anda PurchaseOrderIDRange 43666C at the fourth level 43608. The Itempackage 43652A also includes an Item entity 43654B at the third level43606. The Item entity 54B has a cardinality 43612 of at least one43656B and a data type 43614 OrderIDAssignmentItem 43658B.

The Location package 43662B includes a ShipToLocation entity 43666B atthe fourth level 43608. The ShipToLocation entity 43666B has acardinality 43612 of zero or one 43668B and a data type 43614BusinessTransactionDocumentShipToLocation 43670B. The ShipToLocationentity 43666B includes an InternalID 43676B, a StandardID 43686B, aBuyerID 43696B, and a VendorID 43606C at the fifth level 43610. TheInternalID 43676B has a cardinality 43612 of zero or one 43678B, a datatype 43614 LocationInternalID 43680B, and a length 43618 of 1 to 2043682B. The StandardID 43686B has a cardinality 43612 of any number43688B, a data type 43614 LocationStandardID 43690B, and a length 43618of 1 to 13 43692B. The BuyerID 43696B has a cardinality 43612 of zero orone 43698B, a data type 43614 LocationPartyID 43600C, and a length 43618of 1 to 20 43602C. The VendorID 43606C has a cardinality 43612 of zeroor one 43608C, a data type 43614 of LocationPartyID 43610C, and a length43618 of 1 to 20 43612C.

The Promotion package 43664B includes a Promotion entity 43616C at thefourth level 43608. The Promotion entity 43616C has a cardinality 43612of zero or one 43618C, a data type 43614 Promotion 43620C, and a length43618 of 1 to 35 43622C. The Promotion entity 43616C includes anInternalID 43626C, a BuyerID 43636C, and a VendorID 43646C at the fifthlevel 43610. The InternalID 43626C has a cardinality 43612 of zero orone 43628C, a data type 43614 PromotionInternalID 43630C, and a length43618 of 1 to 20 43632C. The BuyerID 43636C has a cardinality 43612 ofzero or one 43638C, a data type 43614 PromotionPartyID 43640C, and alength 43618 of 1 to 20 43642C. The VendorID 43646C has a cardinality43612 of zero or one 43648C, a data type 43614 PromotionPartyID 43650C,and a length 43618 of 1 to 20 43652C.

The BuyerPurchasingGroupID 43656C at the fourth level 43608 of the Itempackage 52A has a cardinality 43612 of zero or one 43658C, a data type43614 PurchasingGroupID 43660C, and a length 43618 of 1 to 20 43662C.

The PurchaseOrderIDRange 43666C at the fourth level 43608 of the Itempackage 52A has a cardinality 43612 of one 43668C and a data type 43614PurchaseOrderIDRange 43670C. The PurchaseOrderIDRange 43666C includes aFromID 43674C and a ToID 43684C at the fifth level 43610. The FromID43674C has a cardinality 43612 of one 43676C, a data type 43614 ofBusinessTransactionDocumentID 43678C, and a length 43618 of 1 to 3543680C. The ToID 43684C has a cardinality 43612 of one 43686C, a datatype 43614 BusinessTransactionDocumentID 43688C, and a length 43618 of 1to 35 43690C.

y) Product Demand Influencing-Event Interface

The ProductDemandlnfluencingEventNotification message is a notificationof an event that influences the demand. A ProductDemandInfluencingEventcan be a sporting event, school vacation, or a price change, forexample. Usually, however, it is probably a promotional event, that is,a promotion. A promotion is a marketing activity between consumer goodsindustry and retail in a limited timeframe to increase brand capital,mindshare, and market share, to boost sales volumes, or to position newproducts or product groups. For the EAN.UCC, the equivalent of thismessage is called a RetailEvent.

The ProductDemandlnfluencingEventNotification message is sent within theBusiness Scenarios “Responsive Replenishment” and “CollaborativePlanning, Forecasting, and Replenishment (CPFR)” in a cross-companyvariant from a buyer (retail company) to a vendor (consumer productsmanufacturer) or in a variant within a company from a system thatcreates promotions to a planning system, for example.

(1) Message Type Product Demand Influencing Event Notification

A ProductDemandInfluencingEventNotification is a notice about an eventthat influences the sale or demand of products. The structure of themessage type ProductDemandInfluencingEventNotification is specified bythe message data type ProductDemandInfluencingEventMessage. Methods andsystems consistent with the subject matter described herein use thepackage template for a BusinessTransactionDocument for an SCM MasterData depicted in FIG. 270B to derive the ProductDemandlnfluencingEventinterface.

(2) Message Choreography

FIG. 437 depicts a message choreography for an exemplary product demandinfluencing event notification process. The message choreography ofscenario “CPFR” describes the possible logical sequence of the messagetypes necessary for the scenario realization.

A buyer 43700 sends long to mid-term demand information that is relatedto an event to a vendor 43702 in the form of aProductDemandlnfluencingEventNotification message 43704. Together withproduct forecast information in a ProductForecastNotification message43706 sent by the buyer 43700, or with short-term incidental currentsales information in a ProductActivityNotification message 43708, thisinformation can be used by the vendor 43702 for the creation of aforecast for the product demand of the buyer 43700. In the case of acooperative settlement process between the buyer 43700 and vendor 43702,the vendor 43702 can send a revision of the product forecast (sent bythe buyer 43700) back to this buyer 43700 in aProductForecastRevisionNotification message 43710, and in turn, thebuyer 43700 can respond with an updated revision in a secondProductForecastRevisionNotification message 43712.

(3) Message Type Product Demand Influencing Event Message

FIG. 438 depicts the data model for an exemplary product demandinfluencing event notification. The message data typeProductDemandInfluencingEventMessage includes aProductDemandlnfluencingEventMessage package 43802 that includes theProductDemandInfluencingEvent object included in the business documentand the business information relevant for sending a business document ina message. ProductDemandlnfluencingEventMessage package 43802 includes aMessageHeader package 43804, a ProductDemandInfluencingEvent package43806, and a ProductDemandInfluencingEventMessage entity 43808. Themessage data type ProductDemandlnfluencingEventMessage provides thestructure for the message type ProductDemandlnfluencingEventNotificationand the relevant interfaces.

(a) Message Header Package

The MessageHeader package 43804 groups together the business informationthat is relevant for sending a business document in a message. Itincludes a MessageHeader entity 43810, a SenderParty entity 43814 and aRecipientParty entity 43816. There is a 1:1 relationship 43812 betweenthe ProductDemandInfluencingEventMessage entity 43808 and theMessageHeader entity 43810. There is a 1:c relationship 43818 betweenthe MessageHeader entity 43810 and the SenderParty entity 43814. Thereis a 1:c relationship 43820 between the MessageHeader entity 43810 andthe RecipientParty entity 43816.

(i) Message Header

A MessageHeader groups together the business information from theperspective of the sending application information to identify thebusiness document in a message, information about the sender, and anyinformation about the recipient. The MessageHeader entity 43810 isdivided into a SenderParty and a RecipientParty. It is of type GDT:BusinessDocumentMessageHeader. The MessageHeader entity 43810 includesan ID and a CreationDateTime.

(ii) Sender Party

A SenderParty is the party responsible for sending a business documentat business application level. The SenderParty entity 43814 is of typeGDT: BusinessDocumentMessageHeaderParty. InternalID and StandardID areused.

(iii) Recipient Party

A RecipientParty is the party responsible for receiving a businessdocument at business application level. The RecipientParty entity 43816is of type GDT: BusinessDocumentMessageHeaderParty. InternalID andStandardID are used.

(b) Product Demand Influencing Event Package

The ProductDemandlnfluencingEvent package 43806 groups together theProductDemandlnfluencingEvent with its packages. TheProductDemandlnfluencingEvent package 43806 includes a Party package43822, a Scheduling package 43824, a ProductDemandlnfluencingEventItempackage 43826 and a ProductDemandInfluencingEvent entity 43828. There isa 1:1 relationship 43830 between theProductDemandlnfluencingEventMessage entity 43808 and theProductDemandlnfluencingEvent entity 43828.

(i) Product Demand Influencing Event

A ProductDemandlnfluencingEvent describes a demand influencing event andits effects on the demand. The ProductDemandInfluencingEvent entity43828 specifies event dates (see Scheduling Package) and participatingbusiness partners. The ProductDemandlnfluencingEvent entity 43828 isdivided into items (see ProductDemandInfluencingEventItem Package) thateach contain the effects of the event on the expected sales quantitieswith regard to a ship-to party location and a product.

The ProductDemandlnfluencingEvent entity 43828 includes an InternalID, aBuyerID, a VendorID, a Name, a TypeCode, a StatusCode, a Recurrence, aPlanningPeriod, an ExecutingPeriod, an AdvertisementPeriod, and a Note.The InternalID is of type GDT: BusinessTransactionDocumentID, and is theproprietary identifier for the event that is used when both sender andrecipient can access shared master data (extended enterprise). TheBuyerID is of type GDT: BusinessTransactionDocumentID, and is theidentifier that is used by the BuyerParty for this event. The VendorIDis of type GDT: BusinessTransactionDocumentID, and is the identifierthat is used by the VendorParty for this event. The Name is of type GDT:Name, and is the name of the event. The TypeCode is of type GDT:ProductDemandlnfluencingEventTypeCode, and specifies the type of event(for example, SportEvent). The StatusCode is of type GDT:ProductDemandlnfluencingEventStatusCode, and specifies the status of theevent (for example, Active, Completed, and so on). The Recurrence oftype GDT: Recurrence, and specifies the frequency of periodicallyrecurring events. The PlanningPeriod is of type GDT: DateTimePeriod, andis the period in which the event is planned. The ExecutingPeriod is oftype GDT: DateTimePeriod, and is the period in which the event takesplace. The AdvertisementPeriod is of type GDT: DateTimePeriod, and isthe period in which the event is advertised. The Note is of type GDT:Note, and is a language-independent note.

(ii) Party Package

The Party package 43822 groups together the business partners betweenwhich the marketing activity (event) is to take place. The Party package43822 includes a BuyerParty entity 43832 and a VendorParty entity 43834.There is a 1:1 relationship 43836 between theProductDemandlnfluencingEvent entity 43828 and the BuyerParty entity43832. There is a 1:1 relationship 43838 between theProductDemandInfluencingEvent entity 43828 and the VendorParty entity43834.

For communication within the company (with common master data), use theInternalID for all party entity types. For cross-company communication(with business-partner-specific master data), use for all party entitytypes either the StandardID or the partner-role-specific ID of thereceiving partner, for example, for Supplier Collaboration scenarios,use the BuyerID, and for Customer Collaboration scenarios, use theVendorID. Due to the different possibilities for ID use, all ID elementsof the particular party are optional.

(a) Buyer Party

A BuyerParty is the purchasing company. The BuyerParty entity 43832 isof type GDT: BusinessTransactionDocumentParty, where the InternalID, theStandardID, the BuyerID, and the VendorID are used.

(b) Vendor Party

A VendorParty is the delivering company. The VendorParty entity 43834 isof type GDT: BusinessTransactionDocumentParty, where the InternalID, theStandardID, the BuyerID, and the VendorID are used. For a scenariowithin the company, it is not a requirement to specify the businesspartner in the message; hence both party entity types are optional.

(iii) Scheduling Package

The Scheduling package 43824 groups together specifications on timeintervals that are relevant for the event. The Scheduling package 43824includes a Scheduling entity 438408. There is a 1:c relationship 43842between the ProductDemandlnfluencingEvent entity 43828 and theScheduling entity 43840.

A Scheduling groups together time intervals in order to define aschedule for ordering, delivering, and/or picking up the productsaffected by the event.

The Scheduling entity 43840 includes an OrderingPeriod, aDistributionCenterReceiptPeriod, a DistributionCenterIssuePeriod, aStoreReceiptPeriod, and a PickupPeriod. The OrderingPeriod is of typeGDT: DateTimePeriod, and is the period in which the purchase order isexpected. The DistributionCenterReceiptPeriod is of type GDT:DateTimePeriod, and is the period in which the goods are expected to bereceived at the distribution center. The DistributionCenterlssuePeriodis of type GDT: DateTimePeriod, and is the period in which the goods areexpected to be issued by the distribution center. The StoreReceiptPeriodis of type GDT: DateTimePeriod, and is the period in which the goods areexpected to be received at the shop. The PickupPeriod is of type GDT:DateTimePeriod, and is the period in which the goods are ready for pickup.

(iv) Product Demand Influencing Event Item Package

The ProductDemandlnfluencingEventItem package 43826 groups together theProductDemandInfluencingEventItem with its packages. TheProductDemandlnfluencingEventItem package 43826 includes a Locationpackage 43844, a ProductInformation package 43846, and Item 43848. Thereis a 1:n relationship 43850 between the ProductDemandlnfluencingEvententity 43828 and the Item entity 43848.

(a) Product Demand Invluencing Event Item

A ProductDemandlnfluencingEventItem specifies for a ship-from location(optional), a ship-to location, and a product the sales quantitiesexpected on the basis of the demand influencing event in the form of atime series. The ProductDemandlnfluencingEventItem 43848 includes aSalesForecastTimeSeries, an OrderForecastTimeSeries, and aPlannedSalesPriceTimeSeries. The SalesForecastTimeSeries is of type CDT:QuantityTimeSeries, and is the forecasted sales quantity with regard tothe event. The OrderForecastTimeSeries is of type CDT:QuantityTimeSeries, and is the forecasted order quantity with regard tothe event. The PlannedSalesPriceTimeSeries is of type CDT:PriceTimeSeries, and is the planned sales prices. The FixedIndicatorincluded in the TimeSeries mentioned above is not yet used.

(b) Location Package

The Location package 43844 groups together the locations that areaffected by the marketing activity (event). The Location package 43844includes a ShipFromLocation entity 43852 and a ShipToLocation entity43854. There is a 1:c relationship 43856 between the Item entity 43848and the ShipFromLocation entity 43852. There is a 1:1 relationship 43858between the Item entity 43848 and the ShipToLocation entity 43854.

For communication within the company (with common master data), use theInternalID for location entity types. For cross-company communication(with business-partner-specific master data), use for all locationentity types either the StandardID or the partner-role-specific ID ofthe receiving partner, for example, for Supplier Collaborationscenarios, use the BuyerID, and for Customer Collaboration scenarios,use the VendorID. Due to the different possibilities for ID use, all theID elements of the particular location are optional.

(i) Ship From Location

A ShipFromLocation is the location from which the products affected bythe marketing activity (event) are delivered. The ShipFromLocationentity 43852 is of type GDT:BusinessTransactionDocumentShipFromLocation, where the InternalID, theStandardID, the BuyerID, and the VendorID are used.

(ii) Ship To Location

A ShipToLocation is the location to which the products affected by themarketing activity (event) are delivered. The ShipToLocation entity43854 is type GDT: BusinessTransactionDocumentShipToLocation, where theInternalID, the StandardID, the BuyerID, and the VendorID are used.

(c) Product Information Package

The ProductInformation package 43846 groups together the informationthat characterizes the product in greater detail. The ProductInformationpackage 43846 includes a Product entity 43860. There is a 1:1relationship 43862 between the Item entity 43848 and the Product entity43860.

A Product is either a tangible or intangible good whose sales or demandis influenced by the event. The Product entity 43860 is of type GDT:BusinessTransactionDocumentProduct, where the InternalID, theStandardID, the BuyerID, the VendorID, and the PackageQuantity are used.For communication within a company (with common master data), use theInternalID for all product entity types. For cross-company communication(with business-partner-specific master data), use for all product entitytypes either the StandardID or the partner-role-specific ID of thereceiving partner, for example, for Supplier.Collaboration scenarios,use the BuyerID, and for Customer Collaboration scenarios, use theVendorID. Due to the different possibilities for ID use, all ID elementsof the particular product are optional.

(4) Element Structure for the Message Data Type FIG. 439 depicts theelement structure for Product Demand Influencing Event Notification. Theelement structure identifies the different packages 43900 in theinterface, and represents the entities at various levels within theinterface. As shown in FIG. 439, the interface forPurchaseRequirementRequest includes seven levels 43902, 43904, 43906,43908, 43910, 43912, and 43914. The element structure identifies thecardinality 43916 of each element and provides a type 43918, a data typename 43920, and, where applicable, a length 43924 for each element.

The outermost package of this interface is theProductDemandlnfluencingEventMessage package 43928, which includes aProductDemandInfluencingEventMessage entity 43930 at the first level43902. The ProductDemandlnfluencingEventMessage entity 43930 has acardinality of one 43932 and is of data type nameProductDemandInfluencingEventMessage 43934.

The ProductDemandInfluencingEventMessage package 43928 includes aMessageHeader package 43938 and a ProductDemandInfluencingEvent package43940.

The MessageHeader package 43938 includes a MessageHeader entity 43942 atthe second level 43904. The MessageHeader entity 43942 has a cardinalityof zero or one 43944 and is of type GDT 43946 with a data type name ofBusinessDocumentMessageHeader 43948. The MessageHeader entity 43942includes an ID 43954, a Creation DateTime 43966, a SenderParty 43974,and a Recipient Party 43904A at the third level 43906. The ID 43954 hasa cardinality of one 43956, a data type of GDT 43958 with a data typename of BusinessDocument MessageID 43960 and a length of 1 to 35 43962.The CreationDateTime 43966 has a cardinality of one 43968 and a datatype of GDT 43970 with a data type name of DateTime 43972. TheSenderParty 43974 has a cardinality of zero or one 43976 with a datatype of GDT 43978 and a data type name of BusinessDocumentMessageHeaderParty 43980. The Recipient Party 43904A has a cardinalityof zero or one 43906A with a data type of GDT 43908A and a data typename of BusinessDocument MessageHeaderParty 43910A.

The SenderParty 43974 includes an InternalID 43986 and a StandardID43994 at the fourth level 43908. The InternalID 43986 has a cardinalityof zero or one 43988, a data type of GDT 43990, and a data type name ofPartyInternalID 43992. The StandardID 43994 has a cardinality of anynumber 43996, a data type of GDT 43998, and a data type name ofPartyStandardID 43900A.

The RecipientParty entity 43904A includes an InternalID 43916A and aStandardID 43924A. The InternalID 43916A has a cardinality of zero orone 43918A, a data type of GDT 43920A, and a data type name ofPartyInternalID 43922A. The StandardID 43924A has a cardinality of anynumber 43926A, a data type of GDT 43928A, and a data type name ofPartyStandardID 43930A.

The ProductDemandlnfluencingEvent package 43940 includes aProductDemandlnfluencingEvent entity 43934A at the second level 43904.The ProductDemandlnfluencingEvent entity 43934A has a cardinality of one43936A, a data type of AGDT 43938A, and a data type name ofProductDemandlnfluencingEvent 43940A. The ProductDemandlnfluencingEvententity 43934A includes an InternalID 43944A, a BuyerID 43954A, aVendorID 43966A, a Name 43978A, a TypeCode 43990A, a StatusCode 43902B,a Recurrence entity 43914B, a PlanningPeriod 43934B, an ExecutingPeriod43952B, an Advertisement Period 43974B, and a Note 43990B at the thirdlevel 43906.

The InternalID 43944A has a cardinality of one or zero 43946A, a datatype of GDT 43948A, a data type name of BusinessTransactionDocumentID43950A, and a length of 1 to 35 43952A. The BuyerID 43954A has acardinality of one or zero 43956A, a data type of GDT 43958A, a datatype name of BusinessTransactionDocumentID 43960A, and a length of 1 to35 43962A. The VendorID 43966A has a cardinality of one or zero 43968A,a data type of GDT 43970A, a data type name ofBusinessTransactionDocumentID 43972A, and a length of 1 to 35 43974A.The Name 43978A has a cardinality of one or zero 43980A, a data type ofGDT 43982A, a data type name of Name 43984A, and a length of 1 to 4043986A. The TypeCode 43990A has a cardinality of one 43992A, a data typeof GDT 43994A, a data type name of ProductDemandlnfluencingEventTypeCode43996A, and a length of 1 to 35 43998A. The StatusCode 43902B has acardinality of one or zero 43904B, a data type of GDT 43906B, a datatype name of ProductDemandlnfluencingEventStatusCode 43908B, and alength of 1 to 35 43910B. The Recurrence 43914B has a cardinality of oneor zero 43916B, a data type of GDT 43918B, a data type name ofRecurrence 43920B, and a length of 1 to 3 43922B. The PlanningPeriod43934B has a cardinality of one or zero 43936B, a data type of GDT43938B, and a data type name of DateTimePeriod 43940B. TheExecutingPeriod 43952B has a cardinality of one or zero 43954B, a datatype of GDT 43956B, and a data type name of DateTimePeriod 43958B. TheAdvertisement Period 43974B has a cardinality of one or zero 43976B, adata type of GDT 43978B, and a data type name of DateTimePeriod 43980B.The Note entity 43990B has a cardinality of one or zero 43992B, a datatype of GDT 43994B, a data type name of Note 43996B, and a length of 1to 132 43998B.

The Recurrence 43914B includes a Duration 43924B and a Value 43928B atthe fourth level 43908. The Duration 43924B has a cardinality of one43926B. The Value 43928B has a cardinality of one 43930B and a length ofthree 43932B.

The PlanningPeriod 43934B has a StartDateTime 43942B and an EndDateTime43948B at the fourth level 43908. The StartDateTime 43942B has acardinality of zero or one 43944B. The EndDateTime 43948B has acardinality of zero or one 43950B.

The ExecutingPeriod 43952B includes a StartDateTime 43962B and anEndDateTime 43968B at the fourth level. The StartDateTime 43962B has acardinality of zero or one 43964B. The EndDateTime 43968B has acardinality of zero or one 43970B.

The AdvertisementPeriod 43974B includes a StartDateTime 43982B and anEndDateTime 43986B at the fourth level 43908. The StartDateTime 43982Bhas a cardinality of zero or one 43984B. The EndDateTime 43986B has acardinality of zero or one 43988B.

The ProductDemandlnfluencingEvent package 43940 includes a Party package43902C, a Scheduling package 43904C, and an Item package 43906C. TheParty package 43902C includes a BuyerParty entity 43908C and aVendorParty entity 43966C at the third level 43906. The BuyerPartyentity 43908C has a cardinality of zero or one 43910C, a data type ofCDT 43912C, a data type name of BusinessTransactionDocumentParty 43914C.The VendorParty entity 43966C has a cardinality of zero or one 43968C, adata type of CDT 43970C, and a data type name ofBusinessTransactionDocumentParty 43972C.

The Buyer Party entity 43908C includes an InternalID 43920C, aStandardID 43930C, a BuyerID 43942C, and a VendorID 43954C at the fourthlevel 43908. The InternalID 43920C has a cardinality of one or zero43922C, a data type of CDT 43924C, a data type name of PartyInternalID43926C, and a length of 1 to 10 43928C. The StandardID 43930C has acardinality of any number 43932C, a data type of CDT 43934C, a data typename of Party StandardID 43936C, and a length of 1 to 13 43938C. TheBuyerID 43942C has a cardinality of one or zero 43944C, a data type ofCDT 43946C, a data type name of PartyParty ID 43948C, and a length of 1to 10 43950C. The VendorID 43954C has a cardinality of one or zero43956C, a data type of CDT 43958C, a data type name of PartyParty ID43960C, and a length of 1 to 10 43962C.

The VendorParty entity 43966C includes an InternalID 43978C, aStandardID 43988C, a BuyerID 43900D, and a VendorID 43912D at the fourthlevel 43908. The InternalID 43978C has a cardinality of one or zero43980C, a data type of CDT 43982C, a data type name of PartyInternalID43984C, and a length of 1 to 10 43986C. The StandardID 43988C has acardinality of any number 43990C, a data type of CDT 43992C, a data typename of PartyStandardID 43994C, and a length of 1 to 13 43996C. TheBuyerID 43900D has a cardinality of one or zero 43902D, a data type ofCDT 43904D, a data type name of PartyParty ID 43906D, and a length of 1to 10 43908D. The VendorID 43912D has a cardinality of one or zero43914D, a data type of CDT 43916D, a data type name of PartyParty ID43918D, and a length of 1 to 10 43920D.

The Scheduling package 43904C includes a Scheduling entity 43924D at thethird level 43906. The Scheduling entity 43924D has a cardinality ofzero or one 43926D and a data type of AGDT 43928D. The Scheduling entity43924D includes an OrderingPeriod 43930D, aDistributionCenterReceiptPeriod 43938D, a DistributionCenterlssuePeriod43946D, a StoreReceiptPeriod 43954D, and a PickupPeriod 43962D. TheOrderingPeriod 43930D has a cardinality of zero or one 43932D and a datatype of GDT 43934D with a data type name of DateTimePeriod 43936D. TheDistributionCenter ReceiptPeriod 43938D has a cardinality of zero or one43940D and a data type of GDT 43942D with a data type name ofDateTimePeriod 43944D. The DistributionCenterIssuePeriod 43946D has acardinality of zero or one 43948D and a data type of GDT 43950D with adata type name of DateTimePeriod 43952D. The StoreReceiptPeriod 43954Dhas a cardinality of zero or one 43956D and a data type of GDT 43958Dwith a data type name of DateTimePeriod 43960D. The PickupPeriod 43962Dhas a cardinality of zero or one 43964D and a data type of GDT 43966Dand a data type name of DateTimePeriod 43968D.

The Item package 43906C includes an Item entity 43970D at the thirdlevel 43906. The Item entity 43970D has a cardinality of at least one43972D and a data type of AGDT 43974D with a data type name ofProductDemandlnfluencingEventItem 43976D. The Item package 43980D alsoincludes a Location package 43980D and a ProductInformation package43982D.

The Location package 43980D includes a ShipFromLocation entity 43984Dand a ShipToLocation entity 43942E at the fourth level 43908. TheShipFromLocation entity 43984D has a cardinality of zero or one 43986Dand a data type of CDT 43988D with a data type name ofBusinessTransactionDocumentShipFromLocation 43990D. The ShipToLocationentity 43942E has a cardinality of one 43944E and a data type of CDT43946E with a data type name ofBusinessTransactionDocumentShipToLocation 43948E.

The ShipFromLocation entity 43984D includes an InternalID 43996D, aStandardID 43906E, a BuyerID 43918E, and a VendorID 43930E at the fifthlevel 43910. The InternalID 43996D has a cardinality of zero or one43998D, a data type of CDT 43900E, a data type name of LocationInternalID 43902E, and a length of 1 to 20 43904E. The StandardID 43906Ehas a cardinality of any number 43908E, a data type of CDT 43910E, adata type name of LocationStandardID 43912E, and a length of 1 to 1343914E. The BuyerID 43918E has a cardinality of zero or one 43920E, adata type of CDT 43922E, a data type name of LocationPartyID 43924E, anda length of 1 to 20 43926E. The VendorID 3930E has a cardinality of zeroor one 43932E, a data type of CDT 43934E, a data type name ofLocationPartyID 43936E, and a length of 1 to 20 43938E.

The ShipToLocation entity 43942E includes an InternalID 43954E, aStandardID 43964E, a BuyerID 43976E, and a VendorID 43988E at the fifthlevel 43910. The InternalID 43954E has a cardinality of zero or one43956E, a data type of CDT 43958E, a data type name of LocationInternalID 43960E, and a length of 1 to 20 43962E. The StandardID 43964Ehas a cardinality of any number 43966E, a data type of CDT 43968E, adata type name of LocationStandardID 43970E, and a length of 1 to 1343972E. The BuyerID 43976E has a cardinality of zero or one 43978E, adata type of CDT 43980E, a data type name of LocationPartyID 43982E, anda length of 1 to 20 43984E. The VendorID 43988E has a cardinality ofzero or one 43990E, a data type of CDT 43992E, a data type name ofLocationPartyID 43994E, and a length of 1 to 20 43996E.

The ProductInformation package 43982D includes a Product entity 43900Fat the fourth level 43908. The Product entity 43900F has a cardinalityof one 43902F and a data type of CDT 43904F with a data type name ofBusinessTransactionDocumentProduct 43906F.

The Product entity 43900F includes an InternalID 43912F, a StandardID43922F, a BuyerID 43934F, a VendorID 43946F, and a PackageQuantityentity 43958F at the fifth level 43910. The InternalID 43912F has acardinality of zero or one 43914F and a data type of CDT 43916F with adata type name of ProductInternalID 43918F and a length of 1 to 4043920F. The StandardID 43922F has a cardinality of zero or one 43924Fand a data type of CDT 43926F with a data type name of ProductStandardID43928F and a length of 1 to 14 43930F. The BuyerID 43934F has acardinality of zero or one 43936F and a data type of CDT 43938F with adata type name of ProductPartyID 43940F and a length of 1 to 40 43942F.The VendorID 43946F has a cardinality of zero or one 43948F and a datatype of CDT 43950F with a data type name of ProductPartyID 43952F and alength of 1 to 40 43954F. The PackageQuantity 43958F has a cardinalityof zero or one 43960F and a data type of GDT 43962F with a data typename of Quantity 43964F and a length of 13 or 6 43966F.

Item package 43906C includes a SalesForecastTimeSeries 43968F, anOrderForecastTimeSeries 43916G, and a PlannedSalesPriceTimeSeries 43964Gat the fourth level 43908. The SalesForecastTimeSeries 43968F has acardinality of zero or one 43970F and a data type of CDT 43972F with adata type name of QuantityTimeSeries 43974F. The OrderForecastTimeSeriesentity 43916G has a cardinality of zero or one 43918G and a data type ofCDT 43920G with a data type name of QuantityTimeSeries 43922G. ThePlannedSalesTimeSeries entity 43964G has a cardinality of zero or one43966G and a data type of CDT 43968G with a data type name ofPriceTimeSeries 43970G.

The SalesForecastTimeSeries 43968F includes an Item entity 43980F at thefifth level 43910. The Item entity 43980F has a cardinality of anynumber 43982F and includes a ValidityPeriod 43984F and a Quantity 43906Gat the sixth level 43912. The ValidityPeriod 43984F has a cardinality ofone 43986F, a data type of GDT 43988F, and a data type name ofDateTimePeriod 43990F. The Quantity 43906G has a cardinality of one43908G and a data type of GDT 43910G with a data type name of Quantity43912G. The ValidityPeriod 43984F includes a StartDateTime 43994F and anEndDateTime 43900G at the seventh level 43914. The StartDateTime 43994Fhas a cardinality of zero or one 43996F, and the EndDateTime 43900G hasa cardinality of zero or one 43902G.

The OrderForecastTimeSeries 43916G includes an Item entity 43928G at thefifth level 43910. The Item entity 43928G has a cardinality of anynumber 43930G and includes a ValidityPeriod 43932G and a Quantity 43954Gat the sixth level 43912. The ValidityPeriod 43932G has a cardinality ofone 43934G, a data type of GDT 43936G, and a data type name ofDateTimePeriod 43938G. The Quantity 43954G has a cardinality of one43956G and a data type of GDT 43958G with a data type name of Quantity43960G.

The ValidityPeriod 43932G includes a StartDateTime 43942G and anEndDateTime 43948G at the seventh level 43914. The StartDateTime 43942Ghas a cardinality of zero or one 43944G, and the EndDateTime 43948G hasa cardinality of zero or one 43950G.

The PlannedSalesTimeSeries 43964G includes an Item entity 43976G at thefifth level 43910. The Item entity 43976G has a cardinality of anynumber 43978G, and includes a ValidityPeriod 43980G and a Price 43902Hat the sixth level 43912. The ValidityPeriod 43980G has a cardinality ofone 43982G and a data type of GDT 43984G with a data type name ofDateTimePeriod 43986G. The Price 43902H has a cardinality of one 43904Hand a data type of GDT 43906H with a data type name of Price 43908H.

The ValidityPeriod 43980G includes a StartDateTime 43990G and anEndDateTime 43996G at the seventh level 43914. The StartDateTime 43990Ghas a cardinality of zero or one 43992G, and the EndDateTime 43996G hasa cardinality of zero or one 43998G.

z) Product Forecast Interface The ProductForecastNotification message isused to exchange forecast of future product sale or demand. TheProductForecastNotification message is sent within the BusinessScenarios “Responsive Replenishment” and “Collaborative Planning,Forecasting, and Replenishment (CPFR)” in an cross-company variant froma buyer (retail company) to a vendor (consumer products manufacturer) orin a variant within a company from one planning system to another.

(1) Message Type Product Forecast Notification

A ProductForecastNotification is a notice about future product sale ordemand (forecasts). The structure of the message typeProductForecastNotification is specified by the message data typeProductForecastNotificationMessage. Methods and systems consistent withthe subject matter described herein use the package template for aBusinessTransactionDocument for an SCM Master Data depicted in FIG. 270Bto derive the ProductForecast interface.

(2) Message Choreography

The following message choreography of scenario “CPFR” describesexemplary logical sequence of the message types for the scenariorealization.

A buyer 44002 sends long to mid-term demand information that is relatedto an event to a vendor 44004 (ProductDemandlnfluencingEventNotification44006). Together with product forecast information(ProductForecastNotification 44008) sent by the buyer 44002, or withshort-term incidental current sales information(ProductActivityNotification 44010), this information can be used by thevendor 44004 for the creation of a forecast for the product demand ofthe buyer 44002. In the case of a cooperative settlement process betweenthe buyer 44002 and vendor 44004, the vendor 44004 can send a revisionof the product forecast (sent by the buyer 44002) back to this buyer44002 (ProductForecastRevisionNotification 44012), and in turn, thebuyer 44002 can respond with an updated revision(ProductForecastRevisionNotification 44014). In one implementation, thischoreography differs from the Request/Confirmation procedure; ratherthan the original document (possibly in a different form) beingconfirmed here, it is replaced by other ProductForecastRevisions untilthe difference is sufficiently minimal.

(3) Message Data Type Product Forecast Notification Message

The message data type ProductForecastNotificationMessage includes theProductForecast object included in the business document, with the focuson the ProductForecastNotification view and the business informationthat is relevant for sending a business document in a message. TheProductForecastNotificationMessage package 44102 includes aMessageHeader package 44104, a ProductForecast package 44106, and aProductForecastNotificationMessage entity 44108. The message data typeProductForecastNotificationMessage provides the structure for themessage type ProductForecastNotification and the relevant interfaces.

(a) Message Header Package

The MessageHeader package 44104 groups together the business informationthat is relevant for sending a business document in a message. There isa 1:1 relationship 44112 between the MessageHeader entity 44110 and theProductForecastNotificationMessage entity 44108.

(i) Message Header

A MessageHeader entity 44110 groups together the business informationfrom the perspective of the sending application information to identifythe business document in a message, information about the sender, andany information about the recipient.

The MessageHeader entity 44110 includes a SenderParty entity 44114 and aRecipientParty entity 44116. There is a 1:c relationship 44118 betweenthe SenderParty entity 44114 and MessageHeader entity 44110. There is a1:c relationship 44120 between the RecipientParty entity 44116 andMessageHeader entity 44110. The MessageHeader entity 44110 is of typeGDT: BusinessDocumentMessageHeader. The MessageHeader entity 44110includes an ID and a CreationDateTime. The ID is the identification ofthe business document in the technical message. The CreationDateTime isthe creation date of the business document in the technical message.

(ii) Sender Party

A SenderParty entity 44114 is the party responsible for sending abusiness document at business application level. The SenderParty entity44114 is of type GDT: BusinessDocumentMessageHeaderParty.

(iii) Recipient Party

A RecipientParty entity 44116 is the party responsible for receiving abusiness document at business application level. The RecipientPartyentity 44116 is of type GDT: BusinessDocumentMessageHeaderParty.

(b) Product Forecast Package

The ProductForecast package 44106 includes a Party package 44122 and aProductForecastItem package 44124, and a ProductForecast entity 44126.

(i) Product Forecast

A ProductForecast entity 44126 (specialized/regarded) as aProductForecastNotification is a forecast of the sale/demand of productsin the form of time series between business partners. A ProductForecastincludes several items (see ProductForecastItem Package 44124), whichcan contain information about the sales quantities predicted by theforecast for each ship-to location and product. There is a 1:1relationship 44128 between ProductForecast entity 44126 andProductForecastNotificationMessage entity 44108. A ProductForecastentity 44126 includes a ValidityPeriod, and a Note. The ValidityPeriodis of type GDT: DateTimePeriod, and is the validity period for theforecast. The Note is of type GDT: Note, and is the language-independentnote.

(ii) Party Package

The Party package 44122 groups together the business partners betweenwhich the forecast is to be exchanged. It includes a BuyerParty entity44130 and a VendorParty entity 44132. There is a 1:c relationship 44134between the BuyerParty entity 44130 and ProductForecast entity 44126.There is a 1:c relationship 44136 between the VendorParty entity 44132and ProductForecast entity 44126.

For communication within a company (with common master data), theInternalID is used for party entity types. For cross-companycommunication (with business-partner-specific master data), party entitytypes are used for either the StandardID or the partner-role-specific IDof the receiving partner, for example, for Supplier Collaborationscenarios, the BuyerID, and for Customer Collaboration scenarios, theVendorID is used. Due to the different possibilities for ID use, IDelements of the particular party are optional.

(a) Buyer Party

A BuyerParty entity 44130 identifies the purchasing company. ABuyerParty entity 44130 is of type GDT:BusinessTransactionDocumentParty, where the InternalID, the StandardID,the BuyerID, and the VendorID are used.

(b) Vendor Party

A VendorParty entity 44132 is the delivering company. The VendorPartyentity 44132 is of type GDT: BusinessTransactionDocumentParty, where theInternalID, the StandardID, the BuyerID, and the VendorID are used.

(iii) Product Forecast Item Package

The ProductForecastItem package 44124 groups together theProductForecastItem entity 44142, a Location package 44138 and aProductInformation package 44140. There is a 1:n relationship betweenthe ProductForecast entity 44142 and the ProductForecastItem entity44126.

(a) Product Forecast Item

A ProductForecastItem entity 44142 (specialized/regarded) as aProductForecastNotificationItem specifies for a ship-from location(optional), a ship-to location (see Location Package 44138), and aproduct (see ProductInformation Package 44140) the forecasted salesquantities in the form of a time series.

A ProductForecastItem entity 44142 includes a SalesForecastTimeSeries, aPromotionSalesForecastTimeSeries, an OrderForecastTimeSeries, and aPromotionOrderForecastTimeSeries. The SalesForecastTimeSeries is of typeCDT: QuantityTimeSeries, and is the forecasted sales quantity, possiblyincluding reason for adjustment. The PromotionSalesForecastTimeSeries isof type CDT: QuantityTimeSeries, and is the forecasted promotion orderquantity.

(b) Location Package

The Location package 44138 groups together the locations that areaffected by the forecast. It includes a ShipFromLocation entity 44146and a ShipToLocation entity 44148. There is a 1:c relationship 44150between the ProductForecastItem entity 44142 and the ShipFromLocationentity 44146. There is a 1:c relationship 44152 between theProductForecastItem entity 44142 and the ShipToLocation entity 44148.

For communication within a company (with common master data), theInternalID is used for location entity types. For cross-companycommunication (with business-partner-specific master data), locationentity types are used for either the StandardID or thepartner-role-specific ID of the receiving partner, for example, forSupplier Collaboration scenarios, use the BuyerID, and for CustomerCollaboration scenarios, the VendorID is used. Due to the differentpossibilities for ID use, the ID elements of the particular location areoptional.

(i) Ship From Location

A ShipFromLocation entity 44146 is the location from which the product,whose sale or demand is forecasted/revised, is delivered. AShipFromLocation entity 44146 is of type GDT:BusinessTransactionDocumentShipFromLocation, where the InternalID, theStandardID, the BuyerID, and the VendorID are used.

(ii) Ship To Location

A ShipToLocation entity 44148 is the location to which the product,whose sale or demand is forecasted/revised, is delivered. AShipToLocation entity 44148 is of type GDT:BusinessTransactionDocumentShipToLocation, where the InternalID, theStandardID, the BuyerID, and the VendorID are used.

(c) Product Information Package

The ProductInformation package 44140 groups together the informationthat characterizes the product in greater detail. It includes a Productentity 44154. There is a 1:1 relationship 44156 betweenProductForecastItem entity 44142 and Product entity 44154.

A Product entity 44154 is the tangible or intangible good whoseforecasted sale or demand is revised. A Product entity 44154 is of typeGDT: BusinessTransactionDocumentProduct, where the InternalID, theStandardID, the BuyerID, the VendorID, and the PackageQuantity are used.

For communication within a company (with common master data), theInternalID is used for product entity types. For cross-companycommunication (with business-partner-specific master data), productentity types are used for either the StandardID or thepartner-role-specific ID of the receiving partner, for example, forSupplier Collaboration scenarios, the BuyerID is used, and for CustomerCollaboration scenarios, the VendorID is used. Due to the differentpossibilities for ID use, ID elements of the particular product areoptional.

(4) Element Structure for the Message Data Type

FIG. 442 depicts the element structure forProductForecastNotificationMessage. The element structure is similar tothe data model, but provides additional information regarding thedetails of the interface. The element structure identifies the differentpackages 44200 in the interface, and represents the entities at variouslevels within the interface. As depicted in FIG. 442, the interface forProductForecastNotificationMessage includes seven levels 44202, 44204,44206, 44208, 44210, 44212, and 44214. The element structure identifiesthe cardinality 442014 between the entities of the interface, providesinformation (i.e., type 44218 and name 44220) regarding the data typethat provides the basis for the entity, and where appropriate, thelength 44224 of the element. The outermost package of this interface isan ProductForecastNotificationMessage package 44228, which includes anProductForecastNotificationMessage entity 44230 at the first level44202. The ProductForecastNotificationMessage entity 44230 is of typemessage data type “ProductForecastNotificationMessage” 44234, and thereis one 44232 ProductForecastNotificationMessage entity 44230 for eachProductForecastNotificationMessage package 44228.

The ProductForecastNotificationMessage package 44228 includes aMessageHeader package 44238 and a ProductForecast package 44240. TheMessageHeader package 44238 includes a MessageHeader entity 44242, whichis of type generic data type (“GDT”) 44246“BusinessDocumentMessageHeader” 44248. There is zero or one 44244MessageHeader entity 44242 for each MessageHeader package 44238.

The MessageHeader entity 44242 includes an ID 44254, a CreationDateTime442, a SenderParty 44274, and a RecipientParty 44204A. The ID 44254 isof type GDT 44246 BusinessDocumentMessageID 44248, and there is one44256 ID 44254 for each MessageHeader entity 44242. The ID 44254 has alength 44224 of 1 to 35 44262. The CreationDateTime 44266 is of type GDT44270 DateTime 44272. There is one 442 CreationDateTime 442 for eachMessageHeader entity 44242. The SenderParty 44274 is of type GDT 44278BusinessDocumentMessageHeaderParty 44280. The RecipientParty 44204A isalso of type GDT 44208A BusinessDocumentMessageHeaderParty 44210A. Thereis one or zero 44276 SenderParty entity 44274 for each MessageHeaderentity 44242, and there is one or zero 44206A RecipientParty entity44204A for each MessageHeader entity 44242.

The SenderParty entity 44274 includes an InternalID 44286 and aStandardID 44294. The InternalID 44286 has zero or one occurrences 44288and a data type GDT 44290 of PartyInternalID 44292. The StandardID 44294of the SenderParty entity 44274 has any number of occurrences 44296 andhas a data type of GDT 44298 PartyStandardID 44200A. The RecipientPartyentity 44204A includes an InternalID 44216A and a StandardID 44224A. TheInternalID 44216A has zero or one occurrences 44218A and a data type GDT44220A of PartyInternalID 44222A. The StandardID 44224A of theRecipientParty entity 44204A has any number of occurrences 44226A andhas a data type of GDT 44228A PartyStandardID 44230A.

The ProductForecast package 44240 includes a ProductForecast entity44234A. There is one 44236A ProductForecast entity 44234A for eachProductForecast package 44240 and has a data type AGDT 44238AProductForecast 44240A. The ProductForecast entity 44234A includes anValidityPeriod 44242A that has one or zero 44244A occurrences and a datatype of GDT 44246A DateTimePeriod 44248A. The ValidityPeriod 44242Aincludes a StartDateTime 44252A and EndDateTime 44258A, wherein each ofthese elements has one or zero occurrences 44254A and 44260A,respectively.

The Party package 442064A includes a BuyerParty entity 44268A, aVendorParty entity 44226B, and a Note 44284B. The BuyerParty entity44268A is of type CDT 44272A BusinessTransactionDocumentParty 44274A.There is one or zero 44270A BuyerParty entity 44268A for each Partypackage 44264A. The VendorParty entity 44226B is of type DT 44230BBusinessTransactionDocumentParty 44232B. There is one or zero 44228BendorParty entity 44226B for each Party package 44264A.

The BuyerParty entity 44268A includes an InternalID 44280A, a StandardID4290A, a BuyerID 44202B, and a VendorID 44214B. The InternalID 44280Ahas zero or one occurrences 44282, a data type of CDT 44284PartyInternalID 44286 and a length 44224 of 1 to 10 44288A. TheStandardID 44290A has any number of occurrences 44292A, a data type ofCDT 44294A PartyStandardID 44296A, and a length 44224 of 1 to 13 44298A.The BuyerID 44202B has zero or one occurrences 44204B, a data type ofCDT 44206B PartyPartyID 44208B, and a length 44224 of 1 to 10 44210B.The VendorID 44214B has zero or one occurrences 44216B, a data type ofCDT 44218B PartyPartyID 44220B, and a length 44224 of 1 to 10 44222B.

The VendorParty entity 44226B includes an InternalID 44238B, aStandardID 44248B, a BuyerID 44260B, and a VendorID 44272B. TheInternalID 44238B has zero or one occurrences 44240B, a data type CDT44242B of PartyInternalID 44244B, and a length 44224 of 1 to 10 44246B.The StandardID 44248B has any number of occurrences 44250B, a data typeCDT 44252B of PartyStandardID 44254B, and a length 44224 of 1 to 1344256B. The BuyerID 44260B has zero or one occurrences 44262B, a datatype CDT 44264B of PartyPartyID 44266B, and a length 44224 of 1 to 1044268B. The VendorID 44272B has zero or one occurrences 44274B, a datatype CDT 44276B of PartyPartyID 44278B, and a length 44224 of 1 to 1044280B.

The ProductForecast package includes a Note 44284B. The Note 44284B hasone or zero 44286B occurrences, a data type of GDT 44288B Note 44290,and a length 44224 of 1 to 132 44292B.

The Item package 44266A includes an Item entity 44294B, a Locationpackage 44204C, and a ProductInformation package 44206C. There is one ormore 44296B Item entities 44294B for each Item package 44266A and it isof data type AGDT 44298B ProductForecastItem 44200C.

The Location package 44204C includes a ShipFromLocation entity 44208Cand a ShipToLocation entity 44266C. The ShipFromLocation entity 44208Cis of type CDT 44212C BusinessTransactionDocumentShipFromLocation44214C. There is zero or one 44210C ShipFromLocation entity 44208C foreach Location package 44204C. The ShipToLocation entity 44266C is oftype CDT 44268C BusinessTransactionDocumentLocation 44272C and there iszero or one 44268C ShipToLocation entity 44266C for each Locationpackage 44204C.

The ShipFromLocation entity 44208C includes an InternalID 44220C, aStandardID 44230C, a BuyerID 44242C, and a VendorID 44254C. TheInternalID 44220C has zero or one occurrences 44222C, a data type of CDT44224C LocationInternalID 44226C, and a length 44224 of 1 to 20 44228C.The StandardID 44230C has any number of occurrences 44232C, a data typeof CDT 44234C LocationStandardID 44236C, and a length 44224 of 1 to 1344238C. The BuyerID 44242C has zero or one occurrences 44244C, a datatype of CDT 44246C LocationPartyID 44248C, and a length 44224 of 1 to 2044250C. The VendorID 44254C has zero or one occurrences 44256C, a datatype of CDT 44258C LocationPartyID 44260C, and a length 44224 of 1 to 2044262C.

The ShipToLocation entity 44266C includes an InternalID 44278C, aStandardID 44288C, a BuyerID 44200C, and a VendorID 44212C. TheInternalID 44278C has zero or one occurrences 44280C, a data type of CDT44282C LocationInternalID 44284C, and a length 44224 of 1 to 20 44286C.The StandardID 44288C has any number occurrences 44290C, a data type ofCDT 44292C LocationStandardID 44294C, and a length 44224 of 1 to 1344296C. The BuyerID 44200D has zero or one occurrences 44202D, a datatype of CDT 44204D LocationPartyID 44206D, and a length 44224 of 1 to 2044208D. The VendorID 44212D has zero or one occurrences 44214D, a datatype of CDT 44216D LocationPartyID 44218D, and a length 44224 of 1 to 2044220D.

The ProductInformation package 44206C includes a Product entity 44224D.The Product entity 44224D is of type CDT 44228DBusinessTransactionDocumentProduct 44230D, and there is one 44226DProduct entity 44224D for each ProductInformation package 44206C. TheProductInformation entity 44224D includes an InternalID 44236D, aStandardID 44246D, a BuyerID 44258D, a VendorID 44270D, and aPackageQuantity 44282D. The InternalID 44236D has zero or oneoccurrences 44238D, a data type of CDT 44240D ProductInternalID 44242D,and a length 44224 of 1 to 40 44244D. The StandardID 44246D has zero orone occurrences 44248D, a data type of CDT 44250D ProductStandardID44252D, and a length 44224 of 1 to 14 44254D. The BuyerID 44258D haszero or one occurrences 44260D, a data type of CDT 44262D ProductPartyID44264D, and a length 44224 of 1 to 40 44266D. The VendorID 44270D haszero or one occurrences 44272D, a data type of CDT 44274D ProductPartyID44276D, and a length 44224 of 1 to 40 44278D. The PackageQuantity 44282Dhas zero or one occurrences 44284D, a data type of GDT 44286D Quantity44288D, and a length 44224 of 19 or 6 44290D.

The Item package 44266A also includes a SalesForecastTimeSeries 44292D,PromotionSalesForecastTimeSeries 44246E, OrderForecastTimeSeries 44200F,and PromotionOrderForecastTimeSeries 44254F. The SalesForecastTimeSeries44292D has one or zero occurrences 44294D and a data type of CDT 44296DQuantityTimeSeries 44298D. The PromotionSalesForecastTimeSeries 44246Ehas one or zero occurrences 44248E and a data type of CDT 44250EQuantityTimeSeries 44252E. The OrderForecastTimeSeries 44200F has one orzero occurrences 44202F and a data type of CDT 44204F QuantityTimeSeries44206F. The PromotionOrderForecastTimeSeries 44254F has one or zerooccurrences 44256F and a data type of CDT 44258F QuantityTimeSeries44260F.

The SalesForecastTimeSeries 44292D includes an Item 44200E. The Item44200E has any number of occurrences 44202E. The Item 44200E includes aValidityPeriod 44206E, a Quantity 44228E, and a FixedIndicator 44238E.The ValidityPeriod 44206E has one occurrence 44208E and a data type ofGDT 44210E DateTimePeriod 44212E. The ValidityPeriod 44206E includes aStartDateTime 44216E and EndDateTime 44222E, wherein each has one orzero occurrences 44218E and 44224E, respectively. The Quantity 44228Ehas one occurrence 44230E and a data type of GDT 44232E Quantity 44234E.The FixedIndicator 44238E has one or zero occurrence 44240E and a datatype of GDT 44242E FixedIndicator 44244E.

The PromotionSalesForecastTimeSeries 44246E includes an Item 44254E. TheItem 44254E includes a ValidityPeriod 44260E, a Quantity 44282E, and aFixedIndicator 44292E. The Item 44254E has any number of occurrences44256E. The ValidityPeriod 44260E has one occurrence 44262E and a datatype of GDT 44264E DateTimePeriod 44266E. The ValidityPeriod 44260Eincludes a StartDateTime 44270E and EndDateTime 44276E, wherein each hasone or zero occurrences 44272E and 44278E, respectively. The Quantity44282E has one occurrence 44284E and a data type of GDT 44286E Quantity44288E. The FixedIndicator 44292E has one or zero occurrence 44294E anda data type of GDT 44296E FixedIndicator 44298E.

The OrderForecastTimeSeries 44200F includes an Item 44208F. The Item44208F has any number of occurrences 44210F. The Item 44208F includes aValidityPeriod 44214F, a Quantity 44236F, and a FixedIndicator 44246F.The ValidityPeriod 44214F has 30 one occurrence 44216F and a data typeof GDT 44218F DateTimePeriod 44220F. The ValidityPeriod 44214F includesa StartDateTime 44224F and EndDateTime 44230F, wherein each has one orzero occurrences 44226F and 44232F, respectively. The Quantity 44236Fhas one occurrence 44238F and a data type of GDT 44240F Quantity 44242F.The FixedIndicator 44246F has one or zero occurrence 44248F and a datatype of GDT 44250F FixedIndicator 44252F.

The PromotionOrderForecastTimeSeries 44254F includes an Item 44262F. TheItem 44262F has any number of occurrences 44264F. The Item 44262Fincludes a ValidityPeriod 44268F, a Quantity 44290F, and aFixedIndicator 44200G. The ValidityPeriod 44268F has one occurrence44270F and a data type of GDT 44272F DateTimePeriod 44274F. TheValidityPeriod 44268F includes a StartDateTime 44278F and EndDateTime44284F, wherein each has one or zero occurrences 44280F and 44286F,respectively. The Quantity 44290F has one occurrence 44292F and a datatype of GDT 44294F Quantity 44296F. The FixedIndicator 44200G has one orzero occurrence 44202G and a data type of GDT 44204G FixedIndicator44206G.

aa) Product Forecast Revision Interface

The ProductForecastRevisionNotification message is a notice of forecastrevisions. Forecast revisions can be updates or confirmations offorecasts of the future sale or demand of a product, for example.

The ProductForecastRevisionNotification message is sent within theBusiness Scenarios “Responsive Replenishment” and “CollaborativePlanning, Forecasting, and Replenishment (CPFR)” in a cross-companyvariant from a buyer (retail company) to a vendor (consumer productsmanufacturer), or vice versa. In a variant within a company, theexchange is made between two different planning systems.

(1) Message Type Product Forecast Revision Notification

A ProductForecastRevisionNotification entity is a notice about futureproduct sale or demand (forecasts). The structure of the message typeProductForecastNotification is specified by the message data typeProductForecastRevisionNotificationMessage. Methods and systemsconsistent with the subject matter described herein use the packagetemplate for a BusinessTransactionDocument for an SCM Master Datadepicted in FIG. 270B to derive the ProductForecastRevision interface.

(2) Messsage Choreography

The following message choreography of scenario “CPFR” describes anexemplary logical sequence of the message types for the scenariorealization.

A buyer 44302 sends long to mid-term demand information that is relatedto an event to a vendor 44304 (ProductDemandlnfluencingEventNotification44306). Together with product forecast information(ProductForecastNotification 44308) sent by the buyer 44302, or withshort-term incidental current sales information(ProductActivityNotification 44310), this information can be used by thevendor 44304 for the creation of a forecast for the product demand ofthe buyer 44302. In the case of a cooperative settlement process betweenthe buyer 44302 and vendor 44304, the vendor 44304 can send a revisionof the product forecast (sent by the buyer 44302) back to this buyer44302 (ProductForecastRevisionNotification 44312), and in turn, thebuyer can respond with an updated revision(ProductForecastRevisionNotification 44314).

In one implementation, this choreography differs from theRequest/Confirmation procedure; rather than the original document(possibly in a different form) being confirmed here, it is replaced byother ProductForecastRevisions until the difference is sufficientlyminimal.

(3) Message Data Type Product Forecast Revision Message

The message data type ProductForecastRevisionMessage includes theProductForecast object included in the business document, with the focuson the ProductForecastRevision view and the business information that isrelevant for sending a business document in a message. TheProductForecastRevisionMessage package 44402 includes the aMessageHeader package 44404, a ProductForecast package 44406, and aProductForecastRevisionMessage entity 44408. The message data typeProductForecastRevisionMessage provides the structure for the messagetype ProductForecastRevisionNotification and the relevant interfaces.

(a) Message Header Package

The MessageHeader package 44404 groups together the business informationthat is relevant for sending a business document in a message. Itincludes a MessageHeader entity 44410. There is a 1:1 relationship 44412between the ProductForecastRevisionMessage entity 44408 and theMessageHeader entity 44410.

(i) Message Header

A MessageHeader entity 44410 groups together the business informationfrom the perspective of the sending application information to identifythe business document in a message, information about the sender, andany information about the recipient.

The MessageHeader entity 44410 includes a SenderParty entity 44414 and aRecipientParty entity 44416. There is a 1:c relationship 44418 betweenthe MessageHeader entity 44410 and the SenderParty entity 44414. Thereis a 1:c relationship 44420 between the MessageHeader entity 44410 andthe RecipientParty entity 44416. The MessageHeader entity 44410 is oftype GDT: BusinessDocumentMessageHeader. The MessageHeader entity 44410includes an ID and a CreationDateTime. The ID is the identification ofthe business document in the technical message. The CreationDateTime isthe creation date of the business document in the technical message.

(ii) Sender Party

A SenderParty entity 44414 is the party responsible for sending abusiness document at business application level. The SenderParty entity44414 is of type GDT: BusinessDocumentMessageHeaderParty.

(iii) Recipient Party

A RecipientParty entity 44416 is the party responsible for receiving abusiness document at business application level. The RecipientPartyentity 44416 is of type GDT: BusinessDocumentMessageHeaderParty.

(b) Product Forecast Package

The ProductForecast package entity 44406 groups the ProductForecastentity 44426, a Party package 44422 and a ProductForecastItem package44424.

(i) Product Forecast

A ProductForecast entity 44426 (specialized/regarded) as aProductForecastNotification is a forecast of the sale/demand of productsin the form of time series between business partners. A ProductForecastentity 44426 includes several items (see ProductForecastItem Package44424), which can contain information about the sales quantitiespredicted by the forecast for each ship-to location and product.

A ProductForecast entity 44426 includes an Acceptance Status Code, aValidityPeriod and a Note. The AcceptanceStatusCode is of type GDT:AcceptanceStatusCode, and is the status of the acceptance. TheValidityPeriod is of type GDT: DateTimePeriod, and is the validityperiod for the forecast. The Note is of type GDT: Note, and is alanguage-independent note.

The AcceptanceStatusCode is valid for the time series that are specifiedin the ProductForecast entity 44426. On the application side, therelation is established by the validity area of the time series, thatis, by the validity period, the business partners, and the locations andthe product specified at item level.

(ii) Party Package

The Party package 44422 groups together the business partners betweenwhich the revised ProductForecast entity 44426 is to be exchanged. Itincludes a BuyerParty entity 44430 and a VendorParty entity 44432. Thereis a 1:c relationship 44434 between ProductForecast entity 44426 andBuyerParty entity 44430. There is a 1:c relationship 44436 betweenProductForecast entity 44426 and VendorParty entity 44424.

For communication within a company (with common master data), theInternalID is used for party entity types. For cross-companycommunication (with business-partner-specific master data), party entitytypes are used for either the StandardID or the partner-role-specific IDof the receiving partner, for example, for Supplier Collaborationscenarios the BuyerID is used, and for Customer Collaboration scenarios,the VendorID is used. Due to the different possibilities for ID use, IDelements of the particular party are optional.

(a) Buyer Party

A BuyerParty entity 44430 is the purchasing company. BuyerParty entity44430 of type GDT: BusinessTransactionDocumentParty, where theInternalID, the StandardID, the BuyerID, and the VendorID are used.

(b) Vendor Party

A VendorParty entity 44432 is the delivering company. VendorParty entity44432 of type GDT: BusinessTransactionDocumentParty, where theInternalID, the StandardID, the BuyerID, and the VendorID are used.

(iii)Product Forecast Item Package

The ProductForecastItem package 44434 groups together theProductForecastItem entity 44420 a Location package entity 44438, and aProductInformation package entity 44440. There is a 1:cn relationship44444 between ProductForecast entity 44426 and ProductForecastItementity 44442.

(a) Product Forecast Item

A ProductForecastItem entity 44442 (specialized/regarded) as aProductForecastNotificationItem specifies for a ship-from location(optional), a ship-to location (see Location Package 44438), and aproduct (see ProductInformation Package 44440) the forecasted salesquantities in the form of a time series.

A ProductForecastItem entity 444242 includes a SalesForecastTimeSeries,a PromotionSalesForecastTimeSeries, an OrderForecastTimeSeries, and aPromotionOrderForecastTimeSeries. The SalesForecastTimeSeries is of typeCDT: QuantityTimeSeries, and is the forecasted sales quantity. ThePromotionSalesForecastTimeSeries is of type CDT: QuantityTimeSeries, andis the forecasted promotion sales quantity. The OrderForecastTimeSeriesis of type CDT: RevisionQuantityTimeSeries, and is the forecasted orderquantity, possibly including reason for adjustment. ThePromotionOrderForecastTimeSeries is of type CDT:RevisionQuantityTimeSeries, and is the forecasted promotion orderquantity, possibly including reason for adjustment.

(b) Location Package

The Location package 44438 groups together the locations that areaffected by the revised ProductForecastItem entity 44442. It includes aShipFromLocation entity 44448 and a ShipToLocation entity 44450. Thereis a 1:c relationship 44452 between ProductForecastItem entity 44442 andShipFromLocation entity 44430. There is a 1:c relationship 44454 betweenProductForecastItem entity 44442 and ShipToLocation entity 44450.

For communication within a company (with common master data), theInternalID is used for location entity types. For cross-companycommunication (with business-partner-specific master data), locationentity types are used for either the StandardID or thepartner-role-specific ID of the receiving partner, for example, forSupplier Collaboration scenarios, use the BuyerID, and for CustomerCollaboration scenarios, the VendorID is used. Due to the differentpossibilities for ID use, the ID elements of the particular location areoptional.

(i) Ship From Location

A ShipFromLocation entity 44448 is the location from which the product,whose sale or demand is forecasted, is delivered. A ShipFromLocationentity 44448 is of type GDT:BusinessTransactionDocumentShipFromLocafion, where the InternalID, theStandardID, the BuyerID, and the VendorID are used.

(ii) Ship To Location

A ShipToLocation entity 44450 is the location to which the product,whose sale or demand is forecasted, is delivered. A ShipToLocationentity 44450 is of type GDT: BusinessTransactionDocumentShipToLocation,where the InternalID, the StandardID, the BuyerID, and the VendorID areused.

(c) Product Information Package

The ProductInformation package 44440 groups together the informationthat characterizes the product in greater detail. It includes a Productentity 44456. There is a 1:1 relationship 44458 betweenProductForecastitem entity 44442 and Product entity 44456.

A Product entity 44456 is the tangible or intangible good whose sale ordemand is forecasted. A Product entity 44456 is of type GDT:BusinessTransactionDocumentProduct, where the InternalID, theStandardID, the BuyerID, the VendorID, and the PackageQuantity are used.

For communication within a company (with common master data), theInternalID is used for product entity types. For cross-companycommunication (with business-partner-specific master data), productentity types are used for either the StandardID or thepartner-role-specific ID of the receiving partner, for example, forSupplier Collaboration scenarios, the BuyerID is used, and for CustomerCollaboration scenarios, the VendorID is used. Due to the differentpossibilities for ID use, ID elements of the particular product areoptional.

(4) Element Structure of Product Forecast Revision Message

FIG. 445 depicts the element structure forPProductForecastRevisionMessage. The element structure is similar to thedata model, but provides additional information regarding the details ofthe interface. The element structure identifies the different packages44500 in the interface, and represents the entities at various levelswithin the interface. As depicted in FIGS. 445-444, the interface forProductForecastNotification includes seven levels 44502, 44504, 44506,44508, 44510, 44512, and 44514. The element structure identifies thecardinality 44514 between the entities of the interface, providesinformation (i.e., type 44518 and name 44520) regarding the data typethat provides the basis for the entity, and where appropriate, a length44524 for the element. The outermost package of this interface is aProductForecastRevisionMessage package 44528, which includes anProductForecastRevisionMessage entity 44530 at the first level 44502.The ProductForecastRevisionMessage entity 44530 has a message data name44520 “ProductForecastRevisionMessage” 44534.

The ProductForecastRevisionMessage package 44528 includes aMessageHeader package 44538 and a ProductForecast package 44540. TheMessageHeader package 44538 includes a MessageHeader entity 44542, whichis of type generic data type (“GDT”) 44546“BusinessDocumentMessageHeader” 44548. There is one 44544 MessageHeaderentity 44542 for each ProductForecastRevisionMessage package 44528.

The MessageHeader entity 44542 includes an ID 44554, a CreationDateTime44566, a SenderParty 44574, and a RecipientParty 44502A. The ID 44554 isof type GDT 44558 BusinessDocumentMessageID 44560 and has a length 44524of 1 to 35 44562. The CreationDateTime 44566 is of type GDT 44570DateTime 44572. There is one 44556 ID 44554 for each MessageHeaderentity 44542 and one 44568 CreationDateTime 44566 for each MessageHeaderentity 44542. The SenderParty entity 44574 is of type GDT 44578BusinessDocumentMessageHeaderParty 44580. The RecipientParty entity44502A is also of type GDT 44506A BusinessDocumentMessageHeaderParty44508A. There is one or zero 44576 SenderParty entity 44574 for eachMessageHeader entity 44542, and there is one or zero 44504ARecipientParty entity 44502A for each MessageHeader entity 44542.

The SenderParty entity 44574 includes an InternalID 44584 and aStandardID 44592. The InternalID 44584 has zero or one occurrence 44586and a data type GDT 44588 of PartyInternalID 445909. The StandardID44592 of the SenderParty entity 44574 has any number of occurrences44594 and having a data type of GDT 44596 PartyStandardID 44598. TheRecipientParty entity 44502A includes an InternalID 44514A and aStandardID 44522A. The InternalID 44514A has zero or one occurrence44516A and a data type GDT 44518A of PartyInternalID 44520A. TheStandardID 44522A of the RecipientParty entity 44502A has any number ofoccurrences 44524A and has a data type of GDT 44526A PartyStandardID44528A.

The ProductForecast package 44540 includes a ProductForecast entity44532A. There is one 44534A ProductForecast entity 44532A for eachProductForecast package 44540 and is of data type AGDT 44536AProductForecastRevision 44538A. The ProductForecast entity 44532Aincludes an AcceptanceStatusCode 44540A having one or zero occurrence42A, a data type of GDT 44546A AccptanceStatusCode 44548, and a length44528 of two 44550A. The ProductForecast entity 44532A includes aValidityPeriod 44554A having one or zero occurrence 44556A and a datatype of GDT 44558A DateTimePeriod 44560A. The ValidityPeriod 44554Aincludes a StartDateTime 44564A and EndDateTime 44570A, wherein each hasone or zero occurrence 44566A and 72A, respectively.

The Party package 44576A includes a BuyerParty entity 44580A, aVendorParty entity 44538B, and a Note 44596B. The Buyerparty entity44580A is of type CDT 44584A BusinessTransactionDocumentParty 44586A.There is one or zero 44582A BuyerParty entity 44580A for each Partypackage 44576A. The VendorParty entity 44538B is of type CDT 44542BBusinessTransactionDocumentParty 44544B. There is one or zero 44540BVendorParty entity 44538B for each Party package 44576A. The Note 44596Bhas one or zero occurrence 44598B, a data type of GDT 44500C Note44502C, and a length 44524 of 1 to 132 44504C.

The BuyerParty entity 44580A includes an InternalID 44592A, a StandardID44502B, a BuyerID 44514B, and a VendorID 44526B. The InternalID 44592Ahas zero or one occurrence 44594A, a data type of CDT 44596APartyInternalID 44598A, and a length 44524 of 1 to 10 44500B. TheStandardID 44502B has any number of occurrences 44504B, a data type ofCDT 44506B PartyStandardID 44508B, and a length 44524 of 1 to 13. TheBuyerID 44514B has zero or one occurrence 44516B, a data type of CDT44518B PartyPartyID 44520B, and a length 44524 of 1 to 10 44522B. TheVendorID 44526B has zero or one occurrence 44528B, a data type of CDT44530B PartyPartyID 44532B and a length 44524 of 1 to 10 44534B.

The VendorParty entity 44538B includes an InternalID 44550B, aStandardID 44560B, a BuyerID 44572B, and a VendorID 44584B. TheInternalID 44550B has zero or one occurrence 44552B, a data type CDT44554B PartyInternalID 44556B, and a length 44524 of 1 to 10 44558B. TheStandardID 44560B has any number of occurrences 44562B, a data type CDT44564B PartyStandardID 44566B, and a length 44524 of 1 to 13 44568B. TheBuyerID 44572B has zero or one occurrence 44574B, a data type CDT 76BPartyPartyID 44578B, and a length 44524 of 1 to 10 44580B. The VendorID44584B has zero or one occurrence 44586B, a data type CDT 44588BPartyPartyID 44590B, and a length 44524 of 1 to 10 44592B.

The Item package 44578A includes an Item entity 44506C, a Locationpackage 44516C, and a ProductInformation package 44518C. There is one ormore 44508C Item entities 44506C for each Item package 44578A and it isof data type AGDT 44510C ProductForecastRevisionItem 44512C.

The Location package 44516C includes a ShipFromLocation entity 44520C,and a ShipToLocation entity 44578C. The ShipFromLocation entity 44520Cis of type CDT 44524C BusinessTransactionDocumentShipFromLocation44526C. There is one or zero 44522C ShipFromLocation entity 44520C foreach Location package 44516C. The ShipToLocation entity 44578C is oftype CDT 44582C BusinessTransactionDocumentLocation 44584C. There is one44580C ShipToLocation entity 44578C for each Location package 44516C.

The ShipFromLocation entity 44520C includes an InternalID 44532C, aStandardID 44542C, a BuyerID 44554C, and a VendorID 44566C. TheInternalID 44532C has zero or one occurrence 44534C, a data type of CDT44536C LocationInternalID 44538C, and a length 44524 of 1 to 20 44540C.The StandardID 44542C has any number of occurrences 44544C, a data typeof CDT 44546C LocationStandardID 44548C, and a length 44524 of 1 to 1344550C. The BuyerID 44554C has zero or one occurrence 44554C, a datatype of CDT 44556C LocationPartyID 44558C and a length 44524 of 1 to 2044562C. The VendorID 44566C has zero or one occurrence 44568C, a datatype of CDT 44570C LocationPartyID 44572C, and a length 44524 of 1 to 2044574C.

The ShipToLocation entity 44578C includes an InternalID 44590C, aStandardID 44500D, a BuyerID 44512D, and a VendorID 44526D. TheInternalID 44590C has zero or one occurrence 44592C, a data type of CDT44594C LocationInternalID 44596C, and a length 44524 of 1 to 20 44598C.The StandardID 44500D has any number of occurrences 44502D, a data typeof CDT 44504D LocationStandardID 44506D, and a length 44524 of 1 to 1344508D. The BuyerID 44512D has zero or one occurrence 44514D, a datatype of CDT 44516D LocationPartyID 44518D, and a length 44524 of 1 to 2044520D. The VendorID 44526D has zero or one occurrence 44528D, a datatype of CDT 44530D LocationPartyID 44532D, and a length 44524 of 1 to 2044534D.

The ProductInformation package 44518C includes a Product entity 44538D.The Product entity 44538D is of type CDT 44542DBusinessTransactionDocumentProduct 44544D, and there is one 44540DProduct entity 44538D for each ProductInformation package 44518C. TheProduct entity 44538D includes an InternalID 44550D, a StandardID44560D, a BuyerID 44572D, a VendorID 44584D, and a PackageQuantity44596D. The InternalID 44550D has zero or one occurrence 44552D, a datatype of CDT 44554D ProductInternalID 44556D, and a length 44524 of 1 to40 44558D. The StandardID 44560D has zero or one occurrence 44562D, adata type of CDT 44564D ProductStandardID 44566D, and a length 44524 of1 to 14 44568D. The BuyerID 44572D has zero or one occurrence 44574D, adata type of CDT 44576D ProductPartyID 44578D, and a lenth 44524 of 1 to40 44580D. The VendorID 44584D has zero or one occurrence 44586D, a datatype of CDT 44588D ProductPartyID 44590D, and a length 44524 of 1 to 4044592D. The PackageQuantity 44596D has zero or one occurrence 44598D, adata type of GDT 44500E Quantity 44502E, and a length 44524 of 19 or 644504E.

The Item package 44578A also includes a SalesForecastTimeSeries 44506E,PromotionSalesForecastTimeSeries 44584E, OrderForecastTimeSeries 44562F,and PromotionOrderForecastTimeSeries 44540G. The SalesForecastTimeSeries44506E has one or zero occurrence 44508E and a data type of CDT 44510ERevisionQuantityTimeSeries 44512E. The PromotionSalesForecastTimeSeries44584E has one or zero occurrence 44586E, and a data type of CDT 44588ERevisionQuantityTimeSeries 44590E. The OrderForecastTimeSeries 44562Fhas one or zero occurrence 44564F and a data type of CDT 44566FRevisionQuantityTimeSeries 44568F. The PromotionOrderForecastTimeSeries44540G has one or zero occurrence 44542G and a data type of CDT 44544GRevisionQuantityTimeSeries 44546G.

The SalesForecastTimeSeries 44510E includes an Item 44514E. The Item44514E has any number of occurrences 44516E. The Item 44514E includes aValidityPeriod 44520E, a Quantity 44542E, a FixedIndicator 44552E,AdjustmentReasonCode 44560E, and a Note 44572E. The ValidityPeriod44520E has one occurrence 44522E and a data type of GDT 44524EDateTimePeriod 44526E. The ValidityPeriod 44520E includes aStartDateTime 44530E and EndDateTime 44536E, wherein each has one orzero occurrence 44532E and 44438E, respectively. The Quantity 44542E hasone occurrence 44544E and a data type of GDT 44546E Quantity 44548E. TheFixedIndicator 44552E has one or zero occurrence 44554E and a data typeof GDT 44556E FixedIndicator 44558E. The AdjustmentReasonCode 44560E hasone or zero occurrence 44562E, a data type of GDT 44564EAdjustmentReasonCode 44566E, and a length 44524 of 1 to 35 44568E. TheNote 44572E has one or zero occurrence 44574E, a data type of GDT 44576ENote 44578E, and a length 44524 of 1 to 132 44580E.

The PromotionSalesForecastTimeSeries 44584E includes an Item 44592E. TheItem 44592E includes a ValidityPeriod 44598E, a Quantity 44520F, aFixedIndicator 44530F, AdjustmentReasonCode 44538F, and a Note 44550F.The Item 44592E has any number of occurrences 44594E. The ValidityPeriod44598E has one occurrence 44500Fand a data type of GDT 44502FDateTimePeriod 44504F. The ValidityPeriod 44598E includes aStartDateTime 44508F and EndDateTime 44514F, wherein each has one orzero occurrence 44510F and 44516F, respectively. The Quantity 44520F hasone occurrence 44522F and a data type of GDT 44524F Quantity 44526F. TheFixedIndicator 44530F has one or zero occurrence 44532F and a data typeof GDT 44534F FixedIndicator 44536F. The AdjustmentReasonCode 38F hasone or zero occurrence 44540F, a data type of GDT 44542FAdjustmentReasonCode 44544F, a length 44524 of 1 to 35 44546F. The Note44550F has one or zero occurrence 44552F, a data type of GDT 44554F Note44556F, and a length 44524 of 1 to 132 44558F.

The OrderForecastTimeSeries 44562F includes an Item 44570F. The Item44570F includes a ValidityPeriod 44576F, a Quantity 44598F, aFixedIndicator 44508G, AdjustmentReasonCode 44516G, and a Note 44528G.The Item 44570F has any number of occurrences 44572F. The ValidityPeriod44576F has one occurrence 44578F and a data type of GDT 44580FDateTimePeriod 44582F. The ValidityPeriod 44576F includes aStartDateTime 44586F and EndDateTime 44592F, wherein each has one orzero occurrence 44588F and 44594F, respectively. The Quantity 44598F hasone occurrence 44500G and a data type of GDT 44502G Quantity 44504G. TheFixedIndicator 44508G has one or zero occurrence 44510G and a data typeof GDT 44512G FixedIndicator 44514G. The AdjustmentReasonCode 44516G hasone or zero occurrence 44518G, a data type of GDT 44520GAdjustmentReasonCode 44522G, and a length 44524 of 1 to 35 44524G. TheNote 44528G has one or zero occurrence 44530G, a data type of GDT 44532GNote 44534G, and a length 44524 of 1 to 132 44536G.

The PromotionOrderForecastTimeSeries 44540G includes an Item 44548G. TheItem 44548G includes a ValidityPeriod 44554G, a Quantity 44576G, aFixedIndicator 44586G, AdjustmentReasonCode 44594G, and a Note 44506H.The Item 44548G has any number of occurrences 44550G. The ValidityPeriod44554G has one occurrence 44556G and a data type of GDT 44558GDateTimePeriod 44560G. The ValidityPeriod 44554G includes aStartDateTime 44564G and EndDateTime 44570G, wherein each has one orzero occurrence 44566G and 44572G, respectively. The Quantity 44576G hasone occurrence 44578G and a data type of GDT 44580G Quantity 44582G. TheFixedIndicator 44586G has one or zero occurrence 44588G and a data typeof GDT 44590G FixedIndicator 44592G. The AdjustmentReasonCode 44594G hasone or zero occurrence 44596G, a data type of GDT 44598GAdjustmentReasonCode 44500H, and a length 44524 of 1 to 35 44502H. TheNote 44506H has one or zero occurrence 44508H, a data type of GDT 44510HNote 44512H, and a length 44524 of 1 to 132 44514H.

bb) Replenishment Order Interfaces

The ReplenishmentOrder messages are used by a vendor to transfer thereplenishment orders which he or she has planned for a customer fromlogistics planning to logistics execution(ReplenishmentOrderNotification) or to confirm the fulfillment ofreplenishment orders to logistics planning(ReplenishmentOrderConfirmation). To enable a flexible response tocustomers' product requirements, the creation of replenishment orders inlogistics planning is directly linked to an optimum combination ofshipments and is transferred in this way to logistics execution toprepare and perform the outbound delivery.

The ReplenishmentOrderNotification and ReplenishmentOrderConfirmationmessages are exchanged between the Inventory Collaboration Hub (ICH) andbackend system (ERP) of a vendor as part of the “ResponsiveReplenishment (RR)” business scenario. In this scenario, the ICHperforms the “planning” function, while the vendor's backend systemperforms the “execution” function.

(1) Message Types

(a) Replenishment Order Notification

A ReplenishmentOrderNotification is the notification by logisticsplanning (SCP, vendor) to logistics execution (SCE, vendor) about areplenishment order planned for a customer/buyer to so that furtherorder processing is triggered or the relevant goods issue is prepared.The structure of the message type ReplenishmentOrderNotification isspecified by the message data typeReplenishmentOrderNotificationMessage.

(b) Replenishment Order Confirmation

A ReplenishmentOrderConfirmation is the confirmation from logisticsexecution (SCE, vendor) to logistics planning (SCP, vendor) that areplenishment order that is planned for a customer/buyer can befulfilled. The structure of the message typeReplenishmentOrderConfirmation is specified by the message data typeReplenishmentOrderConfirmationMessage. The message transmission isalways complete (“complete transmission”).

(2) Message Choreography

The following message choreography describes the possible logicalsequence of the messages that are necessary to realize the scenariobetween a Buyer 44600, a vendor's Supply Chain Planning system 44602,and a vendor's Supply Chain Execution system 44604, wherein there is aseparation of entities 44616 as between the Buyer 44600 and the Vendor.

A Buyer 44600 can use the OrderIDAssignmentNotification message 44606 totransmit valid purchase order numbers to a vendor's Supply ChainPlanning system 44602 for creating replenishment orders. Thesereplenishment orders are transmitted from the vendor's Supply ChainPlanning system 44602 to the vendor's Supply Chain Execution system44604 using the ReplenishmentOrderNotification message 44608. The SupplyChain Execution system 44604 checks the availability of the requiredproducts and uses the ReplenishmentOrderConfirmation message 44610 toconfirm that the replenishment orders have been fulfilled. The Buyer44600 is then informed of this using theVendorGeneratedOrderNotification message 44612. The Buyer 44600 can thensend an optional order confirmation to the vendor using theVendorGeneratedOrderConfirmation message 44614. If the two businesspartners collaborate very closely, this order confirmation might not benecessary. In this case, the VendorGeneratedOrderNotification 44612creates a purchase order directly on the Buyer's side.

(3) Data Model of Replenishment Order Message

FIG. 447 depicts the data model for the Replenishment Order Message. TheReplenishmentOrderMessage package 44700 message data type groupstogether the following: (1) the business information that is relevantfor sending a business document in a message and (2) theReplenishmentOrder object 44702 in the business document. TheReplenishmentOrderMessage package 44700 message includes aReplenishmentOrder object 44702, a MessageHeader 44704, and aReplenishmentOrder 44706. The template message data typeReplenishmentOrderMessage is the maximum structure (template) for thefollowing message data types: ReplenishmentOrderNotificationMessage,ReplenishmentOrderConfirmationMessage, andReplenishmentOrderInformationMessage and the associated message typesand interfaces. ReplenishmentOrderNotificationMessage,ReplenishmentOrderConfirmationMessage, andReplenishmentOrderInformationMessage are derived from theReplenishmentOrderMessage as structural views. Differences and/orconstraints of ReplenishmentOrderNotificationMessage,ReplenishmentOrderConfirmationMessage, orReplenishmentOrderInformationMessage with regard to theReplenishmentOrderMessage are listed in the relevant “Integration”section.

There is a 1:c relationship between entities in these Interfaces unlessotherwise noted herein or indicated in the Figures.

(a) Message Header Package

A MessageHeader package 44704 groups the business information that isrelevant for sending a business document in a message. It includes aMessageHeader entity 44708. There is a 1:1 relationship betweenMessageHeader entity 44708 and ReplenishmentOrderMessage entity 44702.

A MessageHeader package 44704 groups business information from theperspective of the sending application to identify the business documentin a message, information about the sender, and, optionally, informationabout the recipient.

(i) Message Header

The MessageHeader entity 44708 is divided up into a SenderParty entity44710 and a RecipientParty entity 44712. It is of type GDT:BusinessDocumentMessageHeader. The MessageHeader entity 44708 includesan ID and a CreationDateTime. The ID refers to the identification of thebusiness document in the technical message, and the CreationDateTimerefers to the creation date of the business document in the technicalmessage.

(ii) Sender Party

A SenderParty entity 44710 is the party responsible for sending abusiness document at business application level. The SenderParty entity44712 is of type GDT: BusinessDocumentMessageHeaderParty.

(iii) Recipient Party

A RecipientParty entity 44712 is the party responsible for receiving abusiness document at business application level. The RecipientPartyentity 44714 is of type GDT: BusinessDocumentMessageHeaderParty.

(b) Replenishment Order Package

The ReplenishmentOrder package 44706 groups the ReplenishmentOrderentity 44714 and its packages. It includes a Party package 44716, aDeliveryInformation package 44718, a PaymentInformation package 44720, aReplenishmentOrderItem package 44722, and a HandlingUnit package 44724.

The HandlingUnit package 44724 and its contents are not required in theReplenishmentOrderConfirmationMessage.

(i) Replenishment Order

A ReplenishmentOrder entity 44714 is a replenishment order that isplanned and executed by a vendor for his or her customer. The dates andquantities for delivering a certain product are described in the itemsand schedule lines. The business partners involved and (whereapplicable) references to other relevant business documents are alsolisted. There is a 1:1 relationship between ReplenishmentOrder entity44714 and ReplenishmentOrderMessage entity 44702.

Replenishment Order entity 44714 includes the following attributes: anActionCode and ItemListCompleteTransmissionIndicator. The ActionCode isa coded representation of an instruction to the message recipient as tohow he or she should process the replenishment order (new creation,change, or deletion). Coded representations that strictly conformsemantically with ActionCodes “01” (Create), “02” (Change), and “03”(Delete) are supported. The ActionCode is of type GDT: ActionCode. TheItemListCompleteTransmissionIndicator specifies whether all purchaseorder items are always to be transmitted (i.e., items that are nottransmitted are implicitly classified as canceled) or whether only new,changed purchase order items that have been canceled since the lasttransmission are to be transmitted. TheItemListCompleteTransmissionIndicator is of type GDT:CompleteTransmissionIndicator.

The Replenishment Order entity 44714 also includes the followingelements: an ID, a CreationDateTime, a LastChangeDateTime, aTransportMeansDescriptionCode, a TransportServiceLevelCode, aGrossWeightMeasure, a NetWeightMeasure, a GrossVolumeMeasure, and aNote. The ID is the unique identifier for the ReplenishmentOrder, and isof type GDT: BusinessTransactionDocumentID. The CreationDateTime is oftype GDT: DateTime. The LastChangeDateTime is the time that the lastchange was made to the ReplenishmentOrder, and is of type GDT: DateTime.The TransportMeansDescriptionCode is for the replenishment delivery, andis of type GDT: TransportMeansDescriptionCode. TheTransportServiceLevelCode is for the replenishment delivery (and theirswiftness in particular), and is of type GDT: TransportServiceLevelCode.The GrossWeightMeasure is of type GDT: Measure. The NetWeightMeasure isof type GDT: Measure. The GrossVolumeMeasure is the estimated grossvolume of the resulting replenishment delivery, and is of type GDT:Measure. The Note is the note about ReplenishmentOrder, for example, aninstruction for processing the order. The Note is of type GDT: Note.

(ii) Party Package

The Party package 44716 groups the business partners that are relevantfor the replenishment process. It includes a BuyerParty entity 44726,SellerParty entity 44728, and a VendorParty entity 44730.

(a) Buyer Party

BuyerParty entity 44726 is the company that purchases the goodscontained in the replenishment order. BuyerParty entity 44726 is of typeGDT: BusinessTransactionDocumentParty, whereby, in one implementation,the InternalID, the StandardID, the BuyerID, the VendorID, and Addressand, optionally, several ContactPersons with InternalID, BuyerID,VendorID, and Address are required.

For intra-enterprise communication (with common master data), theBuyerParty entity 44734 is constrained to use only InternalID for allparty entities. For inter-enterprise communication (withbusiness-partner-specific master data), the BuyerParty entity 44734 isconstrained to use only the StandardID or the partner-role-specific IDof the receiving partner for all party entities; in other words, theBuyerID is used for Supplier Collaboration scenarios, and the VendorIDis used for Customer Collaboration scernerios. Due to the differentpossibilities for ID use, all ID elements of the particular “Party” areoptional.

(b) Seller Party

The SellerParty entity 44728 is the company that sells the goodscontained in the replenishment order. SellerParty entity 44728 is oftype GDT: BusinessTransactionDocumeniParty, whereby, in oneimplementation, the InternalID, the StandardID, the BuyerID, theVendorID, and Address and, optionally, several ContactPersons withInternalID, BuyerID, VendorID, and Address are required.

For intra-enterprise communication (with common master data), theSellerParty entity 44728 is constrained to use only InternalID for allparty entities. For inter-enterprise communication (withbusiness-partner-specific master data), the SellerParty entity 44728 isconstrained to use only the StandardID or the partner-role-specific IDof the receiving partner for all party entities; in other words, theBuyerID is used for Supplier Collaboration scenarios, and the VendorIDis used for Customer Collaboration scernerios. Due to the differentpossibilities for ID use, all ID elements of the particular “Party” areoptional.

(c) Vendor Party

A VendorParty entity 44730 is the company that is to provide areplenishment delivery. VendorParty entity 44730 is of type GDT:BusinessTransactionDocumentParty, whereby, in one implementation, theInternalID, the StandardID, the BuyerID, the VendorID, and Address and,optionally, several ContactPersons with InternalID, BuyerID, VendorID,and Address are required.

For intra-enterprise communication (with common master data), theVendorParty entity 44730 is constrained to use only InternalID for allparty entities. For inter-enterprise communication (withbusiness-partner-specific master data), the VendorParty entity 44730 isconstrained to use only the StandardID or the partner-role-specific IDof the receiving partner for all party entities; in other words, theBuyerID is used for Supplier Collaboration scenarios, and the VendorIDis used for Customer Collaboration scernerios. Due to the differentpossibilities for ID use, all ID elements of the particular “Party” areoptional.

(iii) Delivery Information Package

A DeliveryInformation package 44718 groups together all the informationabout a delivery for a replenishment order. It includes DeliveryTermsentity 44732.

DeliveryTerms entity 44732 are the conditions and agreements that arevalid for executing the delivery and transporting the goods beingdelivered and for the necessary services and activities. TheDeliveryTerms entity 44732 are of the type GDT: DeliveryTerms, whereby,in one implementation, “DeliveryPriorityCode,” “Incoterms,” and“QuantityTolerance” are required.

(iv) Payment Information Package

The PaymentInformation package 44720 groups together all the paymentinformation for the replenishment order. It includes CashDiscountTerms44734.

CashDiscountTerms 44734 are the payment conditions for the replenishmentorder. The CashDiscountTerms are of type GDT: CashDiscountTerms (withthe element “Description”).

(v) Replenishment Order Item Package

The ReplenishmentOrderItem package 44722 is a group of one or more itemsin a ReplenishmentOrder. It includes a ReplenishmentOrderItem entity44736, a BusinessTransactionDocumentReference package 44738, a Partypackage 44740, a Location package 44742, a ProductInformation package44744, a Batch package 44746, a Promotion package 44748,DeliveryInformation package 44750, a PriceInformation package 44752, anda ReplenishmentOrderScheduleLine package 44754.

(a) ReplenishmentOrderItem

A ReplenishmentOrderItem entity 44736 is an item in a replenishmentorder that is planned and executed by a vendor for his or her customer.The dates and quantities for delivering a certain product are describedin the individual items and schedule lines. The business partnersinvolved and (where applicable) references to other relevant businessdocuments are also listed. There is a I :n relationship betweenReplenishmentOrderItem 44736 and ReplenishmentOrder 44714.

ReplenishmentOrderItem entity 44736 includes the following attribute:ActionCode, which is the coded representation of an instruction to themessage recipient as to how he or she should process the replenishmentorder item, and is of type GDT: ActionCode. ReplenishmentOrderItementity 44736 also includes the following elements: an ID, aHierarchyRelationship, a SubcontractingIndicator, aVendorInitiatedActionIndicator, a BlockedIndicator, aCompletedIndicator, an AcceptanceStatusCode, a ConsignmentIndicator, aThirdPartyDealIndicator, a CancelledIndicator, a CancellationReasonCode,a KanbanCardID, a NetWeightMeasure, a Note, aFollowUpReplenishmentOrderConfirmationRequirementCode, andFollowUpDespatchedDeliveryNotificationRequirementCode.

The ID identifies the item in the ReplenishmentOrder, and is of typeGDT: BusinessTransactionDocumentItemID.

The HierarchyRelationship refers to a semantic representation thatdefines the hierarchies are mapped for items that contain other items.Item hierarchies are supported for substitute products, that is, itemsfor which a subitem which has a substitute product can exist (e.g.,HierarchyRelationshipTypeCode “006”). Multilevel product hierarchies forsubstitute products are not permitted, i.e., a substitute product thatcannot itself be substituted.

The AcceptanceStatusCode is the acceptance status for executing theplanned replenishment order item, and is of type GDT:AcceptanceStatusCode. The AcceptanceStatusCode is not used in theReplenishmentOrderNotificationMessage.

The ConsignmentIndicator indicates whether or not the product quantitylisted in the item belongs to the consignment stock, and is of type GDT:ConsignmentIndicator.

The ThirdPartyDealIndicator indicates whether or not the replenishmentorder item is used in the context of a third-party deal. This is thecase, in particular, if the predecessor document of the replenishmentorder is a sales order that is referenced using theOriginSalesOrderReference. The ThirdPartyDealIndicator is of type GDT:BusinessTransactionDocumentItemThirdPartyDealIndicator.

The SubcontractingIndicator specifies whether or not the replenishmentorder item is used in the context of a subcontracting deal and is oftype GDT: SubcontractingIndicator.

The VendorInitiatedActionIndicator specifies whether the instruction tothe message recipient, which is specified in the “ActionCode”, and whichdefines how the item is to be processed, was inititated by the vendor ornot and is of type GDT: VendorInitiatedActionIndicator.

The BlockedIndicator specifies whether or not order execution of thereplenishment order is blocked and is of type GDT:BusinessTransactionBlockedIndicator.

The CompletedIndicator specifies whether the order execution is or isnot completed by the quantity of a product specified in thereplenishment order item, and is of type GDT:BusinessTransactionCompletedIndicator.

The CancelledIndicator indicates whether or not the replenishment orderitem has been cancelled (from a business perspective), and is of typeGDT: CancelledIndicator.

The CancellationReasonCode is the coded representation of thecancellation reason code of a replenishment order item, and is of typeGDT: CancellationReasonCode. The CancellationReasonCode can only be usedif the CancelledIndicator is set to “True”.

The KanBanCardID is the unique identifier for a replenishment orproduction signal that is sent from a consumer to a supplier and is oftype GDT: KanbanCardID.

The NetWeightMeasure is the net weight of the product quantity listed inthe item, and is of type GDT: Measure.

The Note is the note on the ReplenishmentOrder item. For example, thenote could be instructions for processing an item. The Note is of typeGDT: Note.

The FollowUpReplenishmentOrderConfirmationRequirementCode is the codedrepresentation of information as to whether the buyer is expecting aconfirmation message from the supplier for the Replenishment Order andis of type GDT: FollowMessageRequirementCode. If the buyer changes theRequirementCode from “Forbidden” to “Required” during an orderingprocess, the supplier should send the current confirmation status, evenfor replenishment order items that have already been delivered orinvoiced. If the code is changed from “Required” to “Forbidden”, thesupplier is allowed to send further confirmations only in the case of acancelation. Only the values “01” (required), “03” (optional) und “04”(forbidden) are permitted for theFollowUpReplenishmentOrderConfirmationRequirementCode . The Code can bechanged by the buyer only. TheFollowUpReplenishmentOrderConfirmationRequirementCode is not used in theReplenishmentOrderConfirmation.

The FollowUpDespatchedDeliveryNotificationRequirementCode is the codedrepresentation of information as to whether or not the buyer isexpecting notification from the supplier for the outbound delivery ofthe goods ordered and is of type CDT: FollowUpMessageRequirementCode. Ifthe buyer changes the RequirementCode from “Forbidden” to “Required”during an ordering process, the seller should inform the buyer of allthe new outbound deliveries for the replenishment order once the changehas been received. If the buyer changes the RequirementCode from“Required” to “Forbidden,” the seller should not send any furtherinformation about outbound deliveries. Only the values “01” (required),“03” (optional) und “04” (forbidden) are permitted for theFollowUpDespatchedDeliveryNotificationRequirementCode . The Code can bechanged by the buyer only. TheFollowUpDespatchedDeliveryNotificationRequirementCode is not used in theReplenishmentOrderConfirmation.

The CancelledIndicator and the CancellationReasonCode are not used inthe ReplenishmentOrderConfirmationMessage.

(b) Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 44738 is a group ofreferences to other business documents that can occur in thereplenishment process. It includes a PurchasingContractReference entity44756, a SchedulingAgreementReference entity 44758, aPurchaseOrderReference entity 44760, an OriginPurchaseOrderReferenceentity 44762, a SalesOrderReference entity 44764, and anOriginSalesOrderReference entity 44766.

(i) Purchasing Contract Reference

A PurchasingContractReference entity 44756 is the reference to apurchase contract or item in a purchase contract. ThePurchasingContractReference entity 44756 is of type GDT:BusinessTransactionDocumentReference.

(ii) Scheduling Agreement Reference

A SchedulingAgreementReference 44758 is the reference to a schedulingagreement or to an item in a scheduling agreement and is of type GDT:BusinessTransactionDocumentReference.

(iii) Purchase Order Reference

PurchaseOrderReference entity 447760 is the reference to the buyer'spurchase order and purchase order item created by the vendor in supplychain planning. PurchaseOrderReference entity 44760 is of type GDT:BusinessTransactionDocumentReference. PurchaseOrderReference includesthe purchase order number and purchase order item number assigned by thebuyer (sold-to party) and transferred to the vendor's supply chainplanning system with the OrderIDAssignmentNotification message. Thisreference is used to extend the sales order in the vendor's supply chainexecution system to include the buyer's external document ID.

(iv) Origin Purchase Order Reference

An OriginPurchaseOrderReference entity 44762 is the reference to theoriginal purchase order or to an item within the original purchase orderin a third-party deal. OriginPurchaseOrderReference entity 44762 is oftype GDT: BusinessTransactionDocumentReference.OriginPurchaseOrderReference entity 44762 is used for third-party dealsonly. The OriginPurchaseOrderReference entity 44762 is used in all thepurchase order documents in a third-party deal, so that the seller orvendor can reference the original purchase order of theProductRecipientParty with the OriginPurchaseOrderReference entity 44762in subsequent process steps.

(v) Sales Order Reference

A SalesOrderReference entity 44764 is the reference to the sales orderor sales order item created for the ReplenishmentOrder in the vendor'slogistics execution system. SalesOrderReference 44764 is of type GDT:BusinessTransactionDocumentReference.

The SalesOrderReference 44764 is not required in theReplenishmentOrderNotificationMessage in the “Responsive Replenishment”business scenario because the vendor's logistics execution system usesthe order number of the replenishment order directly.

This reference is used to extend the buyer's purchase order to includethe vendor's external document ID.

(vi) Origin Sales Order Reference

An OriginSalesOrderReference entity 44766 is the reference to theoriginal sales order or to an item within the original sales order in athird-party deal. The OriginSalesOrderReference entity 44766 is of typeGDT: BusinessTransactionDocumentReference.

OriginSalesOrderReference is used for third-party deals.

The OriginSalesOrderReference entity 44766 is used in all the purchaseorder documents in a third-party deal, so that the seller or vendor canreference the original sales order of the BuyerParty with theOriginSalesOrderReference entity 44766 in subsequent process steps.

(c) Party Package

The Party package entity 44740 groups the business partners that arerelevant for the replenishment process. It includes a BuyerParty entity44768, a ProductRecipentParty entity 44770 and a BillToParty entity44772.

(i) Buyer Party

A BuyerParty entity 44768 is the company that purchases the goodscontained in the replenishment order item. The BuyerParty 44768 is oftype GDT: BusinessTransactionDocumentParty, whereby, in oneimplementation, the InternalID, the StandardID, the BuyerID, theVendorID, and Address are required.

For intra-enterprise communication (with common master data), use onlyInternalID for all party entities. For inter-enterprise communication(with business-partner-specific master data), use only the StandardID orthe partner-role-specific ID of the receiving partner for all partyentities; in other words, use the BuyerID for Supplier Collaborationscenarios, and use the VendorID for Customer Collaboration scenarios.Due to the different possibilities for ID use, all ID elements of theparticular “Party” are optional.

In the case of the BuyerParty 44768, a default logic exists at headerlevel for the items. This means that the BuyerParty 44768 specified atheader level is valid for all items as long as the information specifiedat item level does not contradict this.

(ii) Product Recipient Party

A ProductRecipientParty entity 44770 is the company or person that/whoreceives the replenishment delivery. The ProductRecipientParty entity44770 is of type GDT: BusinessTransactionDocumentParty, whereby, in oneimplementation, the InternalID, the StandardID, the BuyerID, theVendorID, and Address are required.

For intra-enterprise communication (with common master data), use onlyInternalID for all party entities. For inter-enterprise communication(with business-partner-specific master data), use only the StandardID orthe partner-role-specific ID of the receiving partner for all partyentities; in other words, use the BuyerID for Supplier Collaborationscenarios, and use the VendorID for Customer Collaboration scenarios.Due to the different possibilities for ID use, all ID elements of theparticular “Party” are optional.

(iii) Bill To Party

The BillToParty entity 44772 is the company or the person to be sent theinvoice for the replenishment delivery. The BillToParty entity 44772 isof type GDT: BusinessTransactionDocumentParty, whereby, in oneimplementation, the InternalID, the StandardID, the BuyerID, theVendorID, and Address are required.

For intra-enterprise communication (with common master data), use onlyInternalID for all party entities. For inter-enterprise communication(with business-partner-specific master data), use only the StandardID orthe partner-role-specific ID of the receiving partner for all partyentities; in other words, use the BuyerID for Supplier Collaborationscenarios, and use the VendorID for Customer Collaboration scenarios.Due to the different possibilities for ID use, all ID elements of theparticular “Party” are optional.

(d) Location Package

The Location package entity 44742 groups the locations that might berelevant within the replenishment process. It includes aShipFromLocation entity 44774, a TransshipmentLocation entity 44776, anda ShipToLocation entity 44778.

(i) Ship From Package

ShipFromLocation entity 44774 is the location from which the quantity ofa product listed in the item for a ReplenishmentOrder is to bedelivered. ShipFromLocation entity 44774 is of type GDT:BusinessTransactionDocumentShipFromLocation, where the InternalID,StandardID, BuyerID, VendorID, LoadingLocation, and Address are used.There is a 1:1 relationship between ShipFromLocation entity 44774 andReplenishmentOrderItem entity 44736. For intra-enterprise communication(with common master data), use InternalID for all location entities. Forinter-enterprise communication (with business-partner-specific masterdata), use the StandardID or the partner-role-specific ID of the sendingor receiving partner for all location entities, in other words, theBuyerID or VendorID. Due to the different options for ID use, all IDelements of the particular “location” are optional.

(ii) Transshipment Location

The TransshipmentLocation entity 44776 is the location at which thequantity of a product listed in the item for a ReplenishmentOrder is tobe loaded from one vehicle to another on its way to the recipient. TheTransshipmentLocation entity 44776 is of type GDT:BusinessTransactionDocumentTransshipmentLocation, whereby, in oneimplementation, the InternalID, StandardID, BuyerID, VendorID,LoadingLocation, UnloadingLocation, and Address are required. Forintra-enterprise communication (with common master data), use InternalIDfor all location entities. For inter-enterprise communication (withbusiness-partner-specific master data), use the StandardID or thepartner-role-specific ID of the sending or receiving partner for alllocation entities, in other words, the BuyerID or VendorID. Due to thedifferent options for ID use, all ID elements of the particular“location” are optional.

(iii) Ship To Location

The ShipToLocation entity 44704A is the location to which the quantityof a product listed in the item for a ReplenishmentOrder is to bedelivered. The ShipToLocation entity 44778 is of type GDT:BusinessTransactionDocumentShipToLocation, whereby, in oneimplementation, the InternalID, StandardID, BuyerID, VendorID,UnoadingLocation, and Address are required. There is a 1:1 relationshipbetween ShipToLocation entity 44778 and ReplenishmentOrderItem entity44736. For intra-enterprise communication (with common master data), useInternalID for all location entities. For inter-enterprise communication(with business-partner-specific master data), use the StandardID or thepartner-role-specific ID of the sending or receiving partner for alllocation entities, in other words, the BuyerID or VendorID. Due to thedifferent options for ID use, all ID elements of the particular“location” are optional.

(e) Product Information Package

The ProductInformation package 44744 groups the information thatcharacterizes the product listed in the item of a ReplenishmentOrder ingreater detail. It includes a Product entity 44780.

The Product entity 44780 includes the information for identifying adelivered product and the package quantity used. Product entity 44780 isof type GDT: BusinessTransactionDocumentProduct, where the InternalID,StandardID, BuyerID, VendorID, the ChangeID, and PackageQuantity areused. There is a 1:1 relationship between Product entity 44780 andReplenishmentOrderItem entity 44736. For intra-enterprise communication(with common master data), use the InternalID for all product entities.For inter-enterprise communication (with business-partner-specificmaster data), use for all product entities either the StandardID or thepartner-role-specific ID of the sending or receiving partner, in otherwords, the BuyerID or VendorID. Due to the different options for ID use,all ID elements of the particular “product” are optional.

(f) Batch Package

The Batch package 44746 groups the information that characterizes thebatch listed in the item of a ReplenishmentOrder in greater detail. Itincludes a Batch entity 44782.

The Batch entity 44782 includes specifications for identifying a batchto be delivered. The Batch entity 44782 includes an InternalID, aBuyerID, a VendorID, a ManufacturingDate, a BestBeforeDate, and anOriginCountryCode. The InternalID is the proprietary identifier for thebatch, and is of type GDT: BatchID. The BuyerID is the unique identifierused by the BuyerParty for the batch, and is of type GDT: BatchID. TheVendorID is the unique identifier used by the VendorParty for the batch,and is of type GDT: BatchID. The ManufacturingDate is the date ofmanufacture of the batch, and is of type GDT: Date. The BestBeforeDateis the best-before date of the batch, and is of type GDT: Date. TheOriginCountryCode is the coded representation of country of origin ofthe batch, and is of type GDT: CountryCode.

(g) Promotion Package

The Promotion package 44748 groups all the data regarding marketingpromotions that are relevant for the product listed in aReplenishmentOrder item. It includes a Promotion entity 447284.

The Promotion entity 44784 includes data that identifies a marketingpromotion that is planned by the ordering party for the product to bedelivered. A Promotion entity 44784 includes an InternalID, a BuyerID,and a VendorID. The InternalID identifies the marketing promotion (forcommunication within the company), and is of type GDT:PromotionInternalID. The BuyerID identifies the marketing promotion(used by BuyerParty), and is of type GDT: PromotionPartyID. The VendorIDidentifies the marketing promotion (used by VendorParty), and is of typeGDT: PromotionPartyID.

(h) Delivery Information Package

A DeliveryInformation package 44750 groups together all the informationabout a requested delivery for a replenishment order item. It includesDeliveryTerms entity 44786.

DeliveryTerms entity 44786 are the conditions and agreements that arevalid for executing the delivery and transporting the goods beingdelivered and for the necessary services and activities. TheDeliveryTerms entity 44786 are of the type GDT: DeliveryTerms, whereby,in one implementation, “DeliveryPriorityCode,” “Incoterms,” and“QuantityTolerance” are required.

(i) Price Information Package

A PriceInformation package 44752 groups together all the priceinformation in an item of the replenishment order. It includes aNetPrice entity 44788.

The NetPrice entity 44788 is the net price for the base quantity of theproduct ordered in the item without taxes and without discount. NetPriceentity 44788 is of type GDT: Price.

(j) Replenishment Order Item Schedule Line Package

The ReplenishmentOrderItemScheduleLine package 44754 groups all of thequantity and date information for a ReplenishmentOrderItem entity 44736.It includes a ScheduleLine entity 44790 and a ConfirmedScheduleLineentity 44792.

(i) Schedule Line

The ScheduleLine entity 44790 is a schedule line containing a quantityand scheduling dates planned by the vendor for his or her customer forreplenishment deliveries of a product. There is a 1:n relationshipbetween ScheduleLine entity 44790 and ReplenishmentOrderItem entity44736.

The ScheduleLine entity 44790 includes the following attribute:ActionCode, which is a coded representation of an instruction to themessage recipient as to how he or she should process the schedule linesof the replenishment order items. The ActionCode is of type GDT:ActionCode.

The ScheduleLine entity 44790 also includes the following elements: aShipmentGroupID, a TransportPlanningPeriod, a PositioningPeriod, aLoadingPeriod, a ShippingPeriod, a DeliveryPeriod, anAvailabilityPeriod, a PickupPeriod, a Quantity, and a ReceivedQuantity.The ShipmentGroupID identifies a group of ReplenishmentOrderItems thatcan be combined for a shipment, and is of type GDT:BusinessTransactionDocumentGroupID. The TransportPlanningPeriod is theperiod in which the shipment has to be organized, and is of type GDT:DateTimePeriod. The PositioningPeriod is the period in which theproducts are picked and packed, and is of type GDT: DateTimePeriod. TheLoadingPeriod is the period in which the products are loaded onto themeans of transport, and is of type GDT: DateTimePeriod. TheShippingPeriod is the period in which the products leave the ship-fromlocation, and is of type GDT: DateTimePeriod. The DeliveryPeriod is theperiod in which the products are expected to be delivered, and is oftype GDT: DateTimePeriod. The AvailabilityPeriod is the period in whichthe products are available at the ship-to location, and is of type GDT:DateTimePeriod. The PickupPeriod is the period in which the products canbe picked up, and is of type GDT: DateTimePeriod. The Quantity is thequantity of a product in a replenishment delivery to be delivered orpicked up, and is of type GDT: Quantity. The ReceivedQuantity is theactual received product quantity of a replenishment delivery, and is oftype GDT: Quantity.

The ScheduleLine entity 44790 also includes a ComponentRequiremententity 44794. The ComponentRequirement entity 44794 refers to thecomponent requirements necessary to produce the product quantity of thereplenishment order specified in the schedule line. There is a 1:cnrelationship between a ComponentRequirement entity 44794 and theScheduleLine entity 44790.

The ComponentRequirement entity 44794 includes a Product entity 44796and a Quantity element, the latter of which refers to the productquantity for the component requirement. As a rule, only those componentrequirements that are critical, that is, either extremely expensive or,with regards to final assembly, very susceptible, are considered inplanning and communicated to the producer. Permitted scrap quantitiescan potentially be considered here. This leads to a correspondingincrease of component requirements. There is a 1:1 relationship betweena Product entity 44796 and the ComponentRequirement entity 44794.

The Product entity 44796 contains specifications to identify the productfor the component requirement. The Product entity 44796 is of type GDT:BusinessTransactionDocumentProduct, whereby, in one implementation, theInternalID, the StandardID, the BuyerID, and the VendorID are required.For intra-enterprise communication (with common master data), only usethe InternalID for all product entities. For inter-enterprisecommunication (with business-partner-specific master data), use for allproduct entities either only the StandardID or the partner-role-specificID of the sending or receiving partner, in other words, the BuyerID orVendorID. Due to the different options for ID use, all ID elements ofthe particular “product” are optional.

(ii) Confirmed Schedule Line

The ConfirmedScheduleLine entity 44792 is a schedule line with aquantity and dates from the performance schedule confirmed by thevendor's logistics execution system. The ConfirmedScheduleLine entity44792 can contain discrepancies with regard to the original scheduleline in terms of scheduling periods and delivery quantities. There is a1:cn relationship between ConfirmedScheduleLine entity 44792 andReplenishmentOrderItem entity 44736.

The structure of the ConfirmedScheduleLine entity 44792 is asScheduleLine entity 44790 but without the element “ReceivedQuantity.”The ConfirmedScheduleLine entity 44792 also includes aComponentRequirement entity 44798. The ComponentRequirement entity 44798refers to the component requirements necessary to produce the productquantity of the replenishment order specified in the schedule line.There is a 1:cn relationship between a ComponentRequirement entity 44798and the ConfirmedScheduleLine entity 44792.

The ConfirmedScheduleLine entity 44792 includes a Product entity 44700Aand a Quantity element, the latter of which refers to the productquantity for the component requirement. As a rule, only those componentrequirements that are critical, that is, either extremely expensive or,with regards to final assembly, very susceptible, are considered inplanning and communicated to the producer. Permitted scrap quantitiescan potentially be considered here. This leads to a correspondingincrease of component requirements. There is a 1:1 relationship betweena Product entity 44700A and the ComponentRequirement entity 44798.

The Product entity 44700A contains specifications to identify theproduct for the component requirement. The Product entity 44700A is oftype GDT: BusinessTransactionDocumentProduct, whereby, in oneimplementation, the InternalID, the StandardID, the BuyerID, and theVendorID are required. For intra-enterprise communication (with commonmaster data), only use the InternalID for all product entities. Forinter-enterprise communication (with business-partner-specific masterdata), use for all product entities either only the StandardID or thepartner-role-specific ID of the sending or receiving partner, in otherwords, the BuyerID or VendorID. Due to the different options for ID use,all ID elements of the particular “product” are optional.

(vi) Handling Unit Package

The HandlingUnit package 44724 groups the information that characterizesin detail how the delivery is packed or is to be packed. It includes aHandlingUnit entity 44702A.

The HandlingUnit package 44724 and HandlingUnit entity 44702A are notrequired in the ReplenishmentOrderConfirrnationMessage.

A HandlingUnit entity 44702A is a physical unit of packaging materials(load carrier, additional packaging materials) and the packaged products(of type “material”). HandlingUnit 44702A is of type GDT: HandlingUnit.There is a 1:cn relationship between HandlingUnit entity 44702A andReplenishmentOrder entity 44714.

The product listed in a ReplenishmentOrderItem can be distributed amongseveral HandlingUnits and a HandlingUnit can contain products that arelisted in several items. The products included in a HandlingUnit arespecified by the “HandlingUnitLoad” element by means of a reference tothe relevant items in the ReplenishmentOrder.

(4) Element Structure of Replenishment OrderNotification Message

The message data type element structure for theReplenishmentOrderNotification message is depicted in FIG. 448. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 44800 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 448, the interface for ReplenishmentOrderNotificationmessage includes six levels 44802, 44804, 44806, 44808, 44810, and44812. The outermost package of this interface is aReplenishmentOrderNotification package 44820, which includes aReplenishmentOrderNotification entity 44822 at the first level 44802, aBusinessDocumentMessageHeader package 44828, and a ReplenishmentOrderpackage 44830. The BusinessDocumentMessageHeader package 44828 includesa MessageHeader entity 44832 at the second level 44804. TheReplenishmentOrder package 44830 includes a ReplenishmentOrder entity44888 at the second level 44804; a Party package 44808A, aDeliveryInformation package 44810A; a TransportMeansDescriptionCode44800C, a TransportServiceLevelCode 44808C, a GrossWeightMeasure 44816C,a NetWeightMeasure 44824C, a GrossVolumeMeasure 44832C at the thirdlevel 44806; a PaymentInformation package 44812A; a Note 44846C at thethird level 44806; an Item package 44814A, and a HandlingUnit package44815A.

The ReplenishmentOrderNotification entity 44822 is of a type G/CDT 44816“ReplenishmentOrderNotification” 44826, and there is one 44824ReplenishmentOrderNotification 44822 for eachReplenishmentOrderNotification package 44820.

The BusinessDocumentMessageHeader package 44828 includes a MessageHeaderentity 44832 at the second level 44804. The MessageHeader entity 44832is of the type G/CDT 44816 “BusinessDocumentMessageHeader 44836, andthere is one 44834 MessageHeader entity 44832 for eachBusinessDocumentMessageHeader package 44828. The MessageHeader entity44832 includes an ID 44838, a CreationDateTime 44846, a SenderParty44852, and a RecipientParty 44870 at the third level 44806. The ID 44838is of the type G/CDT 44816 “BusinessDocumentMessageID” 44842, and thereis one 44840 ID44838 for each MessageHeader entity 44832. The ID 44838has a length 44818 of 1 to 35 44844. The CreationDateTime 44846 is ofthe type G/CDT 44816 “DateTime” 44850, and there is one 44848CreationDateTime 44846 for each MessageHeader entity 44832.

The SenderParty entity 44852 in the MessageHeader entity 44832 is of thetype 44816 “BusinessDocumentMessageHeaderParty” 44856, and there is zeroor one 44854 SenderParty entity 44852 for each MessageHeader entity44832. The SenderParty entity 44852 includes an InternalID 44858 and aStandardID 44864 at the fourth level 44808. The InternaiID 44858 is ofthe type 44816 “PartyInternalID” 44862, and there is zero or one 44860InternalID 44858 for each SenderParty entity 44852. The StandardID 44864is of the type 44816 “PartyStandardID” 44868, and there is any number44866 of StandardID 44864 for each SenderParty entity 44852.

The RecipientParty entity 44870 in the MessageHeader entity 44832 is ofthe type 44816 “BusinessDocumentMessageHeaderParty” 44874, and there iszero or one 44872 RecipientParty entity 44870 for each MessageHeaderentity 44832. The RecipientParty entity 44870 includes an InternalID44876 and a StandardID 44882 at the fourth level 44808. The InternaiID44876 is of the type 44816 “PartyInternalID” 44880, and there is zero orone 44878 InternalID 44876 for each RecipientParty entity 44870. TheStandardID 44882 is of the type 44816 “PartyStandardID” 44886, and thereis any number 44884 of StandardID 44882 for each RecipientParty entity44870.

The ReplenishmentOrder entity 44888 in the ReplenishmentOrder package44830 is of a type G/CDT 44816 “ReplenishmentOrder” 44892, and there isone 44890 ReplenishmentOrder entity 44888 for each ReplenishmentOrderpackage 44830. The ReplenishmentOrder entity 44888 includes an ID 44894,an @actionCode 44894L, an @itemListCompleteTransmissionIndicator 44802M,a CreationDateTime 44802A, and a LastChangeDateTime 44808M at the thirdlevel 44806. The @actionCode 44894L is of a type G/CDT 44816 ActionCode44898L, and there is zero to one 44896L @actionCode 44894L 44894L foreach ReplenishmentOrder entity 44888. The @actionCode 44894L has alength 44816 of 2 44800M. The @itemListCompleteTransmissionIndicator44802M is of a type G/CDT 44816 CompleteTransmissionIndicator 44806M,and there is zero to one 44804M @itemListCompleteTransmissionIndicator44802M for each ReplenishmentOrder entity 44888. The ID entity 44894 isof a type G/CDT 44816 “BusinessTransactionDocumentID” 44898, and thereis one 44896 ID 44894 for each ReplenishmentOrder entity 44888. The ID44894 has a length 44818 of 1 to 35 44800A. The CreationDateTime 44802Ais of a type G/CDT 44816 “DateTime” 44806A, and there is one 44804ACreationDateTime 44802A for each ReplenishmentOrder entity 44888. TheLastChangeDateTime 44808M is of a type G/CDT 44816 “DateTime” 44812M,and there is zero to one 44810M LastChangeDateTime 44808M for eachReplenishmentOrder entity 44888.

The Party package 44808A includes a BuyerParty entity 44816A, a SellerParty entity 44814M, and a VendorParty entity 44890A at the third level44806. The BuyerParty entity 44816A is of a type 44816“BusinessTransactionDocumentParty” 44820A, and there is zero or one44818A BuyerParty entity 44816A for each Party package 44808A. TheSellerParty entity 44814M is of a type 44816“BusinessTransactionDocumentParty” 44818M, and there is zero or one448116M SellerParty entity 44814M for each Party package 44808A. TheVendorParty entity 44890A is of a type 44816“BusinessTransactionDocumentParty” 44894A, and there is zero or one44892A VendorParty entity 44890A for each Party package 44808A.

The BuyerParty entity 44816A includes an InternalID 44822A, a StandardID44830A, a BuyerID 44838A, a VendorID 44846A, an Address 44854A, and aContactPerson 44860A at the fourth level 44808. The InternalID 44822A isof the type G/CDT 44816 “PartyInternalID” 44826A, and there is zero orone 44824A InternalID 44822A for each BuyerParty entity 44816A. TheInternalID 44822A has a length 44818 of 1 to 10 44828A. The StandardID44830A is of the type G/CDT 44816 “PartyStandardID” 44834A, and there isany number 44832A of StandardID 44830A for each BuyerParty entity44816A. The StandardID 44830A has a length 44818 of 1 to 13 or 1 to 944836A. The BuyerID 44838A is of the type G/CDT 44816 “PartyPartyID”44842A, and there is zero or one 44840A BuyerID 44838A for eachBuyerParty entity 44816A. The BuyerID 44838A has a length 44818 of 1 to10 44844A. The VendorID 44846A is of the type G/CDT 44816 “PartyPartyID”44850A, and there is zero or one 44848A VendorID 44846A for eachBuyerParty entity 44816A. The VendorID 44846A has a length 44818 of 1 to10 44852A. The Address 44854A is of the type G/CDT 44816 “Address”44858A, and there is zero or one 44856A Address 44854A for eachBuyerParty entity 44816A. The ContactPerson 44860A is of the type G/CDT44816 “ContactPerson” 44864A, and there is any number 44862A ofContactPerson 44860A for each BuyerParty entity 44816A.

The ContactPerson 44860A in the BuyerParty entity 44816A includes anInternalID 44866A, a BuyerID 44872A, a VendorID 44878A, and an Address44884A at the fifth level 44810. The InternalID 44866A is of the typeG/CDT 44816 “ContactPersonInternalID” 44870A, and there is zero or one44868A InternalID 44866A for each ContactPerson 44860A. The BuyerID44872A is of the type G/CDT 44816 “ContactPersonPartyID” 44876A, andthere is zero or one 44874A BuyerID 44872A for each ContactPerson44860A. The VendorID 44878A is of the type G/CDT 44816“ContactPersonPartyID” 44882A, and there is zero or one 44880A VendorID44878A for each ContactPerson 44860A. The Address 44884A is of the typeG/CDT 44816 “Address” 44888A, and there is zero or one 44886A Address44884A for each ContactPerson 44860A.

The SellerParty entity 44814M includes an InternalID 44820M, aStandardID 44828M, a BuyerID 44828M, a VendorID 44844M, an Address44852M, and a ContactPerson 44858M at the fourth level 44808. TheInternalID 44820M is of the type G/CDT 44816 “PartyInternalID” 44826A,and there is zero or one 44824A InternalID 44820M for each SellerPartyentity 44814M. The InternalID 44820M has a length 44818 of 1 to 1044828A. The StandardID 44828M is of the type G/CDT 44816“PartyStandardID” 44834A, and there is any number 44832A of StandardID44828M for each SellerParty entity 44814M. The StandardID 44828M has alength 44818 of 1 to 13 or 1 to 9 44836A. The BuyerID 44828M is of thetype G/CDT 44816 “PartyPartyID” 44842A, and there is zero or one 44840ABuyerID 44828M for each SellerParty entity 44814M. The BuyerID 44828Mhas a length 44818 of 1 to 10 44844A. The VendorID 44844M is of the typeG/CDT 44816 “PartyPartyID” 44850A, and there is zero or one 44848AVendorID 44844M for each SellerParty entity 44814M. The VendorID 44844Mhas a length 44818 of 1 to 10 44852A. The Address 44852M is of the typeG/CDT 44816 “Address” 44858A, and there is zero or one 44856A Address44852M for each SellerParty entity 44814M. The ContactPerson 44858M isof the type G/CDT 44816 “ContactPerson” 44864A, and there is any number44862A of ContactPerson 44858M for each SellerParty entity 44814M.

The ContactPerson 44858M in the SellerParty entity 44814M includes anInternalID 44864M, a BuyerID 44870M, a VendorID 44876M, and an Address44882M at the fifth level 44810. The InternalID 44864M is of the typeG/CDT 44816 “ContactPersonInternalID” 44870A, and there is zero or one44868A InternalID 44864M for each ContactPerson 44858M. The BuyerID44870M is of the type G/CDT 44816 “ContactPersonPartyID” 44876A, andthere is zero or one 44874A BuyerID 44870M for each ContactPerson44858M. The VendorID 44876M is of the type G/CDT 44816“ContactPersonPartyID” 44882A, and there is zero or one 44880A VendorID44876M for each ContactPerson 44858M. The Address 44882M is of the typeG/CDT 44816 “Address” 44888A, and there is zero or one 44886A Address44882M for each ContactPerson 44858M.

The VendorParty entity 44890A includes an InternalID 44896A, aStandardID 44804B, a BuyerID 44812B, a VendorID 44820B, an Address44828B, and a ContactPerson 44834B at the fourth level 44808. TheInternalID 44896A is of the type G/CDT 44816 “PartyInternalID” 44800B,and there is zero or one 44898A InternalID 44896A for each VendorPartyentity 44890A. The InternalID 44896A has a length 44818 of 1 to 1044802B. The StandardID 44804B is of the type G/CDT 44816“PartyStandardID” 44808B, and there is any number 44806B of StandardID44804B for each VendorParty entity 44890A. The StandardID 44804B has alength 44818 of 1 to 13 or 1 to 9 44810B. The BuyerID 44812B is of thetype G/CDT 44816 “PartyPartyID” 44816B, and there is zero or one 44814BBuyerID 44812B for each VendorParty entity 44890A. The BuyerID 44812Bhas a length 44818 of 1 to 10 44818B. The VendorID 44820B is of the typeG/CDT 44816 “PartyPartyID” 44824B, and there is zero or one 44822BVendorID 44820B for each VendorParty entity 44890A. The VendorID 44820Bhas a length 44818 of 1 to 10 44826B. The Address 44828B is of the typeG/CDT 44816 “Address” 44832B, and there is zero or one 44830B Address44828B for each VendorParty entity 44890A. The ContactPerson 44834B isof the type G/CDT 44816 “ContactPerson” 44838B, and there is any number44836B of ContactPerson 44834B for each VendorParty entity 44890A.

The ContactPerson 44834B in the VendorParty entity 44890A includes anInternalID 44840B, a BuyerID 44846B, a VendorID 44852B, and an Address44858B at the fifth level 44810. The InternalID 44840B is of the typeG/CDT 44816 “ContactPersonInternalID” 44844B, and there is zero or one44842B InternalID 44840B for each ContactPerson 44834B. The BuyerID44846B is of the type G/CDT 44816 “ContactPersonPartyID” 44850B, andthere is zero or one 44848B BuyerID 44846B for each ContactPerson44834B. The VendorID 44852B is of the type G/CDT 44816“ContactPersonPartyID” 44856B, and there is zero or one 44854B VendorID44852B for each ContactPerson 44834B. The Address 44858B is of the typeG/CDT 44816 “Address” 44862B, and there is zero or one 44860B Address44858B for each ContactPerson 44834B.

DeliveryInformation package 44810A in the ReplenishmentOrder package44830 includes a DeliveryTerms entity 44864B at the third level 44806.DeliveryTerms entity 44864B is of a type G/CDT 44816 “DeliveryTenns”44868B, and there is zero or one 44866B DeliveryTerms entity 44864B foreach DeliveryInformation package 44810A. The DeliveryTerns entity 44864Bincludes a DeliveryPriorityCode 44870B, an Incoterms 44876B, and aQuantityTolerance 44882B at the fourth level 44808. TheDeliveryPriorityCode 44870B is of a type G/CDT 44816“BusinessTransactionPriorityCode” 44874B, and there is zero or one44872B DeliveryPriorityCode 44870B for each DeliveryTerms entity 44864B.The Incoterms 44876B is of a type G/CDT 44816 “Incoterms” 44880B, andthere is zero or one 44878B Incoterms 44876B for each DeliveryTerms44864B. The QuantityTolerance 44882B is of a type G/CDT 44816“QuantityTolerance” 44886B, and there is zero or one 44884BQuantityTolerance 44882B for each DeliveryTerms entity 44864B.

The QuantityTolerance 44882B in DeliveryTerms entity 44864B includes anOverPercent 44888B and an UnderPercent 44894B at the fifth level 44810.The OverPercent 44888B is of a type G/CDT 44816 “Percent” 44892B, andthere is zero or one 44890B OverPercent 44888B for each QualityTolerance44882B. The UnderPercent 44894B is of a type G/CDT 44816 “Percent”44898B, and there is zero or one 44896B UnderPercent 44894B for eachQualityTolerance 44882B.

The ReplenishmentOrder package 44830 includes aTransportMeansDescriptionCode 44800C, a TransportServiceLevelCode44808C, a GrossWeightMeasure 44816C, a NetWeightMeasure 44824C, aGrossVolumeMeasure 44832C, and a Note 44846C at the third level 44806.The TransportMeansDescriptionCode 44800C is of the type G/CDT 44816“TransportMeansDescriptionCode” 44804C, and there is zero or one 44802CTransportMeansDescriptionCode 44800C for each ReplenishmentOrder package44830. The TransportMeansDescriptionCode 44800C has a length 44818 of 444806C. The TransportServiceLevelCode 44808C is of the type G/CDT 44816“TransportServiceLevelCode” 44812C, and there is zero or one 44810CTransportServiceLevelCode 44808C for each ReplenishmentOrder package44830. The TransportServiceLevelCode 44808C has a length 44818 of 244814C. The GrossWeightMeasure 44816C is of the type G/CDT 44816“Measure” 44820C, and there is zero or one 44818C GrossWeightMeasure44816C for each ReplenishmentOrder package 44830. The GrossWeightMeasure44816C has a length 44818 of 19 or 6 44822C. The NetWeightMeasure 44824Cis of the type G/CDT 44816 “Measure” 44828C, and there is zero or one44826C NetWeightMeasure 44824C for each ReplenishmentOrder package44830. The NetWeightMeasure 44824C has a length 44818 of 19 or 6 44830C.The GrossVolumeMeasure 44832C is of the type G/CDT 44816 “Measure”44836C, and there is zero or one 44834C GrossVolumeMeasure 44832C foreach ReplenishrnentOrder package 44830. The GrossVolumeMeasure 44832Chas a length 44818 of 19 or 6 4483 8C. The Note 44846C is of the typeG/CDT 44816 “Note” 44850C, and there is zero or one 44848C Note 44846Cfor each ReplenishmentOrder package 44830. The Note 44846C has a length44818 of 1 to 132 44852C.

The PaymentInformation package 44812A includes a CashDiscountTermsentity 44840C at the third level 44806. The CashDiscountTerms entity44840C is of a type G/CDT 44816 “CashDiscountTerms” 44844C, and there iszero or one 44842C CashDiscountTerms entity 44840C for eachPaymentInformation package 44812A.

The Item package 14A includes an Item entity 44854C at the third level44806, a NetWeightMeasure 44808I and a Note 44858I at the fourth level44808, and the following packages: aBusinessTransactionDocumentReference 44818D, a Party package 44820D, aLocation package 44822D, a ProductInformation package 44824D, a Batchpackage 44826D, a Promotion package 44828D, a DeliveryInformationpackage 44830D, a PriceInformation package 44832D, and a ScheduleLinepackage 44834D.

The Item entity 44854C is of a type G/CDT 44816 “ReplenishmentOrderItem”44858C, and there is at least one 44856C Item entity 44854C for eachItem package 44814A. The Item entity 44854C includes an ActionCode44860C, an ID 44868C, a HierarchieRelationship 44888M, anAcceptanceStatusCode 44876C, a CompletedIndicator 44884C, aConsignmentReasonCode 44892C, a ThirdPartyDealIndicator 44800D, aSubcontractingIndicator 44804N, a VendorInitiatedActionIndicator 44810N,a 30 BlockedIndicator 44816N, a CancelledIndicator 44806D, and aCancellationReasonCode 44812D at the fourth level 44808. The ActionCode44860C is of a type G/CDT 44816 “ActionCode” 44864C, and there is zeroor one 44862C ActionCode 44860C for each Item entity 44854C. TheActionCode 44860C has a length 44818 of 2 44866C. The ID 44868C is of atype G/CDT 44816 “BusinessTransactionDocumentItemID” 44872C, and thereis one 44870C ID 44868C for each Item entity 44854C. The ID 44868C has alength 44818 of 1 to 10 44874C. The AcceptanceStatusCode 44876C is of atype G/CDT 44816 “AcceptanceStatusCode” 44880C, and there is zero or one44878C AcceptanceStatusCode 44876C for each Item entity 44854C. TheAcceptanceStatusCode 44876C has a length 44818 of two 44882C. There iszero or one HierarchieRelationship 44888M for each Item entity 44854C.The HierarchieRelationship 44888M includes elements ParentitemID 44892Mand TypeCode 44898M. The ParentItemID 44892M is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44896N, and there is zero or one44894N ParentItemID 44892M for each Item entity 44854C. The TypeCode44898M is of a type G/CDT 44816 “BusinessTransactionDocumentReference”44802N, and there is zero or one 44800N TypeCode 44898M for each Itementity 44854C. The AcceptanceStatusCode 44876C has a length 44818 of two44882C.The CompletedIndicator 44884C is of a type G/CDT 44816“BusinessTransactionCompletedIndicator” 44888C, and there is zero or one44886C CompletedIndicator 44884C for each Item entity 44854C. TheCompletedIndicator 44884C has a length 44818 of one 44890C. TheConsignmentCode 44892C is of a type G/CDT 44816 “ConsignmentIndicator”44896C, and there is zero or one 44894C ConsignmentCode 44892C for eachItem entity 44854C. The ConsignmentCode 44892C has a length 44818 of one44898C. The ThirdPartyDealIndicator 44800D is of a type G/CDT 44816“BusinessTransactionDocumentItemThirdPartyDealIndicator” 44804D, andthere is zero or one 44802D ThirdPartyDealIndicator 44800D for each Itementity 44854D. The SubcontractingIndicator 44804N is of a type G/CDT44816 “SubcontractingIndicator” 44808N, and there is zero or one 44806NSubcontractingIndicator 44804N for each Item entity 44854D. TheVendorInitiatedActionIndicator 44810N is of a type G/CDT 44816“PartyInitiatedActionIndicator” 44814N, and there is zero or one 44812NVendorInitiatedActionIndicator 44810N for each Item entity 44854D. TheBlockedIndicator 44816N is of a type G/CDT 44816“BusinessTransactionBlockedIndicator” 44820N, and there is zero or one44818N BlockedIndicator 44816N for each Item entity 44854D. TheCancelledIndicator 44806D is of a type G/CDT 44816 “CancelledIndicator”44810D, and there is zero or one 44808D CancelledIndicator 44806D foreach Item entity 44854C. The CancellationReasonCode 44812D is of a typeG/CDT 44816 “CancellationReasonCode” 44816D, and there is zero or one44814D CancellationReasonCode 44812D for each Item entity 44854C.

The BusinessTransactionDocumentReference package 44818D includes aPurchaseContractReference entity 44836D, a SchedulingAgreementReference44822N, a PurchaseOrderReference entity 44842D, anOriginPurchaseOrderReference entity 44848D, a SalesOrderReference entity44854D, and an OriginSalesOrderReference entity 44860D at the fourthlevel 44808. The PurchaseContractReference entity 44836D is of a typeG/CDT 44816 “BusinessTransactionDocumentReference” 44840D, and there iszero or one 44838D PurchaseContractReference entity 44836D for eachBusinessTransactionDocumentReference package 44818D. TheSchedulingAgreementReference 44822N is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44826N, and there is zero or one44824N SchedulingAgreementReference 44822N for eachBusinessTransactionDocumentReference package 44818D. ThePurchaseOrderReference entity 44842D is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44846D, and there is zero or one44844D PurchaseContractReference entity 44842D for eachBusinessTransactionDocumentReference package 44818D. TheOriginPurchaseOrderReference entity 44848D is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44852D, and there is zero or one44850D OriginPurchaseOrderReference entity 44848D for eachBusinessTransactionDocumentReference package 44818D. TheSalesOrderReference entity 44854D is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44858D, and there is zero or one44856D SalesOrderReference entity 44854D for eachBusinessTransactionDocumentReference package 44818D. TheOriginSalesOrderReference entity44860D is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44864D, and there is zero or one44862D OriginSalesOrderReference entity44860D for eachBusinessTransactionDocumentReference package 44818D.

The Party package 44820D includes a BuyerParty entity 44828N, aProductRecipientParty entity 44866D and a BillToParty entity 44810E atthe fourth level 44808. The BuyerParty entity 44828N is of a type G/CDT44816 “BusinessTransactionDocumentParty” 44832N, and there is zero orone 44830N BuyerParty entity 44828N for each Party package 44820D. TheProductRecipientParty entity 44866D is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44870D, and there is zero or one44868D ProductRecipientParty entity 44866D for each Party package44820D. The BillToParty entity 44810E is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44814E, and there is zero or one44812E BillToParty entity 44810E for each Party package 44820D. TheProductRecipientParty entity 44866D is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44870D, and there is zero or one44868D ProductRecipientParty entity 44866D for each Party package44820D. The BillToParty entity 44810E is of a type G/CDT 44816“BusinessTransactionDocumentReference” 44814E, and there is zero or one44812E BillToParty entity 44810E for each Party package 44820D.

The BuyerParty entity 44828N includes an InternalID 44834N, a StandardID44842N, a BuyerID 44850N, a VendorID 44860N, and an Address 44868N atthe fifth level 44810. The InternalID 44834N is of a type G/CDT 44816“PartyInternalID” 44838N, and there is zero or one 44836N InternalID44834N for each BuyerParty entity 44828N. The InternalID 44834N has alength 44818 of 1 to 10 44840N. The StandardID 44842N is of a type G/CDT44816 “PartyStandardID” 44846N, and there is any number 44844N ofStandardID 44842N for each BuyerParty entity 44828N. The StandardID44842N has a length 44818 of 1 to 13 or 1 to 9 44848N. The BuyerID44850N is of a type G/CDT 44816 “PartyPartyID “44854N, and there is zeroor one 44852N BuyerID 44850N for each BuyerParty entity 44828N. TheBuyerID 44850N has a length 44818 of 1 to 10 44852N. The VendorID 44860Nis of a type G/CDT 44816 “PartyPartyID” 44864N, and there is zero or one44862N VendorID 44896D for each BuyerParty entity 44828N. The VendorID44860N has a length 44818 of 1 to 10 44866N. The Address 44868N is of atype G/CDT 44816 “Address” 44872N, and there is zero or one 44870NAddress 44872N for each BuyerParty entity 44828N.

The ProductRecipientParty entity 44866D includes an InternalID 44872D, aStandardID 44880D, a BuyerID 44888D, a VendorID 44896D, and an Address44804E at the fifth level 44810. The InternalID 44872D is of a typeG/CDT 44816 “PartyInternalID” 44876D, and there is zero or one 44874DInternalID 44872D for each ProductRecipientParty entity 44866D. TheInternalID 44872D has a length 44818 of 1 to 10 44878D. The StandardID44880D is of a type G/CDT 44816 “PartyStandardID” 44884D, and there isany number 44882D of StandardID 44880D for each ProductRecipientPartyentity 44866D. The StandardID 44880D has a length 44818 of 1 to 13 or 1to 9 44886D. The BuyerID 44850N is of a type G/CDT 44816 “PartyPartyID“44892D, and there is zero or one 44890D BuyerID 44850N for eachProductRecipientParty entity 44866D. The BuyerID 44850N has a length44818 of 1 to 10 44894D. The VendorID 44896D is of a type G/CDT 44816“PartyPartyID” 44800E, and there is zero or one 44898D VendorID 44896Dfor each ProductRecipientParty entity 44866D. The VendorID 44896D has alength 44818 of 1 to 10 44802E. The Address 44804E is of a type G/CDT44816 “Address” 44808E, and there is zero or one 44806E Address 44804Efor each ProductRecipientParty entity 44866D.

The BillToParty entity 44810E includes an InternalID 44816E, aStandardID 44824E, a BuyerID 44832E, a VendorID 44840E, and an Address44848E at the fifth level 44810. The InternalID 44816E is of a typeG/CDT 44816 “PartyInternalID” 44820E, and there is zero or one 44818EInternalID 44816E for each BillToParty entity 44810E. The InternalID44816E has a length 44818 of 1 to 10 44822E. The StandardID 44824E is ofa type G/CDT 44816 “PartyStandardID” 44828E, and there is any number44826E of StandardID 44824E for each BillToParty entity 44810E. TheStandardID 44824E has a length 44818 of 1 to 13 or 1 to 9 44830E. TheBuyerID 44832E is of a type G/CDT 44816 “PartyPartyID “44836E, and thereis zero or one 44834E BuyerID 44832E for each BillToParty entity 44810E.The BuyerID 44832E has a length 44818 of 1 to 10 44838E. The VendorID44840E is of a type G/CDT 44816 “PartyPartyID” 44844E, and there is zeroor one 44842E VendorID 44840E for each BillToParty entity 44810E. TheVendorID 44840E has a length 44818 of 1 to 10 44846E. The Address 44848Eis of a type G/CDT 44816 “Address” 44852E, and there is zero or one44850E Address 44848E for each BillToParty entity 44810E.

The Location package 44822D includes a ShipFromLocation entity 44854E, aTransshipmentLocation entity 44836F, and a ShipToLocation entity 44892Fat the fourth level 44808. The ShipFromLocation entity 44854E is of atype 44816 G/CDT “BusinessTransactionDocumentShipFromLocation” 44858E,and there is one 44856E ShipFromLocation entity 44854E for each Locationpackage 44822D. The TransshipmentLocation entity 44836F is of a type44816 G/CDT “BusinessTransactionDocumentTransshipmentLocation” 44840F,and there is zero or one 44838F TransshipmentLocation entity 44836F foreach Location package 44822D. The ShipToLocation entity 44892F is of atype 44816 G/CDT “BusinessTransactionDocumentShipToLocation” 44896F, andthere is one 44894F ShipToLocation entity 44892F for each Locationpackage 44822D.

The ShipFromLocation entity 44854E includes an InternalID 44860E, aStandardID 44868E, a BuyerID 44876E, a VendorID 44884E, aLoadingLocation 44892E and an Address 44830F at the fifth level 44810.The InternalID 44860E is of the type G/CDT 44816 “LocationInternalID”44864E, and there is zero or one 44862E InternalID 44860E for eachShipFromLocation entity 44854E. The InternalID 44860E has a length 44818of 1 to 20 44866E. The StandardID 44868E is of the type G/CDT 44816“LocationStandardID” 44872E, and there is any number 44870E StandardID44868E for each ShipFromLocation entity 44854E. The StandardID 44868Ehas a length 44818 of 1 to 13 44874E. The BuyerID 44876E is of the typeG/CDT 44816 “LocationPartyID” 44880E, and there is zero or one 44878EBuyerID 44876E for each ShipFromLocation entity 44854E. The BuyerID44876E has a length 44818 of 1 to 20 44882E. The VendorID 44884E is ofthe type G/CDT 44816 “LocationPartyID” 44888E, and there is zero or one44886E VendorID 44884E for each ShipFromLocation entity 44854E. TheVendorID 44884E has a length 44818 of 1 to 20 44890E. TheLoadingLocation 44892E is of the type G/CDT 44816“BusinessTransactionDocumentLocation” 44896E, and there is zero or one44894E LoadingLocation 44892E for each ShipFromLocation entity 44854E.The Address 44830F is of the type G/CDT 44816 “Address” 44834F, andthere is zero or one 44832F Address 44830F for each ShipFromLocationentity 44854E.

The LoadingLocation 44892E in the ShipFromLocation entity 44854Eincludes an InternalID 44898E, a StandardID 44806F, a BuyerID 44814F,and a VendorID 44822F at the sixth level 44812. The InternalID 44898E isof the type G/CDT 44816 “LocationInternalID” 44802F, and there is zeroor one 44800F InternalID 44898E for each LoadingLocation 44892E. TheInternalID 44898E has a length 44818 of 1 to 20 44804F. The StandardID44806F is of the type G/CDT 44816 “LocationStandardID” 44810F, and thereis any number 44808F of StandardID 44806F for each LoadingLocation44892E. The StandardID 44806F has a length 44818 of 1 to 13 44812F. TheBuyerID 44814F is of the type G/CDT 44816 “LocationPartyID” 44818F, andthere is zero or one 44816F BuyerID 44814F for each LoadingLocation44892E. The BuyerID 44814F has a length 44818 1 to 20 44820F. TheVendorID 44822F is of the type G/CDT 44816 “LocationPartyID” 44826F, andthere is zero or one 44824F VendorID 44822F for each LoadingLocation44892E. The VendorID 44822F has a length 44818 of 1 to 20 44828F.

The TransshipmentLocation entity 44836F includes an InternalID 44842F, aStandardID 44850F, a BuyerID 44858F, a VendorID 44866F, aLoadingLocation 44874F, an UnloadingLocation 44880F, and an Address44886F at the fifth level 44810. The InternalID 44842F is of the typeG/CDT 44816 “LocationInternalID” 44846F, and there is zero or one 44844FInternalID 44842F for each TransshipmentLocation entity 44836F. TheInternalID 44842F has a length 44818 of 1 to 20 44848F. The StandardID44850F is of the type G/CDT 44816 “LocationStandardID” 44854F, and thereis any number 44852F StandardID 44850F for each TransshipmentLocationentity 44836F. The StandardID 44850F has a length 44818 of 1 to 1344856F. The BuyerID 44858F is of the type G/CDT 44816 “LocationPartyID”44862F, and there is zero or one 44860F BuyerID 44858F for eachTransshipmentLocation entity 44836F. The BuyerID 44858F has a length44818 of 1 to 20 44864F. The VendorID 44866F is of the type G/CDT 44816“LocationPartyID” 44870F, and there is zero or one 44868F VendorID44866F for each TransshipmentLocation entity 44836F. The VendorID 44866Fhas a length 44818 of 1 to 20 44872F. The LoadingLocation 44874F is ofthe type G/CDT 44816 “BusinessTransactionDocumentLocation” 44878F, andthere is zero or one 44876F LoadingLocation 44874F for eachTransshipmentLocation entity 44836F. The UnloadingLocation 44880F is ofthe type G/CDT 44816 “BusinessTransactionDocumentLocation” 44884F, andthere is zero or one 44882F UnloadingLocation 44880F for eachTransshipmentLocation 44836F. The Address 44886F is of the type G/CDT44816 “Address” 44890F, and there is zero or one 44888F Address 44886Ffor each TransshipmentLocation entity 44836F.

The ShipToLocation entity 44892F includes an InternalID 44898F, aStandardID 44806G, a BuyerID 44814G, a VendorID 44822G, anUnloadingLocation 44830G, and an Address 44868G at the fifth level44810. The InternalID 44898F is of the type G/CDT 44816“LocationInternalID” 44802G, and there is zero or one 44800G InternalID44898F for each ShipToLocation entity 44892F. The InternalID 44898F hasa length 44818 of 1 to 20 44804G. The StandardID 44806G is of the typeG/CDT 44816 “LocationStandardID” 44810G, and there is any number 44808GStandardID 44806G for each ShipToLocation entity 44892F. The StandardID44806G has a length 44818 of 1 to 13 44812G. The BuyerID 44814G is ofthe type G/CDT 44816 “LocationPartyID” 44818G, and there is zero or one44816G BuyerID 44814G for each ShipToLocation entity 44892F. The BuyerID44814G has a length 44818 of 1 to 20 44820G. The VendorID 44822G is ofthe type G/CDT 44816 “LocationPartyID” 44826G, and there is zero or one44824G VendorID 44822G for each ShipToLocation entity 44892G. TheVendorID 44822G has a length 44818 of 1 to 20 44828G. TheUnloadingLocation 44830G is of the type G/CDT 44816“BusinessTransactionDocumentLocation” 44834G, and there is zero or one44832G UnloadingLocation 44830G for each ShipToLocation entity 44892G.The Address 44868G is of the type G/CDT 44816 “Address” 44872G, andthere is zero or one 44870G Address 44868G for each ShipToLocationentity 44892F.

The UnloadingLocation 44830G in the ShipToLocation entity 44892Fincludes an InternalID 44836G, a StandardID 44844G, a BuyerID 44852G,and a VendorID 44860G at the sixth level 44812. The InternalID 44836G isof the type G/CDT 44816 “LocationInternalID” 44840G, and there is zeroor one 44838G InternalID 44836G for each UnloadingLocation 44830G. TheInternalID 44836G has a length 44818 of 1 to 20 44842G. The StandardID44844G is of the type G/CDT 44816 “LocationStandardID” 44848G, and thereis any number 44846G of StandardID 44844G for each UnloadingLocation44830G. The StandardID 44844G has a length 44818 of 1 to 13 44850G. TheBuyerID 44852G is of the type G/CDT 44816 “LocationPartyID” 44856G, andthere is zero or one 44854G BuyerID 44852G for each UnloadingLocation44830G. The BuyerID 44852G has a length 44818 of 1 to 20 44858G. TheVendorID 44860G is of the type G/CDT 44816 “LocationPartyID” 44864G, andthere is zero or one 44862G VendorID 44860G for each UnloadingLocation44830G. The VendorID 44860G has a length 44818 of 1 to 20 44866G.

The ProductInformation package 44824D includes a Product entity 44874Gat the fourth level 44808. The Product entity 44874G is of the typeG/CDT 44816 “BusinessTransactionDocumentProduct” 44878G, and there isone 44876G Product entity 44874G for each ProductInformation package44824D.

The Product entity 44874G includes an InternalID 44880G, a StandardID44888G, a BuyerID 44896G, a VendorID 44804H, a ChangeID 44812H, and aPackageQuantity 44820H at the fifth level 44810. The InternalID 44880Gis of the type G/CDT 44816 “LocationInternalID” 44884G, and there iszero or one 44882G InternalID 44880G for each Product entity 44874G. TheInternalID 44880G has a length 44818 of 1 to 40 44886G. The StandardID44888G is of the type G/CDT 44816 “LocationStandardID” 44892G, and thereis zero or one 44890G StandardID 44888G for each Product entity 44874G.The StandardID 44888G has a length 44818 of 1 to 14 44894G. The BuyerID44896G is of the type G/CDT 44816 “LocationPartyID” 44800H, and there iszero or one 44898G BuyerID 44896G for each Product entity 44874G. TheBuyerID 44896G has a length 44818 of 1 to 40 44802H. The VendorID 44804His of the type G/CDT 44816 “LocationPartyID” 44808H, and there is zeroor one 44806H VendorID 44804H for each Product entity 44874G. TheVendorID 44804H has a length 44818 of 1 to 40 4481 OH. The ChangeID44812H is of the type G/CDT 44816 “ProductChangeID” 44816H, and there iszero or one 44814H ChangeID 44812H for each Product entity 44874G. TheChangeID 44812H has a length 44818 of 1 to 25 44818H. ThePackageQuantity 44820H is of the type G/CDT 44816 “Quantity” 44824H, andthere is zero or one 44822H PackageQuantity 44820H for each Productentity 44874G. The PackageQuantity 44820H has a length 44818 of 19 or 644826H.

The Batch package 44826D includes zero or one 44830H Batch entity 44828Hat the fourth level 44808. The Batch entity 44828H includes anInternalID 44832H, a BuyerID 44840H, a VendorID 44848H, aManufacturingDate 44856H, a BestBeforeDate 44862H, and anOriginCountryCode 44868H at the fifth level 44810. The InternalID 44832His of the type G/CDT 44816 “BatchInternalID” 44836H, and there is zeroor one 44834H InternalID 44832H for each Batch entity 44828H. TheInternalID 44832H has a length 44818 of 1 to 10 44838H. The BuyerID44840H is of the type G/CDT 44816 “BatchPartyID” 44844H, and there iszero or one 44842H BuyerID 44840H for each Batch entity 44828H. TheBuyerID 44840H has a length 44818 of 1 to 10 44846H. The VendorID 44848His of the type G/CDT 44816 “BatchPartyID” 44852H, and there is zero orone 44850H VendorID 44848H for each Batch entity 44828H. The VendorID44848H has a length 44818 of 1 to 10 44854H. The ManufacturingDate44856H is of the type G/CDT 44816 “Date” 44860H, and there is zero orone 44858H ManufacturingDate 44856H for each Batch entity 44828H. TheBestBeforeDate 44862H is of the type G/CDT 44816 “Date” 44866H, andthere is zero or one 44864H BestBeforeDate 44862H for each Batch entity44828H. The OriginCountryCode 44868H is of the type G/CDT 44816“CountryCode” 44872H, and there is zero or one 44870H OriginCountryCode44868H for each Batch entity 44828H. The OriginCountryCode 44868H has alength 44818 of three 44874H.

The Promotion package 44828D includes a Promotion entity 44876H at thefourth level 44808. The Promotion entity 44876H is of the type G/CDT44816 “Promotion” 44880H, and there is zero or one 44878H Promotionentity 44876H for each Promotion package 44828D. The Promotion entity44876H has a length 44818 of 1 to 35 44882H. The Promotion entity 44876Hincludes an InternalID 44884H, a BuyerID 44892H, and a VendorID 44800Iat the fifth level 44810. The InternalID 44884H is of the type G/CDT44816 “PromotionInternalID” 44888H, and there is zero or one 44886HInternalID 44884H for each Promotion entity 44876H. The InternalID44884H has a length 44818 of 1 to 20 44890H. The BuyerID 44892H is ofthe type G/CDT 44816 “PromotionPartyID” 44896H, and there is zero or one44894H BuyerID 44892H for each Promotion entity 44876H. The BuyerID44892H has a length 44818 of 1 to 20 44898H. The VendorID 44800I is ofthe type G/CDT 44816 “PromotionPartyID” 44804I, and there is zero or one44802I VendorID 44800I for each Promotion entity 44876H. The VendorID44800I has a length 44818 of 1 to 20 44806I.

The NetWeightMeasure 44808I at the fourth level 44808 in the Itempackage 44814A is of a type 44816 “Measure” 44812I, and there is zero orone 44810I NetWeightMeasure 44808I for each Item package 44814A. TheNetWeightMeasure 44808I has a length 44818 of 19 or 6 44814I.

DeliveryInformation package 44830D in the Item package 44814A includes aDeliveryTerms entity 44816I at the fourth level 44808. DeliveryTermsentity 44816I is of a type G/CDT 44816 “DeliveryTerms” 44820I, and thereis zero or one 44818I DeliveryTerms entity 44816I for eachDeliveryInformation package 44830D.

The DeliveryTerms entity 44816I includes a DeliveryPriorityCode 44822I,an Incoterms 44828I, and a QuantityTolerance 44834I at the fifth level44810. The DeliveryPriorityCode 44822I is of a type G/CDT 44816“BusinessTransactionPriorityCode” 44826I, and there is zero or one44824I DeliveryPriorityCode 44822I for each DeliveryTerms entity 44816I.The Incoterms 44828I is of a type G/CDT 44816 “Incoterms” 44832I, andthere is zero or one 44830I Incoterms 44828I for each DeliveryTermsentity 44816I. The QuantityTolerance 44834I is of a type G/CDT 44816“QuantityTolerance” 44838I, and there is zero or one 44836IQuantityTolerance 44834I for each DeliveryTerms entity 44816I.

The QuantityTolerance 44834I in DeliveryTerms entity 44816I includes anOverPercent 44840I and an UnderPercent 44846I at the sixth level 44812.The OverPercent 44840I is of a type G/CDT 44816 “Percent” 44844I, andthere is zero or one 44842I OverPercent 44840I for each QualityTolerance44834I. The UnderPercent 44846I is of a type G/CDT 44816 “Percent”44850I, and there is zero or one 44848I UnderPercent 44846I for eachQualityTolerance 44834I.

The PriceInformation package 44832D includes a NetPrice entity 44852I atthe fourth level 44808. The NetPrice entity 44852I is of a type G/CDT44816 “Price” 44856I, and there is zero or one 44854I NetPrice entity44852I for each PriceInformation package 44832D.

A KanbanCardID 44874N at the fourth level 44808 in the Item package44814A is of a type 44816 “KanbanCardID” 44878N, and there is zero orone 44876N KanbanCardID 44874N for each Item package 44814A. TheKanbanCardID 44874N has a length 44818 of 1 to 10 44880N.

A FollowUpReplenishmentOrderConfirmationRequirementCode 44890N at thefourth level 44808 in the Item package 44814A is of a type 44816“FollowUpMessageRequirementCode” 44894N, and there is zero or one 44892NFollowUpReplenishmentOrderConfirmationRequirementCode 44890N for eachItem package 44814A.

A FollowUpDispatchedDeliveryNotificationRequirementCode 44896N at thefourth level 44808 in the Item package 44814A is of a type 44816“FollowUpMessageRequirementCode” 44800O, and there is zero or one 44898NFollowUpDispatchedDeliveryNotificationRequirementCode 44896N for eachItem package 44814A.

The Note 44858I at the fourth level 44808 in the Item package 44814A isof a type 44816 “Note” 44862I, and there is zero or one 44860I Note44858I for each Item package 44814A. The Note 44858I has a length 44818of 1 to 132 44864I.

The ScheduleLine package 44834D in the Item package 44814A includes aScheduleLine entity 44866I and a ConfimmedScheduleLine entity 44838J atthe fourth level 44808. The ScheduleLine entity 44866I is of a typeG/CDT 44816 “ReplenishmentOrderItemScheduleLine” 44870I, and there is atleast one 44868I ScheduleLine entity 44866I for each ScheduleLinepackage 44834D. The ConfirmedScheduleLine entity 44838J is of a typeG/CDT 44816 “ReplenishmentOrderItemScheduleLine” 44842J, and there isany number 44840J of ConfirmedScheduleLine entities 44838J for eachScheduleLine package 44834D.

The ScheduleLine entity 44866I includes an @actionCode 44802O, an ID44810O, a ShipmentGroupID 44872I, TransportPlanningPeriod 44880I, aPositioningPeriod 44886I, a LoadingPeriod 44892I, a ShippingPeriod44898I, a DeliveryPeriod 44804J, an AvailabilityPeriod 44810J, aPickupPeriod 44816J, a Quantity 44822J, a ReceivedQuantity 44830J, and aComponentRequirement entity 44831J at the fifth level 4481O. The@actionCode 44802O is of a type G/CDT 44816 “ActionCode” 44806O, andthere is zero or one 44804O @actionCode 44802O for each ScheduleLineentity 44866I. The @actionCode 44802O has a length 44818 of 2 44808O.The ID 44810O is of a type G/CDT 44816 “BusinessTransactionDocumentItemScheduleLineID” 44814O, and there is zero or one 44812O ID44810O for each ScheduleLine entity 44866I. The ID 44810O has a length44818 of 1 to 4 44816O. The ShipmentGroupID 44872I is of a type G/CDT44816 “BusinessTransactionDocumentGroupID” 44876I, and there is zero orone 44874I ShipmentGroupID 44872I for each ScheduleLine entity 44866I.The ShipmentGroupID 44872I has a length 44818 of 1 to 10 44878I. TheTransportPlanningPeriod 44880I is of a type G/CDT 44816 “DateTimePeriod”44884I, and there is zero or one 44882I TransportPlanningPeriod 44880Ifor each ScheduleLine entity 44866I. The PositioningPeriod 44886I is ofa type G/CDT 44816 “DateTimePeriod” 44890I, and there is zero or one44888I PositioningPeriod 44888I for each ScheduleLine entity 44866I. TheLoadingPeriod 44892I is of a type G/CDT 44816 “DateTimePeriod” 44896I,and there is zero or one 44894I LoadingPeriod 44892I for eachScheduleLine entity 44866I. The ShippingPeriod 44898I is of a type G/CDT44816 “DateTimePeriod” 44802J, and there is zero or one 44800JShippingPeriod 44898I for each ScheduleLine entity 44866I. TheDeliveryPeriod 44804J is of a type G/CDT 44816 “DateTimePeriod” 44808J,and there is zero or one 44806J DeliveryPeriod 44804J for eachScheduleLine entity 44866I. The AvailabilityPeriod 44810J is of a typeG/CDT 44816 “DateTimePeriod” 44814J, and there is zero or one 44812JAvailabilityPeriod 44810J for each ScheduleLine entity 44866I. ThePickupPeriod 44816J is of a type G/CDT 44816 “DateTimePeriod” 44820J,and there is zero or one 44818J PickupPeriod 44816J for eachScheduleLine entity 44866I. The Quantity 44822J is of a type G/CDT 44816“Quantity” 44826J, and there is one 44824J Quantity 44822J for eachScheduleLine entity 44866I. The Quantity 44822J has a length 44818 of 19of 6 44828J. The ReceivedQuantity 44830J is of a type G/CDT 44816“Quantity” 44834J, and there is zero or one 44832J ReceivedQuantity44830J for each ScheduleLine entity 44866I. The ReceivedQuantity 44830Jhas a length 44818 of 19 or 6 44836J. The ComponentRequirement entity44831J is of a type G/CDT 44816“ReplenishmentOrderItemScheduleLineComponentRequirement” 44835J, andthere is zero to n 44833J ComponentRequirement entity 44831J for eachScheduleLine entity 44866I.

The ComponentRequirement entity 44831J includes a Product entity 44810Oand a Quantity 44846O. The Product entity 44810O in theComponentRequirement entity 44831J includes an InternalID 44816O, aStandardID 44824O, a BuyerID 44832O, and a VendorID 44838O at the sixthlevel 44812. The InternalID 44816O is of the type G/CDT 44816“ProductInternalID” 44820O, and there is zero or one 44818O InternalID44816O for each ComponentRequirement entity 44831J. The InternalID44816O has a length 44818 of 1 to 20 44818O. The StandardID 44824O is ofthe type G/CDT 44816 “ProductStandardID” 44828O, and there is zero orone 44826O of StandardID 44824O for each ComponentRequirement entity44831J. The StandardID 44824O has a length 44818 of 14 44830O. TheBuyerID 44832O is of the type G/CDT 44816 “ProductBuyerID” 44834O, andthere is zero or one 44832O BuyerID 44832O for each ComponentRequiremententity 44831J. The BuyerID 44832O has a length 44818 1 to 40 44836O. TheVendorID 44838O is of the type G/CDT 44816 “ProductVendorID” 44842O, andthere is zero or one 44840O VendorID 44838O for eachComponentRequirement entity 44831J. The VendorID 44838O has a length44818 of 1 to 40 44852O. The Quantity 44846O is of the type G/CDT 44816“Quantity” 44842O, and there is one 44848O Quantity 44846O for eachComponentRequirement entity 44831J. The Quantity 44846O has a length44818 of 19 or 6 44852O.

The ConfirmedScheduleLine entity 44838J includes a @actionCode 44839J, aShipmentGroupID 44844J, TransportPlanningPeriod 44852J, aPositioningPeriod 44858J, a LoadingPeriod 44864J, a ShippingPeriod44870J, a DeliveryPeriod 44876J, an AvailabilityPeriod 44882J, aPickupPeriod 44888J, a Quantity 44894J and a ComponentRequirement entity44895J at the fifth level 44810. The @actionCode 44839J is of a typeG/CDT 44816 “ActionCode” 44843J, and there is zero or one 44841J@actionCode 44839J for each ConfirmedScheduleLine entity 44838J. The@actionCode 44839J has a length 44818 of 2 44845J. The ShipmentGroupID44844J is of a type G/CDT 44816 “BusinessTransactionDocumentGroupID”44848J, and there is zero or one 44846J ShipmentGroupID 44844J for eachConfirmedScheduleLine entity 44838J. The ShipmentGroupID 44844J has alength 44818 of 1 to 10 44850J. The TransportPlanningPeriod 44852J is ofa type G/CDT 44816 “DateTimePeriod” 44856J, and there is zero or one44854J TransportPlanningPeriod 44852J for each ConfirmedScheduleLineentity 44838J. The PositioningPeriod 44858J is of a type G/CDT 44816“DateTimePeriod” 44862J, and there is zero or one 44860JPositioningPeriod 44858J for each ConfirmedScheduleLine entity 44838J.The LoadingPeriod 44864J is of a type G/CDT 44816 “DateTimePeriod”44868J, and there is zero or one 44866J LoadingPeriod 44864J for eachConfirmedScheduleLine entity 44838J. The ShippingPeriod 44870J is of atype G/CDT 44816 “DateTimePeriod” 44874J, and there is zero or one44872J ShippingPeriod 44870J for each ConfirmedScheduleLine entity44838J. The DeliveryPeriod 44876J is of a type G/CDT 44816“DateTimePeriod” 44880J, and there is zero or one 44878J DeliveryPeriod44876J for each ConfirmedScheduleLine entity 44838J. TheAvailabilityPeriod 44882J is of a type G/CDT 44816 “DateTimePeriod”44886J, and there is zero or one 44884J AvailabilityPeriod 44882J foreach ConfirmedScheduleLine entity 44838J. The PickupPeriod 44888J is ofa type G/CDT 44816 “DateTimePeriod” 44892J, and there is zero or one44890J PickupPeriod 44888J for each ConfirmedScheduleLine entity 44838J.The Quantity 44894J is of a type G/CDT 44816 “Quantity” 44898J, andthere is one 44896J Quantity 44894J for each ConfirmedScheduleLineentity 44838J. The Quantity 44894J has a length 44818 of 19 or 6 44800K.The ComponentRequirement entity 44895J is of a type G/CDT 44816“ReplenishmentOrderItemConfirmedScheduleLineComponentRequirement”44899J, and there is zero to n 44897J ComponentRequirement entity 44895Jfor each ScheduleLine entity 44866I.

The ComponentRequirement entity 44895J includes a Product entity 44854Oand a Quantity 44892O. The Product entity 44854O in theComponentRequirement entity 44895J includes an InternalID 44860O, aStandardID 44868O, a BuyerID 44876O, and a VendorID 44884O at the sixthlevel 44812. The InternalID 44860O is of the type G/CDT 44816“ProductInternalID” 44864O, and there is zero or one 44862O InternaiID44860O for each ComponentRequirement entity 44895J. The InternalID44860O has a length 44818 of 1 to 20 44866O. The StandardID 44868O is ofthe type G/CDT 44816 “ProductStandardID” 44872O, and there is zero orone 44870O of StandardID 44868O for each ComponentRequirement entity44895J. The StandardID 44868O has a length 44818 of 14 44874O. TheBuyerID 44876O is of the type G/CDT 44816 “ProductBuyerID” 44880O, andthere is zero or one 44878O BuyerID 44876O for each ComponentRequiremententity 44895J. The BuyerID 44876O has a length 44818 1 to 40 44882O. TheVendorID 44884O is of the type G/CDT 44816 “ProductVendorID” 44888O, andthere is zero or one 44886O VendorID 44884O for eachComponentRequirement entity 44895J. The VendorID 44884O has a length44818 of 1 to 40 44890O. The Quantity 44892O is of the type G/CDT 44816“Quantity” 44896O, and there is one 44894O Quantity 44892O for eachComponentRequirement entity 44895J. The Quantity 44892O has a length44818 of 19 or 6 44898O.

The HandlingUnit package 44815A of the ReplenishmentOrderMessage package44830 includes a HandlingUnit entity 44802K at the third level 44806.The HandlingUnit entity 44802K is of a type G/CDT 44816 “HandlingUnit”44806K, and there is any number 44804K of HandlingUnit entities 44802Kfor a HandlingUnit package 44815A.

The HandlingUnit entity 44802K includes an ID 44808K, a LoadCarrier44816K, a HeightMeasure 44856K, a LengthMeasure 44864K, a WidthMeasure44872K, a GrossVolumeMeasure 44880K, a NetVolumeMeasure 44888K,GrossWeightMeasure 44896K, a NetWeightMeasure 44804L, anAdditionalPackaging 44812L, a LowerLevelHandlingUnit 44860L, and a Load44872L at the fourth level 44808. The ID 44808K is of a type G/CDT 44816“HandlingUnitID” 44812K, and there is one 44810K ID 44808K for eachHandlingUnit entity 44802K. The ID 44808K has a length 44818 of 1 to 2044814K. There is one 44818K LoadCarrier 44816K for each HandlingUnitentity 44802K. The HeightMeasure 44856K is of a type G/CDT 44816“Measure” 44860K, and there is zero or one 44858K HeightMeasure 44856Kfor each HandlingUnit entity 44802K. The HeightMeasure 44856K has alength 44818 of 19 or 6 44862K. The LengthMeasure 44864K is of a typeG/CDT 44816 “Measure” 44868K, and there is zero or one 44866KLengthMeasure 44864K for each HandlingUnit entity 44802K. TheLengthMeasure 44864K has a length 44818 of 19 or 6 44870K. TheWidthMeasure 44872K is of a type G/CDT 44816 “Measure” 44876K, and thereis zero or one 44874K WidthMeasure 44872K for each HandlingUnit entity44802K. The WidthMeasure 44872K has a length 44818 of 19 or 6 44878K.The GrossVolumeMeasure 44880K is of a type G/CDT 44816 “Measure” 44884K,and there is zero or one 44882K GrossVolumeMeasure 44880K for eachHandlingUnit entity 44802K. The GrossVolumeMeasure 44880K has a lengthof 44818 of 19 or 6 44886K. The NetVolumeMeasure 44888K is of a typeG/CDT 44816 “Measure” 44892K, and there is zero or one 44890KNetVolumeMeasure 44888K for each HandlingUnit entity 44802K. TheNetVolumeMeasure 44888K has a length 44818 of 19 or 6 44894K. TheGrossWeightMeasure 44896K is of a type G/CDT 44816 “Measure” 44800L, andthere is zero or one 44898K GrossWeightMeasure 44896K for eachHandlingUnit entity 44802K. The GrossWeightMeasure 44896K has a length44818 of 19 or 6 44802L. The NetWeightMeasure 44804L is of a type G/CDT44816 “Measure” 44808L, and there is zero or one 44806L NetWeightMeasure44804L for each HandlingUnit entity 44802K. The NetWeightMeasure 44804Lhas a length 44818 of 19 or 6 44810L. There is any number 44814L ofAdditionalPackaging 44812L for each HandlingUnit entity 44802K. There isany number 44862L of LowerLevelHandlingUnit 44860L for each HandlingUnit44802K. There is any number 44874L of Load 44872L for each HandlingUnitentity 44802K.

The LoadCarrier 44816K in the HandlingUnit entity 44802K includes one44822K Product 44820K at the fifth level 44810. The Product 44820Kincludes an InternalID 44824K, a StandardID 44832K, a BuyerID 44840K,and a VendorID 44848K at the sixth level 44812. The InternalID 44824K isof the type G/CDT 44816 “ProductInternalID” 44828K, and there is zero orone 44826K InternalID 44824K for each Product 44820K. The InternalID44824K has a length 44818 of 1 to 40 44830K. The StandardID 44832K is ofthe type G/CDT 44816 “ProductStandardID” 44836K, and there is zero orone 44834K StandardID 44832K for each Product 44820K. The StandardID44832K has a length 44818 of 1 to 14 44838K. The BuyerID 44840K is ofthe type G/CDT 44816 “ProductPartyID” 44844K, and there is zero or one44842K BuyerID 44840K for each Product 44820K. The BuyerID 44840K has alength 44818 of 1 to 40 44846K. The VendorID 44848K is of the type G/CDT44816 “ProductPartyID” 44852K, and there is zero or one 44850K VendorID44848K for each Product 44820K. The VendorID 44848K has a length 44818of 1 to 40 44854K.

The AdditionalPackaging 44812L in the HandlingUnit entity 44802Kincludes one 44818L Product 44816L and one 44854L Quantity 44852L at thefifth level 44810. The Quantity 44852L is of the type G/CDT 44816“Quantity” 44856L. The Quantity 44852L has a length 44818 of 19 or 644858L.

The Product 44816L in the AdditionalPackaging 44812L includes anInternalID 44820L, a StandardID 44828L, a BuyerID 44836L, and a VendorID44844L at the sixth level 44812. The InternalID 44820L is of the typeG/CDT 44816 “ProductInternalID” 44824L, and there is zero or one 44822LInternalID 44820L for each Product 44816L. The InternalID 44820L has alength 44818 of 1 to 40 44826L. The StandardID 44828L is of the typeG/CDT 44816 “ProductStandardID” 44832L, and there is zero or one 44830LStandardID 44828L for each Product 44816L. The StandardID 44828L has alength 44818 of 1 to 14 44834L. The BuyerID 44836L is of the type G/CDT44816 “ProductPartyID” 44840L, and there is zero or one 44838L BuyerID44836L for each Product 44816L. The BuyerID 44836L has a length 44818 of1 to 40 44842L. The VendorID 44844L is of the type G/CDT 44816“ProductPartyID” 44848L, and there is zero or one 44846L VendorID 44844Lfor each Product 44816L. The VendorID 44844L has a length 44818 of 1 to40 44850L.

The LowerHandlingUnit44860L in the HandlingUnit entity 44802K includesan ID 44864L. The ID 44864L is of a type G/CDT 44816 “HandlingUnitID”44868L, and there is one 44866L ID 44864L for each LowerHandlingUnit44860L. The ID 44864L has a length 44818 of 1 to 20 44870L.

The Load 44872L in the HandlingUnit entity 44802K includes aBusinessTransactionDocumentReference 44876L and a Quantity 44886L at thefifth level 44810. The Quantity 44886L is of a type G/CDT 44816“Quantity” 44890L, and there is one 44888L Quantity 44886L for each Load44872L. The Quantity 44886L has a length 44818 of 19 or 6 44892L.

cc) The BusinessTransactionDocumentReference 44876L includes an ItemID44878L at the sixth level 44812. The ItemID 44878L is of a type G/CDT44816 “BusinessTransactionDocumentItemID” 44882L, and there is one44880L ItemID 44878L for each BusinessTransactionDocumentReference44876L. The ItemID 44878L has a length 44818 of 1 to 10 44884L.VendorGenerated Order Interfaces

The VendorGeneratedOrderNotification is sent by a vendor to his customer(acting as a buyer). The vendor uses the message to inform his customerof a replenishment order he has planned and initiated. Thisreplenishment order is intended to trigger the creation of a purchaseorder on the customer side. Contrary to the standard ordering process,this message is triggered by the vendor rather than the customer. Themessage is specially designed for business scenarios in which companiesdelegate planning for replenishment deliveries and the creation of theassociated orders to their vendors, as is the case with Vendor ManagedInventory (VMI) and Responsive Replenishment. TheVendorGeneratedOrderConfirmation is sent by a customer (acting as abuyer) to his vendor. The buyer uses this message either to confirm orreject the replenishment order planned by the vendor. When thisconfirmation is received by the vendor, it executes the replenishmentdelivery.

The VendorGeneratedOrderNotification andVendorGeneratedOrderConfirmation messages are exchanged between theInventory Collaboration Hub (ICH) of a vendor and the execution systemof a sold-to party as part of the “Responsive Replenishment (RR)”business scenario. In this scenario, the ICH performs the “planning”function, while the customer's/buyer's backend system performs the“purchasing” function.

(1) Message Types

(a) Vendor Generated Order Notification

The VendorGeneratedOrderNotification is a message that is used by avendor/seller to transfer the a replenishment order that he hasinitiated and planned to a customer/buyer so that the latter can createa purchase order. The notification sent by the vendor/seller to thecustomer/buyer regarding the planned replenishment order can be regardedas a “purchase order generated by the seller.” The structure of themessage type VendorGeneratedOrderNotification is specified by themessage data type VendorGeneratedOrderNotificationMessage. Thenotification transfer is always complete (“complete transmission”).

(b) Vendor Generated Order Confirmation

VendorGeneratedOrderConfirmation is the confirmation from acustomer/buyer that a purchase order has been created for thereplenishment order initiated and planned by his vendor/seller. Thisconfirmation from the customer/buyer for a “purchase order generated bythe seller” can be regarded as a “purchase order” in the traditionalsense, which, in turn, triggers the corresponding fulfillment process atthe vendor/seller. The structure of the message typeVendorGeneratedOrderConfirmation is specified by the message data typeVendorGeneratedOrderConfirmationMessage. The notification transfer isalways complete (“complete transmission”). Methods and systemsconsistent with the subject matter described herein use the packagetemplate for a BusinessTransactionDocument for an SCM Master Datadepicted in FIG. 270B to derive the VendorGeneratedOrder interfaces.

(2) Message Choreography

The following message choreography describes the possible logicalsequence of the messages that can be used to realize the scenariobetween a Buyer 44900, a Vendor's Supply Chain Planning system 44902,and a Vendor's Supply Chain Execution system 44904, wherein the Buyer44900 and Vendor are two separate entities 44916.

The Buyer 44900 can use the OrderIDAssignmentNotification message 44906to transfer valid purchase order numbers to a vendor's “Supply ChainPlanning” system 44902 for creating replenishment orders. Thesereplenishment orders are transferred from the Vendor's Supply ChainPlanning system 44902 to his Supply Chain Execution system 44904 usingthe ReplenishmentOrderNotification message 44908. The Supply ChainExecution system 44904 checks the availability of the required productsand uses the ReplenishmentOrderConfirmation message 44910 to confirmthat the replenishment orders have been fulfilled. The Buyer 44900 isthen informed of this with the VendorGeneratedOrderNotification message44912. The Buyer 44900 can then send an optional order confirmation tothe Vendor using the VendorGeneratedOrderConfirmation message 44914. Ifthe two business partners collaborate very closely, this orderconfirmation might not be necessary. In this case, theVendorGeneratedOrderNotification 44912 creates a purchase order directlyon the buyer side.

(3) Data Model of Vendor Generated Order Message

FIG. 450 depicts the data model for the VendorGeneratedOrderMessage. TheVendorGeneratedOrderMessage package 45000 message data type groupstogether the business information that is relevant for sending abusiness document in a message and the VendorGeneratedOrder object inthe business document. The VendorGeneratedOrderMessage package 45000includes a VendorGeneratedOrderMessage entity 45002, a MessageHeaderpackage 45004, and a VendorGeneratedOrder package 45006.

The VendorGeneratedOrderMessage message data type makes the masterstructure available for the message data typesVendorGeneratedOrderNotificationMessage 45012 andVendorGeneratedOrderConfirmationMessage 45014, as well as for therelevant message types and message interfaces.

(a) Message Header Package

A MessageHeader package 45004 groups together the business informationthat is relevant for sending a business document in a message. Itincludes a MessageHeader entity 45008.

(i) Message Header entity

A MessageHeader package 45004 groups business information from theperspective of the sending application to identify the business documentin a message, to provide information about the sender, and to provideany information about the recipient.

The MessageHeader entity 45008 is divided into a SenderParty entity45010 and a RecipientParty entity 45012. It is of type GDT:BusinessDocumentMessageHeader. There is a 1:1 relationship 45009 betweenMessageHeader entity 45008 and VendorGeneratedOrderMessage entity 45002.The MessageHeader 45008 includes an ID entity and a CreationDateTimeentity. The ID entity identifies the business document in the technicalmessage, and the CreationDateTime entity is the creation date of abusiness document in the technical message.

(ii) Sender Party Entity

A SenderParty entity 45010 is the party responsible for sending abusiness document at business application level. The SenderParty entity45010 is of type GDT: BusinessDocumentMessageHeaderParty. There is a 1:crelationship 45011 between SenderParty entity 45010 and MessageHeaderentity 45008.

(iii) Recipient Party Entity

A RecipientParty entity 45012 is the party responsible for receiving abusiness document at business application level. The RecipientPartyentity 45012 is of type GDT: BusinessDocumentMessageHeaderParty. Thereis a 1:c relationship 45013 between RecipientParty entity 45012 andMessageHeader entity 45008.

(b) Vendor Generated Order Package

The VendorGeneratedOrder package 45006 groups together theVendorGeneratedOrder entity 45014, a Party package 45016, aVendorGeneratedOrderItem package 45018, and a HandlingUnit package45020.

The HandlingUnit package 45020 and its contents are not required in theVendorGeneratedOrderConfimmationMessage 45014.

(i) Vendor Generated Order Entity

VendorGeneratedOrder entity 45014 is a purchase order that is plannedand initiated by a vendor for his customer and is intended to trigger areplenishment delivery for the customer. The dates and quantities fordelivering or picking up a certain product and (if necessary) how theyare packed in handling units are described in the items and schedulelines of the VendorGeneratedOrder entity 45014. The business partnersinvolved and (where applicable) references to other relevant documentsare also listed.

There is a 1:1 relationship 45015 between VendorGeneratedOrder entity45014 and VendorGeneratedOrderMessage entity 45002. VendorGeneratedOrderentity 45014 includes an ID, a CreationDateTime, a LastChangeDateTime, aTransportMeansDescriptionCode, a GrossWeightMeasure, a NetWeightMeasure,a GrossVolumeMeasure, and a Note. The ID is a unique identifier for thedelivery VendorGeneratedOrder, and is of type GDT:BusinessTransactionDocumentID. The CreationDateTime is the creation timeof the VendorGeneratedOrder entity 45014 at the vendor, and is of typeGDT: DateTime. The LastChangeDateTime is the last change date ofVendorGeneratedOrder entity 45014 by the vendor, and is of type GDT. TheTransportMeansDescriptionCode is the code for the type of transportmeans to be used for the resulting replenishment delivery, and is oftype GDT: TransportMeansDescriptionCode. The GrossWeightMeasure is theestimated gross weight of the resulting replenishment delivery, and isof type GDT: Measure. The NetWeightMeasure is the estimated net weightof the resulting replenishment delivery, and is of type GDT: Measure.The GrossVolumeMeasure is the estimated gross volume of the resultingreplenishment delivery, and is of type GDT: Measure. The Note is theNote on the order, For example, instructions for processing the order.The Note is of type GDT: Note.

(ii) Party Package

The Party package 45016 groups the business partners that are relevantfor the ordering process. It includes a BuyerParty entity 45022 and aVendorParty entity 45024.

For internal communication (with common master data), use the InternalIDentity for all party entities. For interenterprise communication (withbusiness-partner-specific master data), use for all party entitieseither the StandardID entity or the partner-role-specific ID entity ofthe receiving partner, in other words, for Supplier Collaborationscenarios use the BuyerID entity, and for Customer Collaborationscenarios, use the VendorID entity. Due to the different possibilitiesfor ID use, all ID entity elements of the particular “Party” areoptional.

(a) Buyer Party Entity

BuyerParty entity 45022 is the purchasing company that is to receive areplenishment delivery. BuyerParty entity 45022 is of type GDT:BusinessTransactionDocumentParty, where the InternalID, the StandardID,the BuyerID, and the VendorID are used. There is a 1:1 relationship45023 between BuyerParty entity 45022 and VendorGeneratedOrder entity45014.

(b) Vendor Party Entity

VendorParty entity 45024 is the company that is to provide areplenishment delivery. VendorParty entity 45024 is of type GDT:BusinessTransactionDocumentParty, where the InternalID, the StandardID,the BuyerID, and the VendorID are used. There is a 1:1 relationship45025 between VendorParty entity 45024 and VendorGeneratedOrder entity45014.

(iii) Vendor Generated Order Item Package

The VendorGeneratedOrder package 45006 groups theVendorGeneratedOrderItem entity 45026 and aBusinessTransactionDocumentReference package 45028, a Location package45030, a Product package 45032, a Promotion package 45034, and aVendorGeneratedOrderItemScheduleLine package 45036.

(a) Vendor Generated Order Item Entity

VendorGeneratedOrderItem entity 45026 describes when and where certainquantities of a product that is listed in a VendorGeneratedOrder entity45014 will be delivered or can be picked up. In addition to detailsregarding the products to be delivered and locations,VendorGeneratedOrderItem can contain references to other relevantbusiness documents.

VendorGeneratedOrderItem entity 45026 includes an ID, anAcceptanceStatusCode, a ConsignmentIndicator, a NetWeightMeasure, and aNote. The ID identifies the item in the VendorGeneratedOrder 45014, andis of type GDT: BusinessTransactionDocumentItemID. There is a 1:nrelationship 45027 between VendorGeneratedOrderItem entity 45026 andVendorGeneratedOrder entity 45014. The AcceptanceStatusCode is theacceptance status for executing the replenishment order item, and is oftype GDT: AcceptanceStatusCode. The ConsignmentIndicator indicateswhether the item belongs to the consignment stock, and is of type GDT:ConsignmentIndicator. The NetWeightMeasure is the net weight of theproducts in the item within the VendorGeneratedOrder entity 45014, andis of type GDT: Measure. The Note is the Note on the item in theVendorGeneratedOrder. For example, the Note includes instructions forprocessing an item. The Note is of type GDT: Note. TheAcceptanceStatusCode is not required in theVendorGeneratedOrderNotificationMessage.

(b) Business Transaction Document Reference package

The BusinessTransactionDocumentReference package 45028 is a group ofreferences to other business documents that can occur in thereplenishment order process. It includes a PurchasingContractReference45058 and a SalesOrderReference entity 45038.

A PurchasingContractReference 45058 is a reference to a purchasecontract or item in a purchase contract. The PurchasingContractReference45058 is of type GDT: BusinessTransactionDocumentReference.

SalesOrderReference entity 45038 is the reference to the sales order orsales order item created for the ReplenishmentOrder in the vendor'sLogistics Execution system. SalesOrderReference entity 45038 is of typeGDT: BusinessTransactionDocumentReference. There is a 1:c relationship45039 between SalesOrderReference entity 45038 andVendorGeneratedOrderItem entity 45026. SalesOrderReference entity 45038is used to extend the buyer's purchase order to include the vendor'sexternal document ID. It is required in particular if the purchase ordernumbers in the buyer's Logistics Execution system are not assigned untilthe VendorGeneratedOrderNotification 45012 is received (as opposed toduring the earlier replenishment planning stage at the vendor using thepurchase order numbers allocated by the buyer). In this case, the salesorder reference also is returned to the vendor in theVendorGeneratedOrderConfirmation message 45014.

(c) Location Package

The Location Package 45030 groups the locations that may be relevantwithin the replenishment order process. It includes a ShipFromLocationentity 45040, a TransshipmentLocation entity 45042, and a ShipToLocationentity 45044.

For internal communication (with common master data), use the InternalIDfor all location entities. For interenterprise communication (withbusiness-partner-specific master data), use for all location entitieseither the StandardID or the partner-role-specific ID entity of thesending or receiving partner, in other words, the BuyerID entity orVendorID entity. Due to the different possibilities for ID entity use,all ID elements of the particular “location” are optional.

(i) Ship From Location Entity

ShipFromLocation entity 45040 is the location to which the quantity of aproduct listed in the item for a VendorGeneratedOrder is to bedelivered. ShipFromLocation entity 45040 is of type GDT:BusinessTransactionDocumentShipFromLocation, where the InternalID,StandardID, BuyerID, VendorID, and LoadingLocation are used. There is a1:1 relationship 45041 between ShipFromLocation entity 45040 andVendorGeneratedOrderItem entity 45026.

(ii) Transshipment Location Entity

TransshipmentLocation entity 45042 is the location at which the quantityof a product listed in the item for a VendorGeneratedOrder is to beloaded from one vehicle to another while being delivered to therecipient. TransshipmentLocation entity 45042 is of type GDT:BusinessTransactionDocumentTransshipmentLocation, where the InternalID,StandardID, BuyerID, VendorID, Address, LoadingLocation, andUnloadingLocation are used. There is a 1:c relationship 45043 betweenTransshipmentLocation entity 45042 and VendorGeneratedOrderItem entity45026.

(iii) Ship To Location Entity

ShipToLocation entity 45044 is the location from which the quantity of aproduct listed in the item for a VendorGeneratedOrder is to bedelivered. ShipToLocation entity 45044 is of type GDT:BusinessTransactionDocumentShipToLocation, where the InternalID,StandardID, BuyerID, VendorID, and UnloadingLocation are used. There isa 1:1 relationship 45045 between ShipToLocation entity 45044 andVendorGeneratedOrderItem entity 45026.

(d) Product Information Package

The ProductInformation package 45032 groups the information thatcharacterizes the product listed in the item of a VendorGeneratedOrderentity 45014 in greater detail. It includes a Product entity 45046.

Product entity 45046 includes the information for identifying adelivered product and the package quantity used. Product entity 45046 isof type GDT: BusinessTransactionDocumentProduct, where the InternalID,StandardID, BuyerID, VendorID, and PackageQuantity are used. There is a1:1 relationship 45047 between Product entity 45046 andVendorGeneratedOrderItem entity 45026. For internal communication, usethe InternalID for all product entities. For interenterprisecommunication, use for all product entities either the StandardID or thepartner-role-specific ID entity of the sending or receiving partner, inother words, the BuyerID or VendorID. Due to the different possibilitiesfor ID entity use, all ID elements of the particular ‘product’ areoptional.

(e) Promotion Package

The Promotion package 45034 groups all the data regarding marketingpromotions that are relevant for the product listed in aVendorGeneratedOrder item 45014. It includes a Promotion entity 45048.

Promotion entity 45048 includes data that identifies a marketingpromotion that is planned by the buyer for the product to be delivered.Promotion entity 45048 includes an InternalID, a BuyerID, and aVendorID. The InternalID identifies the marketing promotion (forcommunication within the company), and is of type GDT:PromotionInternalID. There is a 1:c relationship 45049 between Promotionentity 45048 and VendorGeneratedOrderItem entity 45026. The BuyerIDidentifies the marketing promotion (used by BuyerParty), and is of typeGDT: PromotionPartyID. The VendorID identifies the marketing promotion(used by VendorParty), and is of type GDT: PromotionPartyID.

This additional information is required to distinguish between “standardpurchase orders” and “special purchase orders” as part of the marketingactivities between the consumer goods and retail industries (forexample, to boost awareness of a product).

(f) Vendor Generated Order Item Schedule Line Package

The VendorGeneratedOrderItemScheduleLine package 45036 groups all of thequantity and date information for a VendorGeneratedOrderItem 45026. Itincludes a ScheduleLine entity 45050 and a ConfirmedScheduleLine entity45052.

(i) Schedule Line Entity

ScheduleLine entity 45050 is a schedule line containing a quantity andscheduling dates planned by the vendor for his customer forreplenishment deliveries of a product. The ScheduleLine entity 45050includes a ShipmentGroupID, a DeliveryPeriod, a PickupPeriod, and aQuantity. There is a 1:n relationship 45051 between ScheduleLine entity45050 and VendorGeneratedOrderItem entity 45026. The ShipmentGroupIDentity identifies a group of replenishment order items that are combinedfor a shipment document, and is of type GDT:BusinessTransactionDocumentGroupID. The DeliveryPeriod is the period inwhich the products are expected to be delivered, and is of type GDT:DateTimePeriod. The PickupPeriod is the period in which the products canbe picked up, and is of type GDT: DateTimePeriod. The Quantity is thequantity of a product in a replenishment delivery to be delivered orpicked up, and is of type GDT: Quantity.

(ii) Confirmed Schedule Line Entity

ConfirmedScheduleLine entity 45052 is a schedule line entity containinga quantity and scheduling dates for replenishment deliveries of aproduct. There is a 1:cn relationship 45053 betweenConfirmedScheduleLine entity 45052 and VendorGeneratedOrderItem entity45026. The structure is the same as ScheduleLine entity 45050.

The ConfirmedScheduleLine entity 45052 is not required in theVendorGeneratedOrderNotificationMessage.

The ConfirmedScheduleLine entity 45052 can contain discrepancies withregard to the original schedule line in terms of scheduling periods anddelivery quantities.

(iv) Handling Unit Package

The HandlingUnit package 45020 summarizes information that characterizesin greater detail how the replenishment delivery is packed or to bepacked. It includes a HandlingUnit entity 45054.

The HandlingUnit package 45020 and HandlingUnit entity 45054 are notrequired in the VendorGeneratedOrderConfirmationMessage.

HandlingUnit entity 45054 is a physical unit of packaging materials(load carrier, additional packaging materials) and the packaged products(of type “Material”). HandlingUnit entity 45054 is of type GDT:HandlingUnit. There is a 1:cn relationship 45055 between HandlingUnitentity 45054 and VendorGeneratedOrder entity 45014. The product listedin a VendorGeneratedOrderItem can be distributed among severalHandlingUnits 45054 and a HandlingUnit 45054 can contain products thatare listed in several items. The products included in a HandlingUnit45054 are specified by the “HandlingUnitLoad” element by means of areference to the relevant items in the VendorGeneratedOrder.

(4) Element Structure of Vendor Generated Order Message

The message data type element structure for the VendorGeneratedOrdermessage is depicted in FIG. 451. The element structure is similar to thedata model, but provides additional information regarding the details ofthe interface. The element structure identifies the different packages45100 in the interface, and represents the entities at various levelswithin the interface. As depicted in FIG. 451, the interface forVendorGeneratedOrderMessage includes six levels 45102, 45104, 45106,45108, 45110 and 45112. The outermost package of this interface is aVendorGeneratedOrder package 45124, which includes aVendorGeneratedOrder entity 45126 at the first level 45102. TheVendorGeneratedOrder entity 45126 is of a type G/CDT 45116“VendorGeneratedOrder” 45130. There is one 45128 VendorGeneratedOrderentity 45126 for each VendorGeneratedOrder package 45124.

The VendorGeneratedOrder package 45124 includes aBusinessDocumentMessageHeader package 45134 and an Order package 45136.BusinessDocumentMessageHeader package 45134 includes a MessageHeaderentity 45138 at the second level 45104. The MessageHeader entity 45138is of a G/CDT type 45116 “BusinessDocumentMessageHeader” 45142, andthere is one 45140 MessageHeader entity 45138 for eachBusinessDocumentMessageHeader package 45134.

The MessageHeader entity 45138 includes an ID 45148, a ReferenceID45158, a CreationDateTime 45168, a SenderParty 45176, and aRecipientParty 45102A at the third level 45106. The ID 45148 is of atype G/CDT 45116 “BusinessDocumentMessageID” 45152, and there is one45150 ID 45148 for a MessageHeader entity 45138. The ID 45148 has alength 45120 of 1 to 35 45154. The ReferenceID 45158 is of a type G/CDT45116 “BusinessDocumentMessageID” 45162, and there is zero or one 45160ReferenceID 45158 for a MessageHeader entity 45138. The ReferenceID45158 has a length 45120 of 1 to 35 45164. The CreationDateTime 45168 isof a type G/CDT 45116 “DateTime” 45172, and there is one 45170CreationDateTime 45168 for a MessageHeader entity 45138. The SenderParty45176 is of a type G/CDT 45116 “BusinessDocumentMessageHeaderParty”45180, and there is zero or one 45178 SenderParty 45176 for aMessageHeader entity 45138. The RecipientParty 45102A is of a type G/CDT45116 “BusinessDocumentMessageHeaderParty” 45106A, and there is zero orone 45104A RecipientParty 45102A for a MessageHeader entity 45138.

The SenderParty45176 includes an InternalID 45186 and a StandardID 45194at the fourth level 45108. The InternalID 45186 is of a type G/CDT 45116“PartyInternalID” 45190, and there is zero or one 45188 InternalID 45186for a SenderParty 45176. The StandardID 45194 is of a type G/CDT 45116“PartyStandardID” 45198, and there is any number 45196 of StandardID45194 for a SenderParty 45176.

The RecipientParty 45102A includes an InternalID 45112A and a StandardID45120A at the fourth level 45108. The InternalID 45112A is of a typeG/CDT 45116 “PartyInternalID” 45116A, and there is zero or one 45114AInternalID 45112A for a RecipientParty 45102A. The StandardID 45120A isof a type G/CDT 45116 “PartyStandardID” 45124A, and there is any number45122A of StandardID 45120A for a RecipientParty 45102A.

The Order package 45136 includes a VenderGeneratedOrder entity 45128A atthe second level 45104; a Party package 45154A; aTransportMeansDescriptionCode 45158B, a GrossWeightMeasure 45168A, aNetWeightMessure 45178A, a HandlingUnit 45188B, and a Note 45198B at thethird level 45106; an Item package 45156A; and a HandlingUnit package45166G.

The VenderGeneratedOrder entity 45128A is of a type G/CDT 45116“VenderGeneratedOrder” 45132A, and there is one 45130AVenderGeneratedOrder entity 45128A for each Order package 45136. TheVenderGeneratedOrder entity 45128A includes an ID 45136A and aCreationDateTime 45146A at the third level 45106. The ID 45136A is of atype G/CDT 45116 “BusinessTransactionDocumentID” 45140A, and there iszero or one 45138A ID 45136A for each VenderGeneratedOrder entity45128A. The ID 45136A has a length 45120 of 1 to 35 45142A. TheCreationDateTime entity 45146A is of a type G/CDT 45116 “DateTime”45150A, and there is one 45148A CreationDateTime 45146A for eachVenderGeneratedOrder entity 45128A.

The Party package 45154A includes a BuyerParty entity 45158A and aVenderParty entity 45108B at the third level 45106. The BuyerPartyentity 45158A is of a type G/CDT 45116“BusinessTransactionDocunientParty” 45162A, and there is zero or one45160A BuyerParty entity 45158A for each Party package 45154A. TheVenderParty entity 45108B is of a type G/CDT 45116“BusinessTransactionDocumentParty” 45112B, and there is zero or one45110B VenderParty entity 45108B for each Party package 45154A.

The BuyerParty entity 45158A includes an InternalID 45168A, a StandardID45178A, a BuyerID 45188A, and a VendorID 45198A at the fourth level45108. The InternalID 45168A is of a type G/CDT 45116 “PartyInternalID”45172A, and there is zero or one 45170A InternalID entity 45168A foreach BuyerParty entity 45158A. The InternalID 45168A has a length 45120of 1 to 10 45174A. The StandardID 45178A is of a type G/CDT 45116“PartyStandardID” 45182A, and there is any number 45180A of StandardID45178A for each BuyerParty entity 45158A. The StandardID 45178A has alength 45120 of 1 to 13 or 1 to 9 45184A. The BuyerID 45188A is of atype G/CDT 45116 “PartyPartyID” 45192A, and there is zero or one 45190ABuyerID 45188A for each BuyerParty entity 45158A. The BuyerID 45188A hasa length 45120 of 1 to 10 45194A. The VendorID entity 45198A is of atype G/CDT 45116 “PartyPartyID” 45102B, and there is zero or one 45100BVendorID entity 45198A for each BuyerParty entity 45158A. The VendorIDentity 45198A has a length 45120 of 1 to 10 45104B.

The VendorParty entity 08B includes an InternalID 45118B, a StandardID45128B, a BuyerID 45138B, and a VendorID 45148B at the fourth level45108. The InternalID 45118B is of a type G/CDT 45116 “PartyInternalID”45122B, and there is zero or one 45120B InternalID 45118B for eachVendorParty entity 45108B. The InternalID 45118B has a length 45120 of 1to 10 45124B. The StandardID 45128B is of a type G/CDT 45116“PartyStandardID” 45132B, and there is any number 45130B of StandardID45128B for each VendorParty entity 45108B. The StandardID 45128B has alength 45120 of 1 to 13 or 1 to 9 45134B. The BuyerID 45138B is of atype G/CDT 45116 “PartyPartyID” 45142B, and there is zero or one 45140BBuyerID 45138B for each VendorParty entity 45108B. The BuyerID 45138Bhas a length 45120 of 1 to 10 45144B. The VendorID 45148B is of a typeG/CDT 45116 “PartyPartyID” 45152B, and there is zero or one 45150BVendorID 45148B for each VendorParty entity 45108B. The Vendor 45148Bhas a length 45120 of 1 to 10 45154B.

The Order package 45136 includes a TransportMeansDescriptionCode 45158B,a GrossWeightMeasure 45168B, a NetWeightMeasure 45178B, a HandlingUnit45188B, and a Note 45198B at the third level 45106. TheTransportMeansDescriptionCode 45158B is of a type G/CDT 45116“TransportMeansDescriptionCode” 45162B, and there is zero or one 45160BTransportMeansDescriptionCode 45158B for each Order package 45136. TheTransportMeansDescriptionCode 45158 has a length 45120 of 4 45164B. TheGrossWeightMeasure 45168B is of a type G/CDT 45116 “Measure” 45172B, andthere is zero or one 45170B GrossWeightMeasure 45168B for each Orderpackage 45136. The GrossWeightMeasure 45168B has a length 45120 of 19 or6 45174B. The NetWeightMeasure 45178B is of a type G/CDT 45116 “Measure”45182B, and there is zero or one 45180B NetWeightMeasure 45178B for eachOrder package 45136. The NetWeightMeasure 45178B has a length 45120 of19 or 6 45184B. The HandlingUnit 45188B is of a type G/CDT 45116“Measure” 45192B, and there is zero or one 45190B HandlingUnit 45188Bfor each Order package 45136. The HandlingUnit 45188B has a length 45120of 19 or 6 45194B . The Note 45198B is of a type G/CDT 45116 “Note”45102C, and there is zero or one 45100C Note 45198B for each Orderpackage 45136. The Note 45198B has a length 45120 of 1 to 132 45104C.

The Item package 45156A includes an Item entity 45108C at the thirdlevel 45106; a BusinessTransactionDocumentReference package 45146C; aLocation package 45148C, a ProductInformation package 45150C, aPromotion package 45152C; a NetWeightMeasure 45158F and a Note 45168F atthe fourth level 45108; and a ScheduleLine package 45154C.

The Item entity 45108C is of a type G/CDT 45116“VendorGeneratedOrderItem” 45112C, and there is at least one 45110C.Item entity 45108C for each Item package 45156A. The Item entity 45108Cincludes an ID 45116C, a AcceptanceStatusCode 45126C, and aConsigmentIndicator 45136C at the fourth level 45108.

The ID 45116C is of the type G/CDT 45116“BusinesssTransactionDocumentItemID” 45120C, and there is zero or one45118C ID 45116C for each Item entity 45108C. The ID 45116C has a length45120 of 1 to 10 45122C. The AcceptanceStatusCode 45126C is of a typeG/CDT 45116 “AcceptanceStatusCode” 45129C, and there is zero or one 451C28 AcceptanceStatusCode 45126C for each Item entity 45108C. TheAcceptanceStatusCode 45126C has a length 45120 of two 45132C. TheConsignmentIndicator 45136C is of a type G/CDT 45116“ConsignmentIndicator” 45140C, and there is zero or one 45138CConsignmentIndicator 45136C for each Item entity 45108C. TheConsignmentIndicator 45136C has a length 45120 of one 45142C.

The BusinessTransactionDocumentReference package 45146C includes aSalesOrderReference entity 45156C at the fourth level 45108. TheSalesOrderReference entity 45156C is of a type G/CDT 45116“BusinessTransactionDocumentReference” 45160C, and there is zero or one45158C SalesOrderReference entity 45156C for eachBusinessTransactionDocumentReference package 45146C.

The Location package 45148C includes a ShipFromLocation entity 45164C, aTransshipmentLocation entity 45124D, and a ShipToLocation entity 45102Eat the fourth level 45108. The ShipFromLocation entity 45164C is of thetype G/CDT 45116 “BusinessTransactionDocumentShipFromLocation” 45168C,and there is zero or one 45166C ShipFromLocation entity 45164C for eachLocation package 45148C. The TransshipmentLocation entity 45124D is ofthe type G/CDT 45116 “BusinessTransactionDocumentTransshipmentLocation”45128D, and there is zero or one 45126D TransshipmentLocation entity45124D for each Location package 45148C. The ShipToLocation entity45102E is of the type G/CDT 45116“BusinessTransactionDocumentShipToLocation” 45106E, and there is one45104E ShipToLocation entity 45102E for each Location package 45148C.

The ShipFromLocation entity 45164C includes an InternalID 45174C, aStandardID 45184C, a BuyerID 45194C, a VendorID 45104D, and aLoadingLocation 45114D at the fifth level 45110. The InternalID 45174Cis of the type G/CDT 45116 “LocationInternalID” 45178C, and there iszero or one 45176C InternalID 45174C for each ShipFromLocation entity45164C. The InternalID 45174C has a length 45120 of 1 to 20 45180C. TheStandardID 45184C is of the type G/CDT 45116 “LocationStandardlID”45188C, and there is any number 45186C StandardID 45184C for eachShipFromLocation entity 45164C. The StandardID 45184C has a length 45120of 1 to 13 45190C. The BuyerID 45194C is of the type G/CDT 45116“LocationPartylID” 45198C, and there is zero or one 45196C BuyerID45194C for each ShipFromLocation entity 45164C. The BuyerID entity45194C has a length 45120 of 1 to 20 45100D. The VendorID 45104D is ofthe type G/CDT 45116 “LocationPartylID” 45108D, and there is zero or one45106D VendorID 45104D for each ShipFromLocation entity 45164C. TheVendorID 45104D has a length 45120 of 1 to 20 4511 OD. TheLoadingLocation 45114D is of the type G/CDT 45116“BusinessTransactionDocumentLocation” 45118D, and there is zero or one45116D LoadingLocation 45114D for each ShipFromLocation entity 45164C.

The TransshipmentLocation entity 45124D includes an InternalID 45134D, aStandardID 45144D, a BuyerID 45154D, a VendorID 45164D, an Address45174D, a LoadingLocation 45182D, and an UnloadingLocation 45192D at thefifth level 45110. The InternalID 45134D is of the type G/CDT 45116“LocationInternalID” 45138D, and there is zero or one 45136D InternalID45134D for each TransshipmentLocation entity 45124D. The InternalID45134D has a length 45120 of 1 to 20 45140D. The StandardID 45144D is ofthe type G/CDT 45116 “LocationStandardlID” 45148D, and there is anynumber 45146D StandardID 45144D for each TransshipmentLocation entity45124D. The StandardID 45144D has a length 45120 of 1 to 13 45150D. TheBuyerID 45154D is of the type G/CDT 45116 “LocationPartylID” 45158D, andthere is zero or one 45156D BuyerID 45154D for eachTransshipmentLocation entity 45124D. The BuyerID 45154D has a length45120 of 1 to 20 45160D. The VendorID 45164D is of the type G/CDT 45116“LocationPartylID” 45168D, and there is zero or one 45166D VendorID451064D for each TransshipmentLocation entity 45124D. The VendorID45164D has a length 45120 of 1 to 20 45170D. The Address 451 74D is ofthe type G/CDT 45116 “Address” 45178D, and there is zero or one 45176DAddress 45174D for each TransshipmentLocation entity 45124D. TheLoadingLocation 45182D is of the type G/CDT 45116“BusinessTransactionDocumentLocation” 45186D, and there is zero or one45184D LoadingLocation 45182D for each TransshipmentLocation entity45124D. The UnloadingLocation 45192D is of the type G/CDT 45116“BusinessTransactionDocumentLocation” 45196D, and there is zero or one45194D UnloadingLocation 45192D for each TransshipmentLocation entity45124D.

The ShipToLocation entity 45102E includes an InternalID 45112E, aStandardID 45122E, a BuyerID 45132E, a VendorID 45142E, and anUnloadingLocation 45152E at the fifth level 45110. The InternalID 45112Eis of the type G/CDT 45116 “LocationInternalID” 45116E, and there iszero or one 45114E InternalID 45112E for each ShipToLocation entity45102E. The InternalID entity 45112E has a length 45120 of 1 to 2045118E. The StandardID 45122E is of the type G/CDT 45116“LocationStandardlID” 45126E, and there is any number 45124E StandardID45122E for each ShipToLocation entity 45102E. The StandardID 45122E hasa length 45120 of 1 to 13 45128E. The BuyerID 45132E is of the typeG/CDT 45116 “LocationPartylID” 45136E, and there is zero or one 45134EBuyerID45132E for each ShipToLocation entity 45102E. The BuyerID 45132Ehas a length 45120 of 1 to 20 45138E. The VendorID 45142E is of the typeG/CDT 45116 “LocationPartylID” 45146E, and there is zero or one 45144EVendorID 45142E for each ShipToLocation entity 45102E. The VendorID45142E has a length 45120 of 1 to 20 45148E. The UnloadingLocation45152E is of the type G/CDT 45116 “BusinessTransactionDocumentLocation”45156E, and there is zero or one 45154E UnloadingLocation 45152E foreach ShipToLocation entity 45102E.

ProductInformation package 45150C includes a Product entity 45162E atthe fourth level 45108. The Product entity 45162E is of the type G/CDT45116 “BusinessTransactionDocumentProduct” 45166E, and there is one45164E Product entity 45162E for each ProductInformation package 45150C.

The Product entity 45162E includes an InternalID 45172E, a StandardID45182E, a BuyerID 45192E, a VendorID 45102F, and a PackageQuantity45112F at the fifth level 45110. The InternalID 45172E is of the typeG/CDT 45116 “ProductInternalID” 45176E, and there is zero or one 45174EInternalID 45172E for each Product entity 45162E. The InternalID 45172Ehas a length 45120 of 1 to 40 45178E. The StandardID 45182E is of thetype G/CDT 45116 “ProductStandardID” 45186E, and there is zero or one45184E StandardID 45182E for each Product entity 45162E. The StandardID45182E has a length 45120 of 1 to 14 45188E. The BuyerID 45192E is ofthe type G/CDT 45116 “ProductPartyID” 45196E, and there is zero or one45194E BuyerID 45192E for each Product entity 45162E. The BuyerID 45192Ehas a length 45120 of 1 to 40 45198E. The VendorID 45102F is of the typeG/CDT 45116 “ProductPartyID” 45106F, and there is zero or one 45104FVendorID 45102F for each Product entity 45162E. The VendorID 45102F hasa length 45120 of 1 to 40 45108F. The PackageQuantity 45112F is of thetype G/CDT 45116 “Quantity” 45116F, and there is zero or one 45114FPackageQuantity 45112F for each Product entity 45162E. ThePackageQuantity 45112F has a length 45120 of 19 or 6 45118F.

The Promotion package 45152C includes a Promotion entity 45122F at thefourth level 45108. There is zero or one 45124F Promotion entity 45122Ffor each Promotion package 45152C. The Promotion entity 22F includes anInternalID 45128F, a BuyerID 45138F, and a VendorID 45148F. TheInternalID 45128F is of the type G/CDT 45116 “PromotionInternalID”45132F, and there is zero or one 45130F InternalID 45128F for eachPromotion entity 22F. The InternalID 45128F has a length 45120 of 1 to35 45134F. The BuyerID 45138F is of a type G/CDT 45116“PromotionPartyID” 45142F, and there is zero or one 45140F BuyerID45138F for each Promotion entity 45122F. The BuyerID 45138F has a length45120 of 1 to 35 45144F. The VendorID 45148F is of a type G/CDT 45116“PromotionPartyID” 45152F, and there is zero or one 45150F VendorID45148F for each Promotion entity 45122F. The VendorID 45148F has alength 45120 of 1 to 35 45154F.

The NetWeightMeasure 45158F is of a type G/CDT 45116 “Measure” 45162F,and there is one or zero 45160F NetWeightMeasure 45158F for each Itempackage 45156A. The NetWeightMeasure 45158F has a length 45120 of 19 or6 45164F.

The Note 45168F is of a type G/CDT 45116 “Note” 45172F, and there iszero or one 45170F Note 45168F for each Item package 45156A. The Note45168F has a length 45120 1 to 132 45174F.

The ScheduleLine Package 45154C includes a ScheduleLine entity 45178Fand a ConfirmedScheduleLine entity 45122G at the fourth level 45108. TheScheduleLine entity 45178F is of a type G/CDT 45116“VendorGeneratedOrderItemScheduleLine” 45182F, and there is at least one45180F ScheduleLine entity 45178F for each ScheduleLine package 45154C.The ConfirmedScheduleLine entity 45122G is of a type G/CDT 45116“VendorGeneratedOrderItemScheduleLine” 45126G, and there is any number45124G ConfirmedScheduleLine entities 45122G for each ScheduleLinepackage 45154C.

The ScheduleLine entity 45178F includes a ShipmentGroupID 45186F, aDeliveryPeriod 45196F, a PickUpPeriod 45104G, and a Quantity 45112G atthe fifth level 45110. The ShipmentGroupID 45186F is of the type G/CDT45116 “BusinessTransactionDocumentGroupID” 45190F, and there is zero orone 45188F ShipmentGroupID 45186F for each ScheduleLine entity 45178F.The ShipmentGroupID 45186F has a length 45120 of 1 to 10 45192F. TheDeliveryPeriod 45196F is of a type G/CDT 45116 “DateTimePeriod” 45100G,and there is zero or one 45198F DeliveryPeriod 45196F for eachScheduleLine entity 45178F. The PickUpPeriod 45104G is of a type G/CDT45116 “DateTimePeriod” 45108G, and there is zero or one 45106GPickUpPeriod 45104G for each ScheduleLine entity 45178F. The Quantity45112G is of a type G/CDT 45116 “Quantity” 45116G, and there is one45114G Quantity 45112G for each ScheduleLine entity 45178F. The Quantity45112G has a length 45120 of 19 or 6 45118G.

The ConfirmedScheduleLine entity 45122G includes a ShipmentGroupID45130G, a DeliveryPeriod 45140G, a PickUpPeriod 45148G, and a Quantity45156G at the fifth level 45110. The ShipmentGroupID 45130G is of thetype G/CDT 45116 “BusinessTransactionDocumentGroupID” 45134G, and thereis zero or one 45132G ShipmentGroupID 45130G for eachConfirmedScheduleLine entity 45122G. The ShipmentGroupID 45130G has alength 45120 of 1 to 10 45136G. The DeliveryPeriod 45140G is of a typeG/CDT 45116 “DateTimePeriod” 45144G, and there is zero or one 45142GDeliveryPeriod 45140G for each ConfirmedScheduleLine entity 45122G. ThePickUpPeriod 45148G is of a type G/CDT 45116 “DateTimePeriod” 45152G,and there is zero or one 45150G PickUpPeriod 45148G for eachConfirmedScheduleLine entity 45122G. The Quantity 45156G is of a typeG/CDT 45116 “Quantity” 45160G, and there is one 45158G Quantity 45156Gfor each ConfirmedScheduleLine entity 45122G. The Quantity 45156G has alength 45120 of 19 or 6 45162G.

The HandlingUnit package 45166G includes a HandlingUnit entity 45168G atthe third level 45106. The HandlingUnit entity 45168G is of a type G/CDT45116 “HandlingUnit” 45172G, and there is any number 45170G HandlingUnitentities 45168G for each Handling package 45166G. The HandlingUnitentity 45168G includes an ID 45178G, a LoadCarrier 45188G, aHeightMeasure 45140H, a LengthMeasure 45150H, a WidthMeasure 45160H, aHandlingUnit 45170H, a GrossWeightMeasure 45180H, an AdditionalPackaging45190H, a LowerLevelHandlingUnit 45152I, and Load 45168I at the fourthlevel 45108.

The ID 45178G is of a type G/CDT 45116 “HandlingUnitID” 45182G, andthere is one 45180G ID 45178G for each HandlingUnit entity 45168G. TheID 45178G has a length 45120 of 1 to 20 45184G.

There is one 45190G LoadCarrier 45188G for each HandlingUnit entity45168G. The LoadCarrier entity 45188G includes one 45196G Product 45194Gat the fifth level 45110. The Product 45194G includes an InternalID45100H, a StandardID 45110H, a BuyerID 45120H, and a VendorID 45130H atthe sixth level 45112. The InternalID 45100H is of a type G/CDT 45116“ProductInternalID” 45104H, and there is zero or one 45102H InternalID45100I for each Product 45194G. The InternalID 45100H has a length 45120of 1 to 40 45106H. The StandardID 45110H is of a type G/CDT 45116“ProductStandardID” 45114H, and there is zero or one 45112H StandardID45110H for each Product 45194G. The StandardID 451100H has a length45120 of 1 to 1445116H. The BuyerID 45120H is of a type G/CDT 45116“ProductPartyID” 45124H, and there is zero or one 45122H BuyerID 45120Hfor each Product 45194G. The BuyerID 45120H has a length 45120 of 1 to40 45126H. The VendorID 45130H is of a type 45116 “ProductPartyID”45134H, and there is zero or one 45132H VendorID 45130H for each Product45194G. The VendorID 45130H has a length 45120 of 1 to 40 45136H.

The HeightMeasure 45140H is of a type G/CDT 45116 “Measure” 45144H, andthere is zero or one 45142H HeightMeasure 45140H for each HandlingUnitentity 45168G. The HeightMeasure 45140H has a length 45120 of 19 or 645146H.

The LengthMeasure 45150H is of a type G/CDT 45116 “Measure” 45154H, andthere is zero or one 45152H LengthMeasure 45150H for each HandlingUnitentity 45168G. The LengthMeasure 45150H has a length 45120 of 19 or 645156H.

The WidthMeasure 45160H is of a type G/CDT 45116 “Measure” 45164H, andthere is zero or one 45162H WidthMeasure 45160H for each HandlingUnitentity 45168G. The WidthMeasure 45160H has a length 45120 of 19 or 645166H.

The HandlingUnit 45170H is of a type G/CDT 45116 “Measure” 45174H, andthere is zero or one 45172H HandlingUnit 45170H for each HandlingUnitentity 45168G. The HandlingUnit 45170H has a length 45120 of 19 or 645176H.

The GrossWeightMeasure 45180H is of a type G/CDT 45116 “Measure” 45184H,and there is zero or one 45182H GrossWeightMeasure 45180H for eachHandlingUnit entity 45168G. The GrossWeightMeasure 45180H has a length45120 of 19 or 6 45186H.

There are any number 45192H AdditionalPackaging 45190H for eachHandlingUnit entity 45168G. The AdditionalPackaging 45190H includes one45198H Product 45196H and one 45144I Quantity 45142I at the fifth level45110. The Quantity 45142I is of the type 45116 “Quantity” 45146I. TheQuantity 45142I has a length 45120 of 19 or 6 45148I.

The Product 45196H includes an InternalID 45102I, a StandardID 45112I, aBuyerID 45122I, and a VendorID 45132I at the sixth level 45112. TheInternalID 45102I is of the type G/CDT 45116 “ProductInternalID” 45106I,and there is zero or one 45104I InternalID 45102I for each Product45196H. The InternalID 45102I has a length 45120 of 1 to 40 45108I. TheStandardID 45112I is of the type G/CDT 45116 “ProductStandardID” 45116I,and there is zero or one 45114I StandardID 45112I for each Product45196H. The StandardID 45112I has a length 45120 of 1 to 14 45118I. TheBuyerID 45122I is of the type G/CDT 45116 “ProductPartyID” 45126I, andthere is zero or one 45124I BuyerID 45122I for each Product 45196H. TheBuyerID 45122I has a length 45120 of 1 to 40 45128I. The VendorID 45132Iis of the type G/CDT 45116 “ProductPartyID” 45136I, and there is zero orone 45134I VendorID 45132I for each Product 45196H. The VendorID 45132Ihas a length 45120 of 1 to 40 45138I.

There is any number 45154I LowerLevelHandlingUnit 45152I for eachHandlingUnit entity 45168G. The LowerLevelHandlingUnit 45152I includesan ID 45158I at the fifth level 45110. The ID 45158I is of the typeG/CDT 45116 “HandlingUnitID” 45162I, and there is one 45160I ID 45158Ifor each LowerLevelHandlingUnit 45152I. The ID 45158I has a length 45120of 1 to 20 45164I.

There is any number 45170I of Load 45168I for each HandlingUnit entity45168G. The Load 45168I includes a BusinessTransactionDocumentReference45174I and a Quantity 45188I at the fifth level 45110.

The BusinessTransactionDocumentReference 45174I includes an ItemID45178I at the sixth level 45112. The ItemID 45178I is of a type G/CDT45116 “BusinessTransactionDocumentItemID” 45182I, and there is one45180I ItemID 45178I for each BusinessTransactionDocumentReference45174I. The ItemID 45178I has a length 45120 of 1 to 10 45184I.

The Quantity 45188I is of a type G/CDT 45116 “Quantity” 45192I, andthere is one 45190I Quantity 45188I for each Load 45168I. The Quantity45188I has a length 45120 of 19 or 6 45194I.

dd) Bundle Pricing Interfaces

(1) Motivating Business Scenario

Bundle pricing is a scenario that contains the entire functionality forbundle pricing determination that is used for settlement chargecalculation for a group of bank accounts (combined settlement).

Price determination takes place with the business-related aim ofgranting preferential prices for a group of accounts with various bankproducts and various account holders. The charges are determined on thebasis of business activities of the whole group, adjusted accordinglyand debited to the individual participant accounts.

The aim of bundle pricing is to reward customer loyalty and to ensure acloser connection between customers and the bank.

(2) Message Types

Methods and systems consistent with the subject matter described hereinuse the package template for a BusinessTransactionDocument for an SCMMaster Data depicted in FIG. 270B to derive theBusinessTransactionDocumentlmageRecognitionRequest interface.

(a) BankAccountBalanceReportQuery

A BankAccountBalanceReportQuery is a request made to Account Managementfor bank account balances. The structure of theBankAccountBalanceReportQuery message type is specified by theBankAccountBalanceReportQuery message data type.

(b) BankAccountBalanceReportResponse

A BankAccountBalanceReportResponse contains bank account balances and isthe reply from Account Management to the request for this information.The structure of the BankAccountBalanceReportResponse message type isspecified by the BankAccountBalanceReport message data type.

(3) Message Choreography

The following message choreography (see FIG. 452) describes the possiblelogical sequence of the messages that can be used to realize thescenario between Bundle Pricing 45200 and Account Management 45202.

The Bundle Pricing scenario requires account balances for a particularperiod of time to calculate charges for a group of bank accounts. Itrequests this information by sending a BankAccountBalanceReportQuerymessage 45204. Balances for a period, which are returned in aBankAccountBalanceReportResponse message 45206, are used (together withthe account conditions defined in bundle pricing) to calculate chargesfor a group of bank accounts.

During the request process, the request ID is used to relate theindividual messages to each other. This means that theBankAccountBalanceReportQuery message 45204 receives its own ID in theMessageHeader. The BankAccountBalanceReportResponse message 45206 refersto the request message using the ReferenceID. This method of relatingindividual messages is also used for the other query/response andrequest/confirmation message pairs within this choreography.

The Bundle Pricing scenario also requires bank account payment itemcounters. It requests this information by sending aBankAccountPaymentItemCounterQuery message 45208. The bank accountpayment item counters for a period are returned in aBankAccountPaymentItemCounterResponse message 45210.

The Bundle Pricing scenario also requires bank account attributeinformation. It requests this information by sending aBankAccountAttributeQuery message 45212. Bank account attributeinformation for a period is returned in a BankAccountAttributeResponsemessage 45214.

The Bundle Pricing scenario also requires bank account settlementresults. It requests this information by sending aBankAccountSettlementResultQuery message 45216. Bank account settlementresults for a period are returned in aBankAccountSettlementResultResponse message 45218.

The Bundle Pricing scenario also requires posting of bank accountentries. It makes this request by sending a BankAccountPostRequestmessage 45220. The confirmation of the posted bank account entries for aperiod is returned in a BankAccountPostConfirmation message 45222.

The Bundle Pricing scenario also requires cancellation of posted bankaccount entries. It requests the cancellation by sending aBankAccountPostCancellationRequest message 45224. Confirmation of thecancellation request is returned in aBankAccountPostCancellationConfirmation message 45226.

Transmission errors are handled by the infrastructure (message broker).A receiver system accepts inbound messages that are formally correct.Problems regarding the content are solved on the receiver side.

(4) Data Model of the Bank Account Balance Report Query Message

FIG. 453 depicts the data model for theBankAccountBalanceReportQueryMessage. TheBankAccountBalanceReportQueryMessage package 45300 message data typegroups together the business information that is relevant for sending abusiness document in a message and the Bank Account Balance Report Queryobject in the business document. TheBankAccountBalanceReportQueryMessage package 45300 includes aBankAccountBalanceReportQueryMessage entity 45302, a MessageHeaderpackage 45304, and a BankAccountBalanceReportQuery package 45306.

(a) Message Header Package

The MessageHeader package 45304 groups the business information that isrelevant for sending a business document in a message. It includes aMessageHeader entity 45308, a SenderParty entity 45310, and aRecipientParty entity 45312.

(i) Message Header Entity

The MessageHeader entity 45308 groups business information from theperspective of the sending application. This includes information toidentify the business document in a message, information about thesender, and in some cases, information about the recipient. TheMessageHeader entity 45308 is of type GDT:BusinessDocumentMessageHeader. There is a 1:1 relationship 45314 betweenthe MessageHeader entity 45308 and the BankAccountBalanceReportMessageentity 45302. The MessageHeader entity 45308 includes an ID element anda Reference ID element.

(ii) Sender Party Entity

A SenderParty entity 45310 is the party responsible for sending abusiness document on a business application level. The SenderPartyentity 45310 is of type GDT: BusinessDocumentMessageHeaderParty. Thereis a 1:c relationship 45316 between the SenderParty entity 45310 andMessageHeader entity 45308.

(iii) Recipient Party Entity

A RecipientParty entity 45312 is the party responsible for receiving abusiness document on a business application level. The RecipientPartyentity 45312 is of type GDT: BusinessDocumentMessageHeaderParty. Thereis a 1:c relationship 45318 between the RecipientParty entity 45312 andthe MessageHeader entity 45308.

(b) Bank Account Balance Report Query Package

The BankAccountBalanceReportQuery package 45306 groups together aBankAccountBalanceReportQuery entity 45320, a BankAccount package 45322,and an Item package 45324.

(i) Bank Account Balance Report Query Entity

The BankAccountBalanceReportQuery entity 45320 contains a request forbalance information for a bank account. There is a 1:1 relationship45326 between the BankAccountBalanceReportQuery entity 45320 and theBankAccountBalanceReportQueryMessage entity 45302.

(ii) Bank Account Package

The BankAccount package 45322 groups information about the bank accountfor which requests are to be made. The BankAccount package 45322includes a BankAccount entity 45328 and a Differentiator entity 45330.

(a) Bank Account Entity

The BankAccount entity 45334 determines the bank account for whichbalance information is to be ascertained. It contains information abouta participant bank account that is exchanged in business documentsaccording to general business understanding. The BankAccount entity45334 is of type GDT: BusinessTransactionDocumentBankAccount. There is a1:c relationship 45332 between the BankAccount entity 45328 and theBankAccountBalanceReport entity 45330.

(b) BankAccountDifferentiator Entity

The BankAccountDifferentiator entity 45330 is used to differentiatebetween accounts that are managed under one account number. TheBankAccountDifferentiator entity 45330 is of type GDT:BankAccountDifferentiatorID. The BankAccountDifferentiator entity 45330contains an element BankAccountDifferentiatorID that is a uniqueidentifier to differentiate between bank accounts. There is a 1:1relationship 45334 between the BankAccountDifferentiator entity 45330and the BankAccountBalanceReportQuery entity 45320.

(iii) BankAccountBalanceReportQueryItem Package

A BankAccountBalanceReportQueryItem package 45324 groups criteria thatare relevant for determining bank account balances. TheBankAccountBalanceReportQueryItem package 45324 contains aBankAccountBalanceReportQueryItem entity 45336.

(a) BankAccountBalanceReportQueryItem

The BankAccountBalanceReportQueryItem entity 45336 contains the criteriafor determining bank account balances. TheBankAccountBalanceReportQueryItem entity 45336 contains aBankAccountBalanceTypeCode element that specifies the type of bankaccount balance. The BankAccountBalanceTypeCode element is of type GDT:BankAccountBalanceTypeCode. The BankAccountBalanceReportQueryItem entity45336 also contains a DatePeriod element that specifies the period forwhich the bank account balances are to be taken into consideration. TheDataPeriod element is of type GDT: DatePeriod.

The criteria for an individual BankAccountBalanceReportQueryItem entity45336 are linked with AND. The criteria forBankAccountBalanceReportQueryItem entity 45336 on item level are linkedwith OR. There is a 1:cn relationship 45338 between theBankAccountBalanceReportQueryItem entity 45336 and theBankAccountBalanceReportQuery entity 45320.

(5) Data Model of the Bank Account Balance Report Response Message

FIG. 454 depicts the data model for theBankAccountBalanceReportResponseMessage. TheBankAccountBalanceReportResponseMessage package 45440 message data typegroups together the business information that is relevant for sending abusiness document in a message and the Bank Account Balance Reportobject in the business document. The BankAccountBalanceReportMessagepackage 45440 includes a BankAccountBalanceReportresponseMessage entity45442, a MessageHeader package 45444, and a BankAccountBalanceReportpackage 45446.

(a) Message Header Package

The MessageHeader package 45444 groups business information that isrelevant for sending a business document in a message. It includes aMessageHeader entity 45448, a SenderParty entity 45450, and aRecipientParty entity 45452.

(i) Message Header Entity

The MessageHeader entity 45448 is of type GDT:BusinessDocumentMessageHeader. The MessageHeader entity 45448 groupsbusiness information from the perspective of the sending application.This includes information to identify the business document in amessage, information about the sender, and in some cases, informationabout the recipient. There is a 1:1 relationship 45454 between theMessageHeader entity 45448 and theBankAccountBalanceReportResponseMessage entity 45442. The MessageHeaderentity 45448 includes an ID element and a Reference ID element.

(ii) Sender Party Entity

A SenderParty entity 45450 is the party responsible for sending abusiness document on a business application level. The SenderPartyentity 45410 is of type GDT: BusinessDocumentMessageHeaderParty. Thereis a 1:c relationship 45456 between the SenderParty entity 45450 andMessageHeader entity 45448.

(iii) Recipient Party Entity

A RecipientParty entity 45452 is the party responsible for receiving abusiness document on a business application level. The RecipientPartyentity 45452 is of type GDT: BusinessDocumentMessageHeaderParty. Thereis a 1:c relationship 45458 between the RecipientParty entity 45452 andthe MessageHeader entity 45448.

(b) Bank Account Balance Report Package

The BankAccountBalanceReport package 45406 groups together aBankAccountBalanceReport entity 45460, a Log package 45462, aBankAccount package 45464, and a BankAccountBalance package 45466.

(i) Bank Account Balance Report Entity

The BankAccountBalanceReport entity 45460 contains the information aboutthe balances of a bank account. A bank account balance is the differencebetween the debit and credit side of a bank account.

There is a 1:1 relationship 45468 between the BankAccountBalanceReportentity 45460 and the BankAccountBalanceReportResponseMessage entity45442.

(ii) Log Package

The Log package 45462 groups log information for bank account queries.It includes a Log entity 45470.

(a) Log Entity

The Log entity 45470 provides log information for bank account queries.A Log is a sequence of messages that are issued by an application whenit executes a task. There is a 1:c relationship 45472 between the Logentity 45470 and the BankAccountBalanceReport entity 45460.

(iii) Bank Account Package

The BankAccount package 45464 groups information about the bank accountfor which requests are to be made. The BankAccount package 45464includes a BankAccount entity 45474 and a BankAccountDifferentiatorentity 45476.

(a) Bank Account Entity

The BankAccount entity 45474 contains the bank account to which thebalance information belongs. The BankAccount entity 45474 is of typeGDT: BusinessTransactionDocumentBankAccount. There is a 1:c relationship45478 between the BankAccount entity 45474 and theBankAccountBalanceReport entity 45460.

(b) BankAccountDifferentiator Entity

The BankAccountDifferentiator entity 45476 is used to differentiatebetween accounts that are managed under one account number. TheBankAccountDifferentiator entity 45476 is of type GDT:BankAccountDifferentiatorID. A BankAccountDifferentiatorID element is aunique identifier to differentiate between bank accounts. There is a 1:crelationship 45480 between the BankAccountDifferentiator entity 45476and the BankAccountBalanceReport entity 45460.

(iv) Bank Account Balance Package

The BankAccountBalance package 45466 groups account balances. TheBankAccountBalance package 45466 contains a BankAccountBalance entity45482.

(a) Bank Account Balance Entity

The BankAccountBalance entity 45482 contains bank account balances. TheBankAccountBalance entity 45482 is of type GDT: BankAccountBalance.There is a 1:cn relationship 45444 between the BankAccountBalance entity45482 and the BankAccountBalanceReport entity 45460.

(6) Element Structure BankAccountBalanceReportResponse

The message data type element structure for theBankAccountBalanceReportResponse message is depicted in FIG. 455A-B. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 45500 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 455A, the interface forBankAccountBalanceReportResponse Message includes four levels 45502,45504, 45506, and 45508. The outermost package of this interface is aBankAccountBalanceReportResponse package 45516, which includes aBankAccountBalanceReportResponse entity 45518 at the first level 45502.The BankAccountBalanceReportResponse entity 45518 is of a data type MDT455220 “BankAccountBalanceReportResponseMessage” 45524.

The BankAccountBalanceReportResponse message package 45516 includes aMessageHeader package 45526 and a BankAccountBalanceReport 45548. TheMessageHeader package 45526 includes a MessageHeader entity 45528. TheMessageHeader entity 45528 is a GDT 45532“BusinessDocumentMessageHeader” 45534, and there is either zero of one45530 MessageHeader entity 45528 for each MessageHeader package 45526.The MessageHeader entity 45528 includes a ReferenceID 45538. TheReferenceID 45538 is a GDT 45542 “BusinessDocumentMessageID” 45544, andthere is one ReferenceID 45538 for a MessageHeader entity 45528.

The BankAccountBalanceReport package 45548 includes aBankAccountBalanceReport entity 45550 at the second level. TheBankAccountBalanceReport entity 45550 is a “BankAccountBalanceReport”45556, and there is one 45552 BankAccountBalanceReport entity 45550 foreach BankAccountBalanceReport package 45548.

The BankA455ountBalanceReport 45548 includes a Log package 45560, aBankAccount package 45572, and a BankAccountBalance package 45504A. TheLog package includes a Log entity 45562 in the third level. The Logentity 45562 is a GDT 45566 “Log” 45568, and there is zero or one 45564Log entity 45562 for each Log package 45560.

The BankAccount package 45572 includes a BankAccount entity 45574 and aBankAccountDifferentiator entity 45584. The BankAccount entity 45574 isa GDT 45578 “BusinessTransactionDocumentBankAccount” 45580, and there iseither zero or one 45576 BankAccount entity 45574 for each BankAccountpackage 45572. The BankAccountDifferentiator entity 45584 is a“BankAccountDifferentiator” 45590, and there is either zero or one 45586BankAccountDifferentiator entity 45584 for each BankAccount package45572. The BankAccountDifferentiator entity 45584 includes an ID 45594at the fourth level. The ID 45594 is a GDT 45598“BankAccountDifferentiatorID 45500A, and there is either zero or one45596 ID 45594 for a BankAccountDifferentiator entity 45584.

The BankAccountBalance package 45504A includes a BankAccountBalanceentity 45506A. The BankAccountBalance entity 45506A is a GDT 45510A“BankAccountBalance” 45512A, and there is zero to any number 45508A ofBankAccountBalance entity 45506A in each BankAccountBalance package45504A.

(7) Element Structure Bank Account Balance Report Query

The message data type element structure for theBankAccountBalanceReportQuery message is depicted in FIG. 456A-B. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 45600 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 456A, the interface for BankAccountBalanceReportQueryMessage includes five levels 45602, 45604, 45606, 45608, and 45610. Theoutermost package of this interface is a BankAccountBalanceReportQuerypackage 45618, which includes a BankAccountBalanceReportQuery entity45620 at the first level 45602. The BankAccountBalanceReportQuery entity45620 is of a data type MDT 45622 “BankAccountBalanceReportQueryMessage”45624. The BankAccountBalanceReportQuery message package 45618 includesa MessageHeader package 45628 and a BankAccountBalanceReportQuery 45650.The MessageHeader package 45628 includes a MessageHeader entity 45630.The MessageHeader entity 45630 is a GDT 45634“BusinessDocumentMessageHeader” 45636, and there is either zero of one45632 MessageHeader entity 45630 for each MessageHeader package 45628.The MessageHeader entity 45630 includes an ID 45640. The eID 45640 is aGDT 45644 “BusinessDocumentMessageID” 45644, and there is one ID 45640for a MessageHeader entity 45630. The BankAccountBalanceReportQuerypackage 45650 includes a BankAccountBalanceReportQuery entity 45652 atthe second level. The BankAccountBalanceReportQuery entity 45652 is a“BankAccountBalanceReportQuery” 45658, and there is one 45654BankAccountBalanceReportQuery entity 45652 for eachBankAccountBalanceReportQuery package 45650.

The BankAccountBalanceReportQuery Package 45650 includes a BankAccountpackage 45662 and an Item package 45694. The BankAccount package 45662includes a BankAccount entity 45664 and a BankAccountDifferentiatorentity 45674. The BankAccount entity 45664 is a GDT 45668“BusinessTransactionDocumentbankAccount” 45670, and there is oneBankAccount entity 45664 for each BankAccount package 45662. TheBankAccountDifferentiator entity 45674 is a “BankAccountDifferentiator,”and there is either zero or one 45676 BankAccountDifferentiator entity45674 for each BankAccount package 45662. The BankAccountDifferentiatorentity 45674 includes an ID 45684 at the fourth level. The ID 45684 is aGDT 45688 “BankAccountDifferentiatorID” 45690, and there is either zeroor one 45686 ID 45684 for each BankAccountDifferentiator entity 45674.

The Item package 45694 includes an Item entity 45696. The Item entity45696 is a “BankAccountBalanceReportQueryItem” 45602A, and there is fromone to any number 45698 Item entity 45696 for each Item package 45694.The Item entity 45696 includes BankAccountBalanceTypeCode 45606A andDatePeriod 45616A at the fourth level. The BankAccountBalanceTypeCode45606A is a GDT 45610A “BankAccountBalanceTypeCode” 45612A, and there isone 45608A BankAccountBalanceTypeCode 45606A for each Item entity 45696.The Date Period 45616A is a GDT 45620A “DatePeriod” 45622A, and there isone 45618A DatePeriod 45616A for an Item entity 45696.

ee) Bank Account Statement Notification

A BankAccountStatementNotification is used to transmit information aboutturnovers of a bank account in a B2B process. The account statement canserve as a legally binding notification instrument from the bank to itscustomers. In some situations, if the customer raises no objection tothe settlement results listed within a certain period, the results ofthe settlement carried out by the bank can thereby be accepted by thecustomer.

Motivating business scenarios for the BankAccountStatementNotificationinterface include the Purchase2 Pay and Order2Cash business scenarios.In both scenarios, a bank processes payment orders and the resultingbookings are booked on the bank account of a corporate customer in anaccount management component.

The account management component generates account statements in orderto report all the movements and the start and end balance of the bankaccount held by the corporate customer. The account statements are sentfrom the bank to the PaymentProcessing component of the corporatecustomer using the BankAccountStatementNotification interface.

In the In-House Cash scenario, the interfaceBankAccountStatementNotification is a shared service center scenario.The central payment service replaces the external banks in case ofintra-group transactions or transactions with external businesspartners. In this case, the In-House Cash center acts as a virtual bankand creates bank account statements for the affiliated companies.

A message type BankAccountStatementNotification can be a notificationabout a bank account statement from the bank to the bank account holder.A BankAccountStatement can be a legally binding statement of a bankabout turnovers on a customer's bank account. In variations, thestructure of the message type BankStatementNotification is determined bythe message data type BankAccountStatementMessage. In someimplementations, the receiver of the BankAccountStatementNotificationand the account holder may differ.

Methods and systems consistent with the subject matter described hereinuse the package template for a BusinessTransactionDocument for an SCMMaster Data depicted in FIG. 270B to derive theBankAccountStatementNotification interface.

(1) Message Choreography

FIG. 457 depicts a message choreography that describes the logicalsequence of messages that may be necessary to realize a scenario betweenfive systems, including an HCM Payroll system 45700, a Payment system45702 for the payment transaction initiator, a Bank system 45704 for thepayment transaction initiator party, a Bank system 45706 for the paymenttransaction destinated party, and a Payment system 45708 for the paymenttransaction destinated party. The HCM Payroll system 45700 initiates aPaymentRequest message 45710 to the Payment system 45702. Upon receiptof the PaymentRequest message 45710, the Payment system 45702 transmitsa PaymentAdviceNotification message 45712 to the Payment system 45708 toadvise the payment destinated transaction party of the pending payment.The Payment system 45702 also transmits a CollectivePaymentOrderRequestmessage 45714 to the Bank system 45704 of the payment transactioninitiator party. Upon receipt of the CollectivePaymentOrderRequestmessage 45714, the Bank system 45704 forwards an IntraBankPayReqnotification 45716 to the Bank system 45706 for the payment transactiondestinated party. Subsequently, the Bank system 45704 relays a Cash flowremittance 45718 to the Bank 45706. Optionally, upon receipt of theIntraBankPayReq notification 45716, the Bank system 45706 can initiate acash flow directed debiting order 45720 to Bank system 45704 as analternative form of payment to Bank system 45706. After Bank system45704 has transmitted payment to Bank system 45706, Bank system 45704sends BankAccountStatementNotification message 45722 to the Paymentsystem 45702. Similarly, after Bank system 45706 has received paymentfrom Bank system 45704, Bank system 45706 sendsBankAccountStatementNotification message 45724 to the Payment system45708.

The BankAccountStatementNotificationMessage encompasses two relatedinterfaces: BankAccountStatementNotification_Out andBankAccountStatementNotification_In. The InterfaceBankAccountStatementNotification_Out is used to send aBankAccountStatementNotification message asynchronously from a bank orcentral payment service to the bank statement receiver. The InterfaceBankAccountStatementNotification_In is used to receive an asynchronousBankAccountStatementNotification message.

(2) Message Data Type Data Model

FIG. 458A depicts a data model for theBankAccountStatementNotificationMessage. The message data typeBankAccountStatementNotificationMessage includes a bank accountstatement in a business document and business information that isrelevant for sending a business document in a message.

The message data type BankAccountStatementNotificationMessage includes aBankAccountStatementMessage package 45800, which includes aBankAccountStatementMessage entity 45802. TheBankAccountStatementMessage package 45800 also includes a MessageHeaderpackage 45804 and a BankAccountStatement package 45806. The message datatype BankAccountStatementMessage provides the structure for the messagetype BankAccountStatementNotification and the interfaces that are basedon it.

There is a 1:c relationship between entities in this Interface unlessotherwise noted herein or indicated in the Figures.

(a) Message Header Package

The MessageHeader package 45804 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader Package 45804 includes a MessageHeader entity 45808, whichgroups the business information from the viewpoint of the sendingapplication to identify the business document in a message, informationabout the sender, and, optionally, information about the recipient. TheMessageHeader entity 45808 may be divided up into a SenderParty 45810and a RecipientParty 45812, and is of type GDT:BusinessDocumentMessageHeaderParty. The MessageHeader entity 45808 alsoincludes an ID, which is the identification of the business document inthe technical message, and a CreationDateTime, which is the creationdate of the business document in the technical message. There is a 1:1relationship between MessageHeader entity 45808 andBankAccountStatementMessage entity 45802.

A SenderParty entity 45810 is the party responsible for sending abusiness document at the business application level and is of type GDT:BusinessDocumentMessageHeaderParty.

A RecipientParty entity 45812 is the party responsible for receiving abusiness document at the business application level and is of type GDT:BusinessDocumentMessageHeaderParty.

(b) Bank Account Statement Package

The BankAccountStatement package 45806 groups the BankAccountStatemententity 45814 with its packages: a BankAccount package 45816 and aBankAccountStatementItem package 45818. There is a 1:1 relationshipbetween the BankAccountStatement entity 45814 and theBankAccountStatementMessage entity 45802.

A BankAccountStatement can be a legally binding statement of a bankabout turnovers on a customer's bank account. It includes turnovers(items) for a defined date period or the new turnovers since theprevious BankAccountStatement was generated. Optionally, it additionallyincludes opening and closing balance information.

(i) Bank Account Statement

A BankAccountStatement entity 45814 includes header information and oneor more items containing information concerning a single turnover. TheBankAccountStatement entity 45814 includes the following elements: ID;Date; ValidityPeriod; OpeningBalanceAmount; ClosingBalanceAmount;TotaIDebitAmount; TotalCreditAmount; and ItemTotalNumberValue.

The ID is a unique identifier for an account statement (statementnumber) that is created by the bank and is of type GDT:BusinessTransactionDocumentID. The Date is the date on which thestatement was created and is of type GDT: Date. TheValidityPeriod is thevalidity period of the account statement and is of type GDT: DatePeriod.The OpeningBalanceAmount is an amount in the account before the firsttransaction reported that is equal to the ClosingBalanceAmount of theprevious statement for this account and is of type GDT: Amount. TheClosingBalanceAmount is an amount in the account after the lasttransaction reported that is equal to the OpeningBalanceAmount of thenext statement for this account and is of type GDT: Amount. TheTotaIDebitAmount is the total amount of debited items and is of typeGDT: Amount. The TotalCreditAmount is the total amount of credited itemsand is of type GDT: Amount. The ItemTotalNumberValue is the total numberof items of the actual bank statement and is of type GDT:TotalNumberValue.

In one implementation, the integrity includes the following attributes:An ID (statement number) must be a positive natural number. The ID mustbe continuous (i.e., without gaps) and unique within a calendar year.Finally, the numbering sequence should start with one (1). AnOpeningBalanceAmount must be equal to a ClosingBalanceAmount of theprevious statement for this account. A TotaIDebitAmount, if used, mustbe equal to the total number of debit items reported in the respectivebank statement. A TotalCreditAmount, if used, must be equal to the totalnumber of credit items reported in the respective bank statement. AnItemTotalNumberValue, if used, must be equal to the total number of bankstatement items for the respective bank statement.

(ii) Bank Account Package

The BankAccount package 45816 groups the information about the bankaccount that is reported in the subsequent BankAccountStatementItem. TheBankAccount package 45816 includes a BankAccount entity 45820.

The BankAccount entity 45820 is the bank account whose activities arereported in this account statement, and is of type GDT:BusinessTransactionDocumentBankAccount. In one implementation, theBankAccount entity 45820 is mandatory.

(iii) Bank Account Statement Item Package

The BankAccountStatementItem package 45818 groups the informationconcerning a single turnover. It includes an Item entity 45822 with thefollowing packages: a Party package 45824; a BankAccount package 45826;a BusinessTransactionDocumentReference package 45828, and optionally, aPaymentExplanationItem package 45830.

(a) Bank Account Statement Item

The BankAccountStatementItem entity 45822 is a single turnover (creditor debit) on the bank account. Optionally, items may be accompanied bypayment explanation items. There is a 1:cn relationship between theBankAccountStatementItem entity 45822 and BankAccountStatement entity45814. The BankAccountStatementItem includes the following elements: ID;PaymentTransactionTypeCode; PaymentTransactionTypeDescrption;BankValueDate; BankPostingDate; BankPostingTime; Amount;BankExchangeRate; BankChargeAmount; OriginalCurrencyAmount;OriginalBankChargeAmount; BankPaymentTransactionReferenceID;BankPrimaNotaNote; and Note.

The ID is a unique identifier for the item, which is preferably the itemnumber that is created by the bank and is of type GDT:BusinessTransactionDocumentItemID. The PaymentTransactionTypeCodedescribes the type of the payment transaction that is reflected in thisitem and is of type GDT: PaymentTransactionTypeCode. ThePaymentTransactionTypeDescription is a textual description of thepayment transaction type and is of type GDT: Description. TheBankValueDate is the date from which the bank transaction is reflectedin the interest statement and is of type GDT: Date. The BankPostingDateis the bank's posting date for this item and is of type GDT: Date. TheBankPostingTime is the bank's posting time for this item and is of typeGDT: Time. The Amount is the amount of credit or debit in accountcurrency and is of type GDT: Amount. The BankExchangeRate is theexchange rate applied by the bank in case the transaction currencydiffers from account currency and is of type GDT: ExchangeRate. TheBankChargeAmount is the charge in account currency that the bank debitedand deducted from the incoming payment added to the outgoing payment andis of type GDT: Amount. The OriginalCurrencyAmount is of originalpayment amount in original payment currency and is of type GDT: Amount.The OriginalBankChargeAmount is the charge deducted be the paymenttransaction initiator's house bank in original payment currency and isof type GDT: Amount. The BankPaymentTransactionReferenceID is thereference number created by the bank that identifies the paymenttransaction that is reflected in this item and is of type GDT:PaymentTransactionReferenceID. The BankPrimaNotaNote is the bank'sdaybook note that is used for organizational distinctions and is of typeGDT: Note. The Note includes explanatory notes for the account holderand is of type GDT: Note.

(b) Party Package

As shown in FIG. 458B, the Party package 45824 groups the informationconcerning the parties involved in the payment transaction. Partypackage 45824 includes the following entities:PaymentTransactionInitiatedParty entity 45832;PaymentTransactionDestinatedParty entity 45834;OriginalPaymentTransactionInitiatorParty 45836; andFinalPaymentTransactionDestinatedParty 45838.

A PaymentTransactionInitiatedParty entity 45832 is the party thatinitiated the payment (e.g., bank transfer or direct debit) and is oftype GDT: BusinessTransactionDocumentParty. In one implementation, onlythe elements StandardID, PaymentInitiatorID, PaymentRecipientID, Addressand ContactPerson are required. A PaymentTransactionInitiatedPartyentity 45832 is optional.

A PaymentTransactionDestinatedParty 45834 is the party that receives thepayment in case of a bank transfer or whose account is debted in case ofa direct debit. The PaymentTransactionDestinatedParty 45834 is of typeGDT: BusinessTransactionDocumentParty. In one implementation, only theelements StandardID, PaymentInitiatorID, PaymentRecipientID, Address andContactPerson are required. The PaymentTransactionDestinatedParty entity45834 is optional.

The payment transaction can optionally be executed by thePaymentTransactionInitiatorParty entity 45832 on behalf of anOriginalPaymentTransactionInitiatorParty 45836. TheOriginalPaymentTransactionInitiatorParty entity 45836 is of type GDT:BusinessTransactionDocumentParty. In one implementation, only theelements StandardID, PaymentInitiatorID, PaymentRecipientID, Address andContactPerson are required. The OriginalPaymentTransactionInitiatorParty45836 is optional and should only be used in case the party is differentfrom the PaymentTransactionInitiatorParty entity 45832.

The PaymentTransactionDestinatedParty entity 45834 optionally canreceive a payment or be debited on behalf of aFinalPaymentTransactionDestinatedParty entity 45838. TheFinalPaymentTransactionDestinatedParty entity 45838 is of type GDTBusinessTransactionDocumentParty. In one implementation, only theelements StandardID, PaymentInitiatorID, PaymentRecipientID, Address,and ContactPerson are required. TheFinalPaymentTransactionDestinatedParty entity 45838 is optional andshould only be supplied in case it is different from thePaymentTransactionDestinatedParty 45834.

(c) Bank Account Package

The BankAccount package 45826 groups the information concerning the bankdetails of the parties involved in case the item resulted from a paymenttransaction. The BankAccount package 45826 includes aPaymentTransactionInitiatorBankAccount entity 45840, aPaymentTransactionDestinatedBankAccount entity 45842, and aPartnerBankAccount entity 45844.

All BankAccounts are optional. In one implementation, only oneBankAccount may be filled because the respective offsetting account isalways the BankAccount entity 45820. If the bank is able to provide theinformation who initiated the payment, eitherPaymentTransactionInitiatorBankAccount entity 45840 orPaymentTransactionDestinatedBankAccount 45842 should be filled. In casethe bank is unable to provide this information, PartnerBankAccountentity 45844 should be used instead.

The PaymentTransactionInitiatorBankAccount entity 45840 is the bankaccount of the PaymentTransactionInitiatorParty entity 45832 and is oftype GDT: BusinessTransactionDocumentBankAccount.

The PaymentTransactionDestinatedBankAccount 45842 is the bank account ofthe PaymentTransactionDestinatedParty entity 45834, i.e., the partyreceiving the payment in case of a bank transfer or that isautomatically debited in case of a direct debit. ThePaymentTransactionDestinatedBankAccount 45842 is of type GDT:BusinessTransactionDocumentBankAccount.

The PartnerBankAccount entity 45844 is the bank account of the partnerof a PaymentTransaction and is of type GDT:BusinessTransactionDocumentBankAccount. In one implementation, thePartnerBankAccount entity 45844 is filled in case the bank can notprovide information about the payment transaction initiator.

(d) Business Transaction Document Reference Package

The Business Transaction Document Reference package 45828 groupsreferences to business documents connected to the bank statement item(currently only a check number). The Business Transaction DocumentReference package 45828 includes the PaymentReference entity 45846, thePaymentOrderReference entity 45848, the ChequeReference entity 45850,and the BillOfExchangeReference entity 45852. TheBusinessTransactionDocumentReferences are optional.

The PaymentReference entity 45846 is a reference to the paymenttransaction initiator's payment document representing the actual paymentand is of type GDT: BusinessTransactionDocumentReference. In oneimplementation, only the element ID is required. A payment documentindicates a cash flow. The PaymentReference entity 45846 includes atleast the payment procedure, the payment currency, the payment amount,the payment date, and the payment receiver. Optionally, thePaymentReference entity 45846 may include, in addition to otherattributes, the parties involved and their respective bank details.

The PaymentOrderReference entity 45848 is a reference to the paymenttransaction initiators payment order that led to the payment transactionreflected in this account statement item. The PaymentOrderReferenceentity 45848 is of type GDT: BusinessTransactionDocumentReference. Inone implementation, only the element ID is required. The payment ordermay be a single or collective payment order.

The ChequeReference entity 45850 includes the check number in case ofcheck encashment and is of type GDT:BusinessTransactionDocumentReference. In one implementation, only theelement ID is required.

The BillOfExchangeReference entity 45852 is the reference to the bill ofexchange (bill of exchange number) that was used for the payment and isof type GDT: BusinessTransactionDocumentReference. In oneimplementation, only the element ID is required.

(e) Payment Explanation Item Package

The PaymentExplanationItem package 45830 groups the payment explanationitems for the payment, in particular explaining the reason for thepayment (e.g. by referring to one or more invoices), the payment amount(e.g. by giving the cash discount amounts) as well as, if necessary, thedifference between the expected and the actual amount for the payment.The PaymentExplanationItem package 45830 includes aPaymentExplanationItem entity 45854 and the following packages: Partypackage 45856, BusinessDocumentObjectReference package 45858 andPaymentDifferenceExplanationItem package 45860.

(i) Payment Explanation Item

A PaymentExplanationItem entity 45854 provides an explanation of thepayment amount for the payee and is of type GDT: PaymentExplanationItem.There is a 1:cn relationship between PaymentExplanationItem entity 45854and BankAccountStatementItem entity 45822.

PaymentExplanationItem entity 45854 refers to one or more invoices orother business documents relevant for the payment amount, includingadjustments applied by the payer. The PaymentExplanationItem entity45854 may include information to identify the respective invoices orcredit memos in the payee's financial accounting. Optionally,PaymentExplanationItem entity 45854 may provide additional informationabout potential differences between the invoice and the payment amount.

PaymentExplanationItem can be of type GDT: PaymentExplanationItem andcontain an ID, OffsettingIndicator, BusinessTransactionDocumentDate,NetAmount, GrossAmount, TransactionCurrencyGrossAmount,CashDiscountAmount, TransactionCurrencyCashDiscountAmount,WithholdingTaxAmount, BankFeeAmount, ScandinavianPaymentReferenceID,SwissPaymentReferenceID, and Note.

In a PaymentExplanationItem entity with those items, the ID can be anidentification of a PaymentExplanationItem in the context of a paymentor payment advice, where the ID is a unique identification of aPaymentExplanationItem, when combined with a PaymentID or aPaymentAdviceID, and the ID can be of type GDT:BusinessTransactionDocumentID. The OffsettingIndicator can specifywhether amounts contained in a given PaymentExplanationItem are offsettwith amounts from other PaymentExplanationItems on the same level orwhether these amounts are contained as a part in the TotaIDebitAmount orTotalCreditAmount of the BankAccountStatementItem. TheOffsettingIndicator can be of type GDT: Indicator. TheBusinessTransactionDocumentDate can be a date of the business documentrelated to the PaymentExplanationItem. TheBusinessTransactionDocumentDate can be of type GDT: Date. The NetAmountcan be a payed or transfered net amount of type GDT: Amount. TheGrossAmount can be an amount as given by the business document relatedto the PaymentExplanation, for example the amount of an invoice or aloan contract, of type GDT: Amount. The TransactionCurrencyGrossAmountcan be an amount of the business document in transaction currency and beof type GDT: Amount. The CashDiscountAmount can represent a deduced cashdiscount amount of type GDT: Amount. TheTransactionCurrencyCashDiscountAmount can represent an amount of cashdiscount in transaction currency and be of type GDT: Amount. TheWithholdingTaxAmount can represent deduced withholding tax and be oftype GDT: Amount. The BankFeeAmount can represent a deduced bank fee andbe of type GDT: Amount. The ScandinavianPaymentReferenceID can be areference to a payment as used in Scandinavian countries (so-calledKIDNO) and be of type GDT: ID. The SwissPaymentReferenceID can be areference to a payment as used in Switzerland (so-called ESR) and be oftype GDT: ID. The Note can be natural-language text that explains thepayment and deduced amounts and be of type GDT: Note.

In variations, PaymentExplanationItem entity 45854 must not be filledfor self-initiated items.

(ii) Payment Explanation Item Party Package

A PaymentExplanationItemParty package 45856 groups the informationconcerning the parties related to the explanation of a payment in aBankAccountStatement. The PaymentExplanationItemParty package 45856includes an OriginalPaymentTransactionInitiatorParty entity 45862 and aFinalPaymentTransactionDestinatedParty entity 45864. The partiescontained in PaymentExplanationItemParty package 45856 can differ fromthe respective parties of the BankAccountStatementItemParty package45824.

The function and structure of OriginalPaymentTransactionInitiatorPartyentity 45862 and a FinalPaymentTransactionDestinatedParty entity 45864of PaymentExplanationItemParty package 45856 is similar to the functionand structure of OriginalPaymentTransactionInitiatorParty entity 45836and a FinalPaymentTransactionDestinatedParty entity 45838 ofBankAccountStatementItemParty package 45824, respectively.

(iii) Payment Explanation Business Document Object Reference Package

A PaymentExplanationBusinessDocumentObjectReference package 45858 groupsreferences to business documents related to invoice information,contract information, and purchase order information between thePaymentTransactionInitiatorParty entity 45862 and thePaymentTransactionDestinatedParty entity 45864. APaymentExplanationItemBusinessDocumentObjectReference package 45858includes a PaymentTransactionInitiatorInvoiceReference entity 45866; aPaymentTransactionDestinatedInvoiceReference entity 45868; aPaymentTransactionInitiatorContractReference entity 45870; aPaymentTransactionDestinatedContractReference entity 45872; aPaymentTransactionlntitiatorPurchaseOrderReferenc entity 45874; and aPaymentTranactionDestinatedPurchaseOrderReference entity 45876.

The PaymentTransactionInitiatorInvoiceReference 45866 is a reference toan invoice of the PaymentTransactionInitiatorParty 45862. ThePaymentTransactionInitiatorInvoiceReference is of type GDT:BusinessTransactionDocumentReference, where only the element ID is used.

The PaymentTransactionDestinatedInvoiceReference 45868 is a reference toan invoice of the PaymentTransactionDestinatedParty 45864. ThePaymentTransactionDestinatedInvoiceReference 45868 is of type GDT:BusinessTransactionDocumentReference, where only the element ID is used.

The PaymentTransactionInitiatorContractReference 45870 is a reference toa contract of the PaymentTransactionInitiatorParty 45862. ThePaymentTransactionInitiatorContractReference 45870 is of type GDT:BusinessTransactionDocumentReference, where only the element ID is used.

The PaymentTransactionDestinatedContractReference 45872 is a referenceto a contract of the PaymentTransactionDestinatedParty 45864. ThePaymentTransactionDestinatedContractReference is of type GDT:BusinessTransactionDocumentReference, where only the element ID is used.

The PaymentTransactionInitiatorPurchaseOrderReference 45874 is areference to a PurchaseOrder of the PaymentTransactionInitiatorParty.The PaymentTransactionInitiatorPurchaseOrderReference 45874 is of typeGDT :BusinessTransactionDocumentReference, where only the element ID isused.

The PaymentTransactionDestinatedPurchaseOrderReference 45876 is areference to a PurchaseOrder of the PaymentTransactionDestinatedParty45834. The PaymentTransactionDestinatedInvoiceReference is of type GDT:BusinessTransactionDocumentReference, where only the element ID is used.

(iv) Payment Difference Explanation Item Package

A PaymentDifferenceExplanationItem package 45860 provides information,if necessary, to explain the difference between the expected and theactual amount for the payment. The PaymentDifferenceExplanationItempackage 45860 includes a PaymentDifferenceExplanation entity 45878 and aBusinessDocumentObjectReference package 45880.

There is a 1:cn relationship between the PaymentDifferenceExplanationentity 45878 and PaymentExplanationItem entity 45854. ThePaymentDifferenceExplanationItem entity is an explanation of thedifference between the expected and the actual amount of a payment.PaymentDifferenceExplanationItem is of type GDT:PaymentDifferenceExplanationItem and contains the elementsOffsettingIndicator, Amount, and PaymentDifferenceReasonCode.

OffsettingIndicator can specify whether the amounts contained in thegiven PaymentExplanationItem are offsetted with amounts from otherPaymentExplanationItems on the same level or whether these amounts arecontained as a part in another amount on this level and is of type GDT:Indicator. Amount can be an amount of the adjustment of a payment (incurrency of the payment) and is of type GDT: Amount.PaymentDifferenceReasonCode can be a coded representation of the reasonfor a payment difference and be of type GDT:PaymentDifferenceReasonCode.

The BusinessDocumentObjectReference package 45880 groups references tobusiness documents related to invoice information, contract information,and purchase order information between thePaymentTransactionInitiatorParty entity 45862 and thePaymentTransactionDestinatedParty entity 45864 as necessary to explainthe difference between the expected and the actual amount for thepayment.

A BusinessDocumentObjectReference package 45880 can include aPaymentTransactionInitiatorInvoiceReference entity 45882; aPaymentTransactionDestinatedInvoiceReference entity 45884; aPaymentTransactionInitiatorContractReference entity 45886; aPaymentTransactionDestinatedContractReference entity 45888; aPaymentTransactionInitiatorPurchaseOrderReferenc entity 45890; and aPaymentTranactionDestinatedPurchaseOrderReference entity 45892.

The PaymentTransactionInitiatorInvoiceReference 45882 is a reference toan invoice of the PaymentTransactionInitiatorParty 45882. ThePaymentTransactionInitiatorInvoiceReference is of type GDT:BusinessTransactionDocumentReference, where only the element ID is used.

The PaymentTransactionDestinatedInvoiceReference 45884 is a reference toan invoice of the PaymentTransactionDestinatedParty 45864. ThePaymentTransactionDestinatedInvoiceReference 45884 is of type GDT:BusinessTransactionDocumentReference, where only the element ID is used.

The PaymentTransactionInitiatorContractReference 45886 is a reference toa contract of the PaymentTransactionInitiatorParty 45862. ThePaymentTransactionInitiatorContractReference 45886 is of type GDT:BusinessTransactionDocumentReference, where only the element ID is used.

The PaymentTransactionDestinatedContractReference 45888 is a referenceto a contract of the PaymentTransactionDestinatedParty 45864. ThePaymentTransactionDestinatedContractReference 45888 is of type GDT:BusinessTransactionDocumentReference, where only the element ID is used.

The PaymentTransactionInitiatorPurchaseOrderReference 45890 is areference to a PurchaseOrder of the PaymentTransactionInitiatorParty.The PaymentTransactionInitiatorPurchaseOrderReference 45890 is of typeGDT :BusinessTransactionDocumentReference, where only the element ID isused.

The PaymentTransactionDestinatedPurchaseOrderReference 45892 is areference to a PurchaseOrder of the PaymentTransactionDestinatedParty45834. The PaymentTransactionDestinatedInvoiceReference 45892 is of typeGDT: BusinessTransactionDocumentReference, where only the element ID isused.

(3) Element Structure of Bank Account Statement Notification Message

The message data type element structure for theBankAccountStatementNotification message is depicted in FIG. 459A-I. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 45900 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 459A, the interface forBankAccountStatementNotification Message includes four levels 45902,45904, 45906 and 45908. The outermost package of this interface is aBankAccountStatementMessage package 45914, which includes aBankAccountStatementMessage entity 45916 at the first level 45902. TheBankAccountStatementMessage entity 45916 is of a data type MDT 45918“BankAccountStatementMessage” 45920.

The BankAccountStatementMessage package 45924 includes a MessageHeaderpackage 45922 and a BankAccountStatement package 45924. TheMessageHeader package 45922 includes a MessageHeader entity 45926 at thesecond level 45904. The MessageHeader entity 45926 is of a data type GDT45916 “MessageHeader” 45932, and there is one 45930 MessageHeader entity45926 for each BankAccountStatement package 45924.

The MessageHeader entity 45926 includes an ID 45934, a CreationDateTime45942, a SenderParty 45950, and a ReceiverParty 45958 at the third level45906. The ID 45934 is of a type GDT 45916 “BusinessDocumentMessageID”45940, and there is one 45936 ID 45934 for a MessageHeader entity 45926.The CreationDateTime 45942 is of a type GDT 45946 “DateTime” 45948, andthere is one 45944 CreationDateTime 45942 for a MessageHeader entity45926. The SenderParty 45950 is of a type GDT 45916“BusinessDocumentMessageHeaderParty” 45956, and there is zero or one45952 MessageHeader entity 45926 for a SenderParty 45950. TheReceiverParty 45958 is of a type GDT 45916“BusinessDocumentMessageHeaderParty” 45964, and there is any number45960 of MessageHeader entity 45926 for a ReceiverParty 45958.

The SenderParty45976 includes an InternalID 45986 and a StandardID 45994at the fourth level 45908. The InternalID 45986 is of a type G/CDT 45916“PartyInternalID” 45990, and there is zero or one 45988 InternalID 45986for a SenderParty 45976. The StandardID 45994 is of a type G/CDT 45916“PartyStandardID” 45998, and there is any number 45996 of StandardID45994 for a SenderParty 45976.

The BankAccount entity 45924 is of a data type AGDT 45916“BankAccountStatement” 45972, and there is one 45968 BankAccount entity45924 for each BankAccountStatement package 45966.

As depicted in FIG. 459B, the BankAccountStatement entity 45966 includesan ID 45974, a Date 45982, a ValidityPeriod 45990, anOpeningBalanceAmount 45998, a ClosingBalanceAmount 45908A, aTotaIDebitAmount 45916A, a TotalCreditAmount 24A, and anItemTotalNumberValue 32A at the fourth level 45908. The ID is of a typeGDT 45978 “BusinessTransactionDocumentID” 45980, and there is one 45976ID 45974 for a BankAccountStatement entity 45966. The Date 45982 is of atype GDT 45986 “Date” 45988, and there is one 45984 Date 45942 for aBankAccountStatement entity 45966. The Validity Period 45990 is of atype GDT 45994 “DatePeriod” 45996, and there is zero or one 45992 ofValidityPeriod 45990 for a BankAccountStatement entity 45966. TheOpeningBalanceAmount 45998 is of a type GDT 45904A “Amount” 45906A, andthere is zero or one 45902A of OpeningBalanceAmount 45998 for aBankAccountStatement entity 45966.

As depicted in FIG. 459C, the ClosingBalanceAmount 45908A is of a typeGDT 45912A “Amount” 45914A, and there is zero or one 45910ABankAccountStatement entity 45966 for each ClosingBalanceAmount package45908A. The TotaIDebitAmount entity 45916A is of a type GDT 45920A“Amount” 45922AA, and there is zero or one 45918A BankAccountStatemententity 45966 for each TotaIDebitAmount entity 45916A. TheTotalCreditAmount 45924A is of a type GDT 45928A “Amount” 45930A, andthere is zero or one 45926A of TotalCreditAmount 45924A for aBankAccountStatement entity 45966. The ItemTotalNumberValue 45932A is ofa type GDT 45936A “TotalNumberValue” 45938A, and there is zero or one45934A BankAccountStatement entity 45966 for each ItemTotalNumberValuepackage 45932A.

As depicted in FIG. 459D, the BankAccountStatementMessage package 45924includes a BankAccount package 45940A. The BankAccount package 45940A isof a type GDT 45946A “BusinessTransactionDocumentBankAccount” 45948A,and there is one 45944A of BankAccountStatement entity 45966 for eachBankAccount 45942A.

The BankAccountStatementMessage package 45924 also includes an Itempackage 45970A. The Item package 45970A is of type AGDT 45976A“BankAccountStatementItem” 45978A, and there is any number 45974A ofBankAccountStatement entity 45966 for each Item 45970A.

The BankAccountStatementMessage package 45924 also includes a Partypackage 45980A. The Party package 45980A includes an ID 45982A, aPaymentTranactionTypeCode 45990B, a PaymentTranactionTypeDescription45998B, a ValueDate 45908B, a PostingDateTime 45916B, a PstingDate45924B, an Amount 45932B, an Exchange Rate 45940B, a BankChargeAmount45948B, an OriginalCurrencyAmount 45956B, an OriginalBankChargeAmount45964B, a BankPaymentTransactionReferenceID 45972B, a BankPrimaNotaNote45980B, a Note 45988B, a PaymentTransactionaInitiatorPart 45996B, aPaymentTransactionDestinatedParty 45906C, anOriginalPaymentTranactionInitiatorParty 45914C and aFinalPaymentTransactionDestinatedParty 45922C shown at the fourth level45908.

As depicted in FIG. 459D, the ID 45982A is of type GDT 45986A“BusinessTransactionDocumentItemID” 45988A, and there is zero or one45984A of PartyPackage entity 45980A for each ID 45982A. ThePaymentTranactionTypeCode 45990B is of type GDT 45994A “PaymentTransaction TypeCode” 45996A, and there is zero or one 45992A ofPartyPackage entity 45980A for each PaymentTransactionTypeCode 45990A.The PaymentTransactionTypeDescription 45998B is of type GDT 45904B“Description” 45906B, and there is zero or one 45902B of PartyPackageentity 45980A for each PaymentTransactionDescription 45998A. TheValueDate 45908B is of type GDT 45912B “Date” 45914B, and there is zeroor one 45910B of PartyPackage entity 45980A for each ValueDate 45908B.The PostingDateTime 45916B is of type GDT 45920B “DateTime” 45922B, andthere is zero or one 45918B of PartyPackage entity 45980A for eachPostingDateTime 45916B.

As depicted in FIG. 459E, the PostingDate 45924B is of type GDT 45928B“Date” 45930B, and there is zero or one 45926B of PartyPackage entity45980A for each PostingDate 45924B. The Amount 45932B is of type GDT45936B “Amount” 45938B, and there is one 45934B of PartyPackage entity45980A for each Amount 45932B. The Exchange Rate 45940B is of type GDT45944B “ExchangeRate” 45946B, and there is zero or one 45942B ofPartyPackage entity 45980A for each ExchangeRate 45940B. TheBankChargeAmount 45948B is of type GDT 45952B “Amount” 45954B, and thereis zero or one 45950B of PartyPackage entity 45980A for eachBankChargeAmount 45948B.

The OriginalCurrencyAmount 45956B is of type GDT 45960B “Amount” 45962B,and there is zero or one 45958B of PartyPackage entity 45980A for eachOriginalCurrencyAmount 45956B.

As depicted in FIG. 459F, the OriginalBankChargeAmount 45964B is of typeGDT 45968B “Amount” 45970B, and there is zero or one 45966B ofPartyPackage entity 45980A for each OriginalBankChargeAmount 45964B. TheBankPaymentTransactionReferenceID 45972B is of type GDT 45976B“PaymentTransactionReferenceID” 45978B, and there is zero or one 45974Bof PartyPackage entity 45980A for each BankPaymentTransactionReferenceID45972B. The BankPrimaNotaNote 45980B is of type GDT 45984B “Note”45986B, and there is zero or one 45982B of PartyPackage entity 45980Afor each BankPrimaNotaNote 45980B. The Note 45988B is of type GDT 45992B“Note” 45994B, and there is any number 45984A of PartyPackage entity45980A for each Note 45988B. The PaymentTransactionaInitiatorPart 45996Bis of type GDT 45902C “BusinessTransactionDocumentParty” 45904C, andthere is zero or one 45998B of PartyPackage entity 45980A for eachPaymentTrnsactionInitiatorPart 45996B.

As depicted in FIG. 459G, the PaymentTransactionDestinatedParty 45906Cis of type GDT 45910C “BusinessTransactionDocumentParty” 45912C, andthere is zero or one 45908C of PartyPackage entity 45980A for eachPaymentTransactionDestinatedParty 45906C. TheOriginalPaymentTransactionInitiatorParty 45914C is of type GDT 45918C“BusinessTransactionDocumentParty” 45920C, and there is zero or one45916C of PartyPackage entity 45980A for eachOriginalPaymentTransactionInitatorParty 45914C. TheFinalPaymentTransactionDestinatedParty 45922C is of type GDT 45926C“BusinessTransactionDocumentParty” 45928C, and there is zero or one45924C of PartyPackage entity 45980A for eachFinalPaymentTransactionDestinatedParty 45928C.

As depicted in FIG. 459H, the Item package 45970A includes a BankAccountpackage 45930C. The BankAccount package 45930C includes aPaymentTransactionInitiatorBankAccount entity 45932C, aPaymentTransactionDestinatedBankAccountEntity 45940C, and aPartnerBankAccount entity 45948C. ThePaymentTransactionInitiatorBankAccount 45932C is a data type GDT 45936C“BusinessTransactionDocumentBankAccount” 45938C, and there is zero orone 45934C of Item entity 45970A for eachPaymentTransacfionInitiatorBankAccount 45932C. ThePaymentTransactionDestinatedBankAccount 45940C is a data type GDT 45944C“BusinessTransactionDocumentBankAccount” 45946C, and there is zero orone 45942C of Item entity 45970A for eachPaymentTransactionDestinatedBankAccount 45940C. The PartnerBankAccount45948C is a data type GDT 45952C“BusinessTransactionDocumentBankAccount” 45954C, and there is zero orone 45950C of Item entity 45970A for each PartnerBankAccount 45948C.

The Item package 45970A also includes aBusinessTransactionDocumentReference package 45956C. TheBusinessTransactionDocumentReference package 45958C includes aPaymentReference entity 45958C, a PaymentOrderReference entity 45966C, aChequeReference entity 45974C, a BillofExchangeReference entity 45982Cand a PaymentExplanationItem entity 45990C.

The PaymentReference 45958C is a data type GDT 45962C“BusinessTransactionDocumentReference” 45964C, and there is zero or one45960C of Item entity 45970A for each PaymentReference 45958C.

As depicted in FIG. 4591, the PaymentOrderReference 45966C is a datatype GDT 45970C “BusinessTransactionDocumentReference” 45972C, and thereis zero or one 45968C of Item entity 45970A for eachPaymentOrderReference 45966C.

The ChequeReference 45974C is a data type GDT 45978C“BusinessTransactionDocumentReference” 45980C, and there is zero or one45976C of Item entity 45970A for each ChequeReference 45974C.

The BillofExchangeReference 45982C is a data type GDT 45986C“BusinessTransactionDocumentReference” 45988C, and there is zero or one45984C of Item entity 45970A for each BillofExchangeReference 45982C.

The PaymentExplanationItem 45990C is a data type GDT 45994C“PaymentExplanationItem” 45996C, and there is zero or one 45992C of Itementity 45970A for each PaymentExplanationItem 45990C.

ff) Business Transaction Document Image Recognition Request

A BusinessTransactionDocumentImageRecognitionRequest is an interfacethat can be used to record data of a business document from an imagetemplate. The image template can be recognized either manually or viaOptical Character Recognition (OCR) software.

Companies can create invoices in paper form. The paper documents can besent to the appropriate invoice recipients by various means (fax,e-mail, post, etc.). These incoming invoices may be stored in digitalform once they are received. An invoice can be recorded manually usingthe digitalized image. To ease recording of data in an invoice,automatic entry using OCR software may be implemented.

If OCR software is used, the software can receive messages of a typeBusinessTransactionDocumentImageRecognitionRequest. The OCR software cancarry out image recognition and can also structure the data. If areceived document is an invoice, for example, a message of typeInvoiceRequest can be generated and this can be sent to anotherapplication for further processing.

The BusinessTransactionDocumentImageRecognitionRequest interface canalso be used to transfer digitalized invoice documents as images fordata entry to a system.

(1) Message Type

A message type BusinessTransactionDocumentlmageRecognitionRequest can bea request to record business document data either manually orautomatically from an image, for example, a digital image.

Methods and systems consistent with the subject matter described hereinuse the package template for a BusinessTransactionDocument for an SCMMaster Data depicted in FIG. 270B to derive theBusinessTransactionDocumentlmageRecognitionRequest interface.

(2) Message Choreography

FIG. 460 depicts a message choreography that describes the logicalsequence of messages in a scenario between two systems: an ImageRecognition Initiator 46000 and an Image Recognition Executor 46002. TheImage Recognition Initiator 46000 can record and digitalize the image ofa business document to be recognized and trigger image recognition. Totrigger image recognition, the Image Recognition Initiator 46000 cangenerate a BusinessTransactionDocumentlmageRecognitionRequest message46004, which can be accepted by an Image Recognition Executor 46002,charged with recognizing the image. The results of the Image RecognitionExecutor 46002 can be the recognition of an image. These results may notbe relevant for the image-recognition-triggering Image RecognitionInitiator 46000.

The Image Recognition Executor 46002 charged with recognizing the imagecan accept the information from theBusinessTransactionDocumentlmageRecognitionRequest message 46004. Basedon this information, image recognition can be carried out; and based onthe result of the image recognition, a business document can be created.The Image Recognition Executor 46002 can be an application system wherea person performs the image recognition manually or a system with OCRsoftware.

(3) Message Data Type Data Model

FIG. 461 depicts a data model for theBusinessTransactionDocumentImageRecognitionRequest. TheBusinessTransactionDocumentlmageRecognitionRequest message data typeincludes the BusinessTransactionDocumentlmageRecognition objectcontained in a business document.

The BusinessTransactionDocumentlmageRecognitionRequest package 46100includes a BusinessTransactionDocumentlmageRecognitionRequestMessageentity 46102 and a BusinessTransactionDocumentlmageRecognition package46104. The message data typeBusinessTransactionDocumentlmageRecognitionRequestMessage entity 46102provides the structure for the message typeBusinessTransactionDocumentlmageRecognitionRequest and the interfacesthat are based on it.

(a) Business Transaction Document Image Recognition package

The BusinessTransactionDocumentlmageRecognition package 46104 groups theBusiness Transaction Document Image with its packages. It can contain anAttachment package 46106 and aBusinessTransactionDocumentImageRecognitionRequest entity 46108. Thereis a 1:1 relationship between theBusinessTransactionDocumentlmageRecognitionRequestMessage entity 46102and the Business Transaction Document Image Recognition Request entity46108.

(i) Business Transaction Document Image Recognition

The Business Transaction Document Image Recognition entitiy includesinformation related to a recording of business document data from eithermanual or automatic recognition from a delivered digital image. TheBusiness Transaction Document Image Recognition entity contains detailson a document type to be generated (after recognition) and an attachmentwith the business information, and can contain a contact person. ABusinessTransactionDocumentTypeCode is a coded representation of thetype of business document and is of the type, GDT:BusinessTransactionDocumentTypeCode.

(ii) Attachment Package

The Attachment package 46106 is the grouping of all attachmentinformation with reference to the business document to be generated. Itcan include an Attachment entity 46110. ABusinessTransactionDocumentlmageAttachment entity 46110 includes anattachment containing the digitalized image information of a businessdocument (e.g., a scanned invoice) and can be of the type GDT:Attachment.

(4) Element Structure of Business Transaction Document Image RecognitionRequest Message

The message data type element structure for the business transactiondocument image recognition request message is depicted in FIG. 462. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 46200 in the interface, andrepresents the entities at various levels within the interface. Theinterface for business transaction document image recognition requestmessage includes four levels 46202, 46204, 46206 and 46208. Theoutermost package of this interface is aBusinessTransactionDocumentlmageRecognitionRequest Message package46214, which includes aBusinessTransactionDocumentImageRecogntionRequest entity 46216 at thefirst level 46202. TheBusinessTransactionDocumentlmageRecognitionRequest entity 46216 is of adata type MDT 46218“BusinessTransactionDocumentlmageRecognitionRequestMessage” 46220.

A BusinessTransactionDocumentlmageRecognition 46222 includes aBusinessTransactionDocumentImageRecognition entity 46224. TheBusinessTransactionDocumentImageRecognition entity 46224 has one 46226BusinessTransactionDocumentlmageRecognition entity 46224 for aBusinessTransactionDocumentImageRecognition package 46222. The data typename 46212 is BusinessTransactionDecoumentlmageRecognition 46236.

The BusinessTransactionDocumentlmageRecognition 46222 also includes aBusinessTransactionDocumentTypeCode 46230. TheBusinessTransactionDocumentTypeCode 46230 is of type GDT 46234“BusinessTransactionDocumentTypeCode” 46236, and there may be one 46232BusinessTransactionDocumentTypeCode entity 46230 for aBusinessTransactionDocumentTypeCode 46230.

An Attachment package 46238 inlcudes an Attachment entity 46240. TheAttachment entity is of type GDT 46244 “Attachment” 46246, and there maybe any number of Attachment entities 46246 for an Attachment 46238package.

gg) CollectivePaymentOrderRequest Interface

The CollectivePaymentOrderRequest interface is used to transmit paymentorders (e.g., payment or direct debit) in a B2B process. Motivatingbusiness scenarios for the CollectivePaymentOrderRequest interfaceinclude the Purchase2 Pay and Order2Cash business scenarios. Invariations of those scenarios, a CollectivePaymentOrderRequest messagecan be sent from the PaymentProcessing component of the paymenttransaction initiator system (e.g., a corporate ERP system) to the bankof the payment transaction destinated party. The destinated party system(e.g., the bank) can process the CollectivePaymentOrderRequest andresulting bookings can be booked on the bank account of a corporatecustomer in an account management component of the bank. The accountmanagement component can generate account statements(BankAccountStatementNotification) to report all the movements and thestart and end balance of the bank account held by the paymenttransaction initiator system (e.g., a corporate ERP system).

In an In-House Cash scenario, the interfaceCollectivePaymentOrderRequest can be used by a shared service centerversion of the above-mentioned business scenarios. In that scenario,central payment services can replace external banks in intra-grouppayment transactions.

(1) Message Type

(a) CollectivePaymentOrderRequest

A CollectivePaymentOrderRequest is a request with instructions to a bankto carry out one or more payment transactions (e.g., bank transfer ordirect debit). The structure of the message typeCollectivePaymentOrderRequest is provided by theCollectivePaymentOrderMessage data type. The payment transactioninitiator's bank account can be debited or credited, depending on thetype of the payment (e.g. direct debit, bank transfer, etc.).

Methods and systems consistent with the subject matter disclosed hereinuse the package template for a BusinessTransactionDocument for an SCMMaster Data depicted in FIG. 270B to derive theCollectivePaymentOrderRequest interface.

(2) Message Choreography

FIG. 463 depicts a message choreography forCollectivePaymentOrderRequest interfaces. The choreography describes thelogical sequence of messages that can be used to realize a scenariobetween five systems, including: a HCM Payroll system 46300; a Paymentsystem 46302 for the payment transaction initiator; a Bank system 46304for the payment transaction initiator party; a Bank system 46306 for thepayment transaction destinated party; and a Payment system 46308 for thepayment transaction destinated party. The HCM Payroll system 46300initiates a PaymentRequest message 46310 to the Payment system 46302.Upon receipt of the PaymentRequest message 46310, the Payment system46302 transmits a PaymentAdviceNotification message 46312 to the Paymentsystem 46308 to advise the payment destinated transaction party of thepending payment. The Payment system 46302 also transmits aCollectivePaymentOrderRequest message 46314 to the Bank system 46304 ofthe payment transaction initiator party. Upon receipt of theCollectivePaymentOrderRequest message 46314, the Bank system 46304forwards an IntraBankPayReq notification 46316 to the Bank system 46306for the payment transaction destinated party. Subsequently, the Banksystem 46304 relays a Cash flow remittance 46318 to the Bank 46306.Optionally, upon receipt of the IntraBankPayReq notification 46316, theBank system 46306 can initiate a cash flow directed debiting order 46320to Bank system 46304 as an alternative form of payment to Bank system46306. After Bank system 46304 has transmitted payment to Bank system46306, Bank system 46304 sends BankAccountStatementNotification message46322 to the Payment system 46302. Similarly, after Bank system 46306has received payment from Bank system 46304, Bank system 46306 sendsBankAccountStatementNotification message 46324 to the Payment system46308.

The choreography includes a PaymentProcessing component of the paymenttransaction initiator system which includes the Payment system 46302 forthe payment transaction initiator and the Bank system 46304 for thepayment transaction initiator party, which is an example of a centralpayment service. In the implementation shown in FIG. 463, the Payment46302 is operatively configured to send a CollectivePaymentOrderRequest46314 to the Bank system 46304 for the payment transaction initiatorparty as further discussed below.

The CollectivePaymentOrderRequest encompasses two related interfaces:CollectivePaymentOrderRequest_Out and CollectivePaymentOrderRequest_In.The interface CollectivePaymentOrderRequest_Out is used to send aCollectivePaymentOrderRequest message asynchronously to a bank orcentral payment service. The interface CollectivePaymentOrderRequest_Inis used to receive an asynchronous CollectivePaymentOrderRequestmessage.

(3) Message Data Type CollectivePaymentOrderMessage

The message data type CollectivePaymentOrderRequestMessage groups thebusiness information that is relevant for sending a business document ina message and the CollectivePaymentOrder object or entity included inthe business document. The message data typeCollectivePaymentOrderRequestMessage provides the structure for themessage type CollectivePaymentOrderRequest. As depicted in FIG. 464A,the message data type CollectivePaymentOrderRequestMessage includes aCollectivePaymentOrderMessage package 46400, which includes aMessageHeader package 46402, a CollectivePaymentOrder package 46404, anda CollectivePaymentOrderMessage entity 46406.

(a) MessageHeader Package

The MessageHeader package 46402 groups the business information that isrelevant for sending a business document in a message. The MessageHeaderpackage 46402 includes a MessageHeader entity 46408. The groupedbusiness information may include in the MessageHeader entity 46408, forexample, information to identify the business document in a message,information about the sender, and information about the recipient. Thereis a 1:1 relationship between the CollectivePaymentOrderMessage entity46406 and the MessageHeader entity 46408. Where a relationship isidentified between entitites in FIG. 464A for this Interface, therespective relationship is a 1:1 relationship unless otherwise notedherein or indicated in FIG. 464A-F. The MessageHeader package 46402 alsoincludes a SenderParty entity 46410 and a RecipientParty entity 46412.There is a 1:c relationship between the MessageHeader entity 46408 andthe SenderParty entity 46410 and a 1:cn relationship between theMessageHeader entity 46408 and the RecipientParty entity 46412.

The MessageHeader entity 46408 is of type GDT:BusinessDocumentMessageHeader, where, in one implementation, the ID,CreationDateTime, and SenderParty are used.

The SenderParty is the party responsible for sending a business documentat the business application level. The SenderParty entity 46410 is oftype GDT: BusinessDocumentMessageHeaderParty.

The RecipientParty is the party responsible for receiving a businessdocument at the business application level. The RecipientParty entity46412 is of type GDT: BusinessDocumentMessageHeaderParty.

(b) CollectivePaymentOrder Package

The CollectivePaymentOrder package 46404 includes aCollectivePaymentOrderParty package 46414, which may also be referred toas the Party package 46414, a CollectivePaymentOrderBankAccount package46416, which may also be referred to as a BankAccount package 46416, aPaymentOrder package 46418, and a CollectivePaymentOrder entity 46420.The CollectivePaymentOrder entity 46420 is an instruction to a creditinstitution to carry out one or more payment transactions (e.g. banktransfers or direct debits). The CollectivePaymentOrderParty Package46414 includes the payment order initiator party (e.g.,PaymentTransactionInitiatorParty entity 46422). TheCollectivePaymentOrderBankAccount Package 46416 includes the bankdetails for the payment order initiator party. The PaymentOrder Package46418 includes one or more instructions to a credit institution to carryout a single payment transaction (e.g. bank transfer or direct debit).

The CollectivePaymentOrder entity 46420 can include the followingelements:

(1) An ID that is a unique identifier for the collective payment orderthat is created by the PaymentTransactionInitiatorParty entity 46422.The ID is of type GDT: BusinessTransactionDocumentID.

(2) A PaymentFormCode that identifies the form of payment (e.g. bycheque, bank transfer, direct debit) and is of type GDT:PaymentFormCode. In one implementation, the PaymentFormCode may beconfigured to identify each payment form except an “Invoice”.

(3) A PaymentProcedureCode that identifies the payment procedure codethat determines one or more technical characteristics of paymentexecution (e.g. EU internal payment, domestic payment, foreign payment).The PaymentProcedureCode is of type GDT: PaymentProcedureCode.

(4) An AccountDebitIndicator that indicates whether the account of thepayment transaction destinated party is debited (e.g. if the paymentform is direct debit) or not. The AccountDebitIndicator is of type GDT:AccountDebitIndicator.

(5) A PaymentExecutionDate that identifies the execution date for thepayment. The PaymentExecutionDate is of type GDT: Date.

(6) A PaymentTransactionInitiatorBankAccountValueDate that identifiesthe expected value date on the payment transaction initiator's bankaccount. The PaymentTransactionInitiatorBankAccountValueDate is of typeGDT: Date.

(7) A PaymentTransactionDestinatedBankAccountValueDate that identifiesthe expected value date on the payment transaction destinated party'sbank account. The PaymentTransactionDestinatedBankAccountValueDate is oftype GDT: Date.

(8) A TotalNetAmount that identifies the total of all net amountsincluded in the collective payment order and is of type GDT: Amount.

(9) A PaymentOrderTotalNumberValue that identifies the total number ofall PaymentOrders included in the collective payment order. ThePaymentOrderTotalNumberValue is of type GDT: TotalNumberValue.

(i) CollectivePaymentOrderParty Package

The CollectivePaymentOrderParty package 46414 groups informationconcerning the parties involved in the payment transaction. As notedabove, the Party package 46414 includes thePaymentTransactionInitiatorParty entity 46422. ThePaymentTransactionInitiatorParty entity 46422 includes the party thatinitiated the payment (e.g. bank transfer or direct debit). ThePaymentTransactionInitiatorParty entity 46422 has a 1:c relationshipwith the CollectivePaymentOrder entity 46420 and is of type GDT:BusinessTransactionDocumentParty. In one implementation, only theelements StandardID, PaymentInitiatorID, PaymentRecipientID, Address andContactPerson are used in the PaymentTransactionInitiatorParty entity46422.

(ii) CollectivePaymentOrderBankAccount Package

The CollectivePaymentOrderBankAccount package 46416 groups theinformation concerning the bank details of the payment transactioninitiator and the bank account to be used by the bank for bank charges.The BankAccount package 46416 includes aPaymentTransactionInitiatorBankAccount entity 46424 and aBankChargesBankAccount entity 46426.

The PaymentTransactionInitiatorBankAccount entity 46424 is the bankaccount of the payment transaction initiator. ThePaymentTransactionInitiatorBankAccount entity 46424 is of type GDT:BusinessTransactionDocumentBankAccount. There is a 1:c relationshipbetween the CollectivePaymentOrder entity 46420 and thePaymentTransactionInitiatorBankAccount entity 46422.

The BankChargesBankAccount entity 46426 is the bank account that shallbe debited with the bank charges for the CollectivePaymentOrder 46404.The BankChargesBankAccount entity 46426 is of type GDT:BusinessTransactionDocumentBankAccount. There is a 1:c relationshipbetween the CollectivePaymentOrder entity 46420 and theBankChargesBankAccount entity 46426. The BankChargesBankAccount entity46426 is optional and, in one implementation, is only used if theBankChargesBankAccount entity 46426 differs fromPaymentTransactionInitiatorBankAccount entity 46422.

(iii) PaymentOrder Package

The PaymentOrder package 46418 includes a PaymentOrderParty package46428, which may also be referred to as a Party package 46428, aPaymentOrderBankAccount package 46430, which may also be referred to asa BankAccount package 46430, a PaymentOrderPaymentInstruction package46432, which may also be referred to as a PaymentInstruction package46432, a PaymentOrderCentralBankReport package 46434, which may also bereferred to as a PaymentOrderCentralBankReport package 46434, aPaymentOrderBusinessTransactionDocumentReference package 46436, whichmay also be referred to as a BusinessTransactionDocumentReferencepackage 46436 and a PaymentOrderPaymentExplanation package 46438, whichmay also be referred to as a PaymentExplanation package 46438. ThePaymentOrder package 46418 also includes a PaymentOrder entity 46440,which is an instruction to a credit institution to carry out a singlepayment transaction (e.g. bank transfer or direct debit). The Partypackage 46428 identifies the payment order destinated party apart otherparties. The BankAccout package 46430 includes the bank details for thedestinated party of the payment transaction. The PaymentInstructionpackage 46432 includes information for the participating banksconcerning the payment execution. The CentralBankReport package 46434provides legal reporting information to the central bank and informationto satisfy the legal reporting requirement for payments to foreignpayees. The BusinessTransactionDocumentReference package 46436 includesreferences to different documents involved in the payment transaction(e.g. checks). The PaymentExplanation package 46438 provides anexplanation for the purpose and the amount of the payment. ThePaymentExplanation package 46438 includes references to individualinvoices or credit memos.

The PaymentOrder entity 46440 includes the following elements:

(1) An ID that is a unique identifier for the PaymentOrder entity 46440created by the payment transaction initiator party. The ID is of typeGDT: BusinessTransactionDocumentID.

(2) A BillOfExchangeDueDate that identifies the bill of exchange duedate in case of bill of exchange payments. The BillOfExchangeDueDate isof type GDT: Date.

(3) A NetAmount, which is the payment amount associated with thePaymentOrder entity 46440. The NetAmount is of type GDT: Amount.

(4) A GrossAmount, which is the gross amount resulting from the businessdocuments referred to in the PaymentExplanation. The GrossAmount is oftype GDT: Amount.

(5) A CashDiscountAmount, which is the cash discount deducted from theGrossAmount. The CashDiscountAmount is of type GDT: Amount.

(6) A WithholdingTaxAmount, which is the amount of withholding taxcalculated for this payment transaction. The withholdingTaxAmount is oftype GDT: Amount.

(7) A Note, which provides additional remarks concerning the payment andis of type GDT: Note.

(8) A BankChargeBearerCode which determines how bank charges arehandled. The BankChargeBearerCode is of type GDT:BankChargeRegulationCode.

(9) A PriorityCode, which indicates whether execution of a payment isurgent. The PriorityCode is of type GDT:BusinessTransactionPriorityCode. The PriorityCode may, for example,indicate urgent or normal.

In variations, payment orders can be generated automatically whenpayments that are due are settled individually or collectively using thepayment program.

(a) PaymentOrderParty Package

The PaymentOrderParty package 46428, as shown in FIG. 464B, groups theinformation concerning the parties involved in the payment transaction.The PaymentOrderParty package 46428 includes aPaymentTransactionDestinatedParty entity 46442, anOriginalPaymentTransactionInitiatorParty entity 46444, and aFinalPaymentTransactionDestinatedParty entity 46446. In variations, thePaymentTransactionDestinatedParty entity 46442 is mandatory, and theOriginalPaymentTransaction InitiatorParty entity 46444 and theFinalPaymentTransactionDestinatedParty entity 46446 are optional and mayonly be used in case they are different from thePaymentTransactionInitiatorParty entity 46422 or thePaymentTransactionDestinatedParty entity 46442. There is a 1:crelationship between the PaymentOrder entity 46440 and each of thePaymentTransactionDestinatedParty entity 46442, theOriginalPaymentTransactionInitiatorParty entity 46444, and theFinalPaymentTransactionDestinatedParty entity 46446.

The PaymentTransactionDestinatedParty entity 46442 is the party thatreceives the payment or whose account is debted. ThePaymentTransactionDestinatedParty entity 46442 is of type GDT:BusinessTransactionDocumentParty. In one implementation, only theelements StandardID, PaymentInitiatorID, PaymentRecipientID, Address andContactPerson are used in the PaymentTransactionDestinatedParty entity46442.

The OriginalPaymentTransactionInitiatorParty entity 46444 is the partyon whose behalf the payment order may be executed by thePaymentTransactionInitiatorParty entity 46442. TheOriginalPaymentTransactionInitiatorParty entity 46444 is of type GDT:BusinessTransactionDocumentParty. In one implementation, only theelements StandardID, PaymentInitiatorID, PaymentRecipientID, Address andContactPerson are used in the OriginalPaymentTransactionInitiatorPartyentity 46444. The OriginalPaymentTransactionInitiatorParty entity 46444is optional and may be used when theOriginalPaymentTransactionInitiatorParty entity 46444 is not equal tothe PaymentTransactionInitiatorParty entity 46422.

The PaymentTransactionDestinatedParty entity 46442 may optionallyreceive a payment or be debited on behalf of theFinalPaymentTransactionDestinatedParty entity 46446. TheFinalPaymentTransactionDestinatedParty entity 46446 is of type GDT:BusinessTransactionDocumentParty. In one implementation, only theelements StandardID, PaymentInitiatorID, PaymentRecipientID, Address andContactPerson are used the FinalPaymentTransactionDestinatedParty entity46446. The FinalPaymentTransactionDestinatedParty entity 46446 isoptional and may be used when it is different from thePaymentTransactionDestinatedParty 46442.

(b) PaymentOrderBankAccount Package

The PaymentOrderBankAccount package 46430, as shown in FIG. 464B, groupsthe information concerning the bank details of the payment transactiondestinated party. The PaymentOrderBankAccount package 46430 includes thePaymentTransactionDestinatedBankAccount entity 46448. ThePaymentTransactionDestinatedBankAccount entity 46448 is the bank accountof the party that the payment transaction is destined. ThePaymentTransactionDestinatedBankAccount entity 46448 may beautomatically debited in case of a direct debit. ThePaymentTransactionDestinatedBankAccount entity 46448 is of type GDT:BusinessTransactionDocumentBankAccount and has a 1:c relationship withthe PaymentOrder entity 46440.

(c) PaymentOrderPaymentInstruction Package

The PaymentOrderPaymentInstruction package 46432, as shown in FIG. 464C,groups the information concerning the payment instructions sent togetherwith the payment order. The PaymentOrderPaymentInstruction package 46432includes a PaymentInstruction entity 46450 and aCorrespondenceBankDetails entity 46452.

The PaymentInstruction entity 46450 is an instruction to the executingbank related to the payment order, for example, to send a bank advice tothe payee. The PaymentInstruction entity 46450 is of type GDT:PaymentInstruction. The PaymentInstruction entity 46450 is optional.There is a 1:cn relationship between the PaymentOrder entity 46440 andthe PaymentInstruction entity 46450.

The CorrespondenceBankDetails entity 46452 includes the bank details ofa correspondence bank that should be used for forwarding the paymentorder. A correspondence bank is a bank (typically in a foreign country)to which a bank has a business connection. The correspondence bank isused as an intermediary, for example, for cross border payments. TheCorrespondenceBankDetails entity 46452 includes a Bank entity 46454 anda BankAccount entity 46456. The CorrespondenceBankDetails entity 46452contains also a CorrespondenceBankTypeCode element that is arepresentation of the type of correspondence bank, for example, an“intermediate bank” or “initiator's correspondence bank”. TheCorrespondenceBankTypeCode is of type GDT: CorrespondenceBankTypeCode.The CorrespondenceBankDetails entity 46452 is optional.

The Bank entity 46454 includes the address or identifier for therespective correspondence bank. The Bank entity 46454 is of type GDT:Bank. In one implementation, either the Bank entity 46454 or theBankAccount entity 46456 is supplied in the CorrespondenceBankDetailsentity 46452 but not both at the same time.

The BankAccount entity 46456 is a correspondence bank account and is oftype GDT: BusinessTransactionDocumentBankAccount.

(d) PaymentOrderCentralBankReport Package

The PaymentOrderCentralBankReport Package 46434, as shown in FIG. 464C,groups the information required for legal reporting. ThePaymentOrderCentralBankReport Package 46434 includes aCentralBankReportItem entity 46458. The CentralBankReportItem entity46458 includes information to satisfy the legal reporting to the centralbank and the requirement for payments to foreign payees. TheCentralBankReportItem entity 46458 is of type GDT:CentralBankReportItem. The CentralBankReportItem entity 46458 isoptional.

(e) PaymentOrderBusinessTransaction DocumentReference Package

The PaymentOrderBusinessTransactionDocumentReference package 46436, asshown in FIG. 464D, groups references to business documents involved inor used for the payment transaction (e.g. a check number). TheBusinessTransactionDocumentReference package 46436 is optional.

The PaymentOrderBusinessTransactionDocumentReference package 46436includes a PaymentReference entity 46460, a ChequeReference entity46462, and a BillOfExchangeReference entity 46464.

The PaymentReference entity 46460 is a reference to the payer's paymentdocument representing the actual payment. The PaymentReference entity46460 is of type GDT: BusinessTransactionDocumentReference. In oneimplementation, only the element ID in the PaymentReference entity 46460is used. As a payment documents a cash flow, the PaymentReference entity46460 includes at least the payment procedure, the payment currency, thepayment amount, the payment date and the payment receiver. ThePaymentReference entity 46460 may also identify the parties involved andthe bank details associated with a payment.

The ChequeReference entity 46462 is the reference to the check(checknumber) that was used for payment. The ChequeReference entity46462 is of type GDT: BusinessTransactionDocumentReference. In oneimplementation, only the element ID in the ChequeReference entity 46462is used.

The BillOfExchangeReference entity 46464 is the reference to the bill ofexchange (bill of exchange number) that was used for the payment. TheBillOfExchangeReference entity 46464 is of type GDT:BusinessTransactionDocumentReference. In one implementation, only theelement ID in the BillOfExchangeReference entity 46464 is used.

(f) Payment Order Payment Explanation Package

The PaymentOrderPaymentExplanation package 46438 groups the paymentexplanation items for a payment, such as the reason for the payment(e.g. by referring to one or more invoices), the payment amount (e.g. bygiving the cash discount amounts) as well as, if necessary, thedifference between the expected and the actual amount for the payment.The PaymentOrderPaymentExplanation package 46438 includes a Partypackage 46466, a BusinessDocumentObjectReference package 46468, aPaymentDifferenceExplanationItem package 46470 and aPaymentExplanationItem entity 46472.

(i) PaymentExplanationItem

The PaymentExplanationItem entity 46472 can explain the payment amountfor the payee. It can refer to one or more invoices or other businessdocuments relevant for the payment amount. This includes potentialadjustments applied by the payer.

The information contained can identify the respective invoices or creditmemos in the payee's financial accounting. Additionally it can explainpotential differences between the invoice and the payment amount.

The parties contained in PaymentExplanationItem entity 46472 can differfrom the respective parties of the PaymentOrder entity 46440. ThePaymentExplanationItem entity 46472 is of type GDT:PaymentExplanationItem.

The PaymentExplanationItem entity 46472 includes the following elements:

(1) An ID that is a unique identifier for the PaymentExplanationItementity 46472 in the context of a payment or payment advice. The ID is aunique identification of a PaymentExplanationItem entity 46472 whencombined with a PaymentID or a PaymentAdviceID. The ID is of type GDT:BusinessTransactionDocumentID.

(2) An OffsettingIndicator which specifies whether the amounts containedin the given PaymentExplanationItem entity 46472 are offset with amountsfrom other PaymentExplanationItems on the same level or whether theseamounts are contained as a part in the TotaIDebitAmount orTotalCreditAmount of the PaymentOrder. The OffsettingIndicator is of thetype GDT: Indicator.

(3) A BusinessTransactionDocumentDate which is the date of the businessdocument related to the PaymentExplanationItem entity 46472. TheBusinessTransactionDocumentDate is of the type GDT: Date.

(4) A NetAmount that is a payed or transfered net amount. The NetAmountis of the type GDT: Amount.

(5) A GrossAmount that is an amount as given by the business documentrelated to the PaymentExplanation, for example the amount of an invoiceor a loan contract. The GrossAmount is of the type GDT: Amount.

(6) A TransactionCurrencyGrossAmount that is the amount of the businessdocument in transaction currency. The TransactionCurrencyGrossAmount isof the type GDT: Amount.

(7) A CashDiscountAmount that is the deduced cash discount. TheCashDiscountAmount is of the typeGDT: Amount.

(8) A TransactionCurrencyCashDiscountAmount that is the amount of cashdiscount in transaction currency. TheTransactionCurrencyCashDiscountAmount is of the type GDT: Amount.

(9) A WithholdingTaxAmount that is deduced withholding tax. TheWithholdingTaxAmount is of the type GDT: Amount.

(10) A BankFeeAmount that is the deduced bank fee. The BankFeeAmount isof the type GDT: Amount.

(11) A ScandinavianPaymentReferenceID that is a reference to a paymentas used in Scandinavian countries (so-called KIDNO). TheScandinavianPaymentReferenceID is of the type GDT: ID.

(12) A SwissPaymentReferenceID that is a reference to a payment as usedin Switzerland (so-called ESR). The SwissPaymentReferenceID is of thetype GDT: ID.

(13) A Note that is a natural-language text item that explains thepayment and deduced amounts. The Note is of the type GDT: Note.

(ii) PaymentOrderPaymentExplanationParty Package

The Party Package 46466 can group the information concerning the partiesrelated to the explanation of a payment in a PaymentOrder package 46418.These parties may differ from the parties of the PaymentOrder package46418. The Party Package 46466 includes anOriginalPaymentTransactionInitiatorParty entity 46474 and aFinalPaymentTransactionDestinatedParty entity 46476.

The OriginalPaymentTransactionInitiatorParty entity 46474 can be theoriginal party on behalf of which the payment transaction is executed.The OriginalPaymentTransactionInitiatorParty entity 46474 is of typeGDT: BusinessTransactionDocumentParty. Only the elements StandardID,PaymentInitiatorID, PaymentRecipientID, Address and ContactPerson areused. The OriginalPaymentTransactionInitiatorParty entity 46474 isoptional and may only be supplied in the case where it is not equal tothe PaymentTransactionInitiatorParty entity 46422 of the PaymentOrderpackage 46418.

The FinalPaymentTransactionDestinatedParty entity 46476 can be the finalparty on behalf of which a payment is received or debited. TheFinalPaymentTransactionDestinatedParty entity 46476 is of type GDT:BusinessTransactionDocumentParty. Only the elements StandardID,PaymentInitiatorID, PaymentRecipientID, Address and ContactPerson areused. The FinalPaymentTransactionDestinatedParty entity 46476 can beoptional and may only be supplied in the case where it is different fromPaymentTransactionDestinatedParty entity 46442 of the PaymentOrderpackage 46418 Party package 46428.

(iii) PaymentOrderPaymentExplanationBusinessDocumentObjectReferencePackage

The BusinessDocumentObjectReference Package 46468 can group referencesto business documents related to the explanation of a payment in aPaymentOrder package 46418. The BusinessDocumentObjectReference Package46468 can include a PaymentTransactionInitiatorInvoiceReference entity46478, a PaymentTransactionDestinatedInvoiceReference entity 46480, aPaymentTransactionInitiatorContractReference entity 46482, aPaymentTransactionDestinatedContractReference entity 46484, aPaymentTransactionInitiatorPurchaseOrderReference entity 46486 and aPaymentTransactionDestinatedPurchaseOrderReference entity 46488.

The PaymentTransactionInitiatorInvoiceReference entity 46478 is areference to an invoice of the PaymentTransactionInitiatorParty entity46422. The PaymentTransactionInitiatorInvoiceReference entity 46478 isof the type GDT: BusinessTransactionDocumentReference, where only theelement ID is used.

The PaymentTransactionDestinatedInvoiceReference entity 46480 is areference to an invoice of the PaymentTransactionDestinatedParty entity46442. The PaymentTransactionDestinatedInvoiceReference entity 46480 isof the type GDT: BusinessTransactionDocumentReference, where only theelement ID is used.

The PaymentTransactionInitiatorContractReference entity 46482 is areference to a contract of the PaymentTransactionInitiatorParty entity46422. The PaymentTransactionInitiatorContractReference entity 46482 isof the type GDT: BusinessTransactionDocumentReference, where only theelement ID is used.

The PaymentTransactionDestinatedContractReference entity 46484 is areference to a contract of the PaymentTransactionDestinatedParty entity46442. The PaymentTransactionDestinatedContractReference entity 46484 isof the type GDT: BusinessTransactionDocumentReference, where only theelement ID is used.

The PaymentTransactionInitiatorPurchaseOrderReference entity 46486 is areference to a purchase order of the PaymentTransactionInitiatorPartyentity 46422. The PaymentTransactionInitiatorPurchaseOrderReferenceentity 46486 is of the type GDT: BusinessTransactionDocumentReference,where only the element ID is used.

The PaymentTransactionDestinatedPurchaseOrderReference entity 46488 is areference to a purchase order of the PaymentTransactionDestinatedPartyentity 46442. The PaymentTransactionDestinatedInvoiceReference entity46488 is of the type GDT: BusinessTransactionDocumentReference, whereonly the element ID is used.

(g) PaymentOrderPaymentExplanationPaymentDifferenceExplanation Package

The PaymentDifferenceExplanation Package 46470 can group theexplanations of differences between the expected and the actual amountsof payments occuring in a PaymentOrder package 46418. ThePaymentDifferenceExplanation Package 46470 includes aPaymentDifferenceExplanationItem entity 46490 and a packageBusinessDocumentObjectReference Package 46491.

(i) PaymentDifferenceExplanationitem

The PaymentDifferenceExplanationItem entity 46490 is an explanation ofthe difference between the expected and the actual amount of a payment.The PaymentDifferenceExplanationItem entity 46490 is of the type GDT:

PaymentDifferenceExplanationItem. The PaymentDifferenceExplanationItementity 46490 includes the following elements:

(1) An OffsettingIndicator that specifies, whether the amounts containedin the given PaymentExplanationItem entity 46472 are offsetted withamounts from other PaymentExplanationItems on the same level or whetherthese amounts are contained as a part in another amount on this level.The OffsettingIndicator is of the type GDT: Indicator.

(2) An Amount that is the amount of the adjustment of a payment (incurrency of the payment). The Amount is of the type GDT: Amount.

(3) A PaymentDifferenceReasonCode that is a coded representation of thereason for a payment difference. The PaymentDifferenceReasonCode is ofthe type GDT: PaymentDifferenceReasonCode.

(ii)PaymentOrderPaymentExplanationPaymentDifferenceExplanationBusinessDocumentObjectReferencePackage

The BusinessDocumentObjectReference Package 46491 can group referencesto business documents related to the explanation of payment differencesin a PaymentOrder package 46418. The BusinessDocumentObjectReferencePackage 46491 includes a PaymentTransactionInitiatorInvoiceReferenceentity 46492, a PaymentTransactionDestinatedInvoiceReference entity46494, a PaymentTransactionInitiatorContractReference entity 46496, aPaymentTransactionDestinatedContractReference entity 46497,aPaymentTransactionInitiatorPurchaseOrderReference entity 46498, and aPaymentTransactionDestinatedPurchaseOrderReference entity 46499.

The PaymentTransactionInitiatorInvoiceReference entity 46492 is areference to an invoice of the PaymentTransactionInitiatorParty entity46422. The PaymentTransactionInitiatorInvoiceReference entity 46492 isof the type GDT: BusinessTransactionDocumentReference, where only theelement ID is used.

The PaymentTransactionDestinatedInvoiceReference entity 46494 is areference to an invoice of the PaymentTransactionDestinatedParty entity46442. The PaymentTransactionDestinatedInvoiceReference entity 46494 isof the type GDT: BusinessTransactionDocumentReference, where only theelement ID is used.

The PaymentTransactionInitiatorContractReference entity 46496 is areference to a contract of the PaymentTransactionInitiatorParty entity46422. The PaymentTransactionInitiatorContractReference entity 46496 isof the type GDT: BusinessTransactionDocumentReference, where only theelement ID is used.

The PaymentTransactionDestinatedContractReference entity 46497 is areference to a contract of the PaymentTransactionDestinatedParty entity46442. The PaymentTransactionDestinatedContractReference entity 46497 isof the type GDT: BusinessTransactionDocumentReference, where only theelement ID is used.

The PaymentTransactionInitiatorPurchaseOrderReference entity 46498 is areference to a purchase order of the PaymentTransactionInitiatorPartyentity 46422. The PaymentTransactionInitiatorPurchaseOrderReferenceentity 46498 is of the type GDT: BusinessTransactionDocumentReference,where only the element ID is used.

The PaymentTransactionDestinatedPurchaseOrderReference entity 46499 is areference to a purchase order of the PaymentTransactionDestinatedPartyentity 46442. The PaymentTransactionDestinatedInvoiceReference entity46499 is of the type GDT: BusinessTransactionDocumentReference, whereonly the element ID is used.

(4) Element Structure of Collective Payment Order Request Message

The message data type element structure for theCollectivePaymentOrderRequest message is depicted in FIG. 465A-F. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 46500 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 465A, the interface for CollectivePaymentOrderRequestmessage includes five levels 46502, 46504, 46506, 46508 and 46510. Theoutermost package of this interface is a CollectivePaymentOrderMessagepackage 46516, which includes a CollectivePaymentOrderMessage entity46518 at the first level 46502. The CollectivePaymentOrderMessage entity46518 is of a data type MDT 46520 “CollectivePaymentOrderMessage” 46522.

The CollectivePaymentOrderMessage package 46516 includes a MessageHeaderpackage 46524 and a CollectivePaymentOrder package 46566. TheMessageHeader package 46524 includes a MessageHeader entity 46526 at thesecond level 46504. The MessageHeader entity 46526 is of a data type GDT46530 “MessageHeader” 46532, and there is one 46528 MessageHeader entity46526 for each CollectivePaymentOrderMessage package 46516.

The MessageHeader entity 46526 includes an ID 46534, a CreationDateTime46542, a SenderParty 46550, and a ReceiverParty 46558 at the third level46506. The ID 46534 is of a type GDT 46538 “BusinessDocumentMessageID”46540, and there is one 46536 ID 46534 for a MessageHeader entity 46526.The CreationDateTime 46542 is of a type GDT 46546 “DateTime” 46548, andthere is one 46544 CreationDateTime 46542 for a MessageHeader entity46526. The SenderParty 46550 is of a type GDT 46554“BusinessDocumentMessageHeaderParty” 46556, and there is zero or one46552 SenderParty 46550 for a MessageHeader entity 46526. TheReceiverParty 46558 is of a type GDT 46562“BusinessDocumentMessageHeaderParty” 46564, and there is any number46560 ReceiverParty 46558 for a MessageHeader entity 46526.

As depicted in FIG. 465B, the CollectivePaymentOrder package 46566includes a CollectivePaymentOrder entity 46568 is of a data type AGDT46572 “CollectivePaymentOrder” 46574, and there is one 46570CollectivePaymentOrder entity 46568 for each CollectivePaymentOrderpackage 46566.

The CollectivePaymentOrder entity 46568 includes an ID 46576, aPaymentFormCode 46584, a PaymentProcedureCode 46594, anAccountDebitIndicator 46502A, a PaymentExecutionDate 46510A, aPaymentTransactionInitiatorBankAccountValueDate CC 18A, aPaymentTransactionDestinated BankAccountValueDate 46526A, aTotalNetAmount 46534A, and a PaymentOrderTotalNumberValue 46542A at thethird level 46506. The ID 46576 is of a type GDT 46580“BusinessTransactionDocumentID” 46582, and there is zero or one 46578 ID46576 for a CollectivePaymentOrder entity 46568. The PaymentFormCode46584 is of a type GDT 46590 “PaymentFormCode” 46592, and there is one46588 PaymentFormCode 46584 for a CollectivePaymentOrder entity 46566.The PaymentProcedureCode 46594 is of a type GDT 46598“PaymentProcedureCode” 46500A, and there is one 46596 ofPaymentProcedureCode 46594 for a CollectivePaymentOrder entity 46568.The AccountDebitIndicator 46502A is of a type GDT 46506A“AccountDebitIndicator” 46508A, and there is one 46504A ofAccountDebitIndicator 46502A for a CollectivePaymentOrder entity 46568.The PaymentExecutionDate 46510A is of a type GDT 46514A “Date” 46516A,and there is one 46512A of PaymentExecutionDate 46510A for aCollectivePaymentOrder entity 46568. ThePaymentTransactionInitiatorBankAccountValueDate CC18A is of a type GDT46522A “Date” 46524A, and there is zero or one 46520A ofPaymentTransactionInitiatorBankAccountValueDate CC18A for aCollectivePaymentOrder entity 46568.

As depicted in FIG. 465C, the PaymentTransactionDestinatedBankAccountValueDate 46526A is of a type GDT 46530A “Date” 46532A, andthere is zero or one 46528A of PaymentTransactionDestinatedBankAccountValueDate 46526A for a CollectivePaymentOrder entity 46568.The TotalNetAmount 46534A is of a type GDT 46536A “Amount” 46540A, andthere is zero or one 46536A of TotalNetAmount 46534A for aCollectivePaymentOrder entity 46568. The PaymentOrderTotalNumberValue46542A is of a type GDT 46546A “TotalNumberValue” 46548A, and there iszero or one 46544A of PaymentOrderTotalNumberValue 46542A for aCollectivePaymentOrder entity 46568.

The CollectivePaymentOrder package 46566 includes a Party package 46550Athat includes a PaymentTransactionInitiatorParty entity 46552A at thethird level 46506. The PaymentTransactionInitiatorParty entity 46552A isof a type CDT 46556A “BusinessTransactionDocumentParty” 46558A, andthere is zero or one 46554A of PaymentTransactionInitiatorParty entity46552A for a Party package 46550A.

The CollectivePaymentOrder package 46566 includes a BankAccount package46560A that includes a PaymentTransactionBankAccount entity 46562A and aBankChargesBankAccount entity 46570A at the third level 46506. ThePaymentTransactionBankAccount entity 46562A is of a type GDT 46566A“BusinessTransactionDocumentBankAccount” 46568A, and there is zero orone 46564A of PaymentTransactionBankAccount entity 46562A for aBankAccount package 46560A. The BankChargesBankAccount entity 46570A isof a type GDT 46574A “BusinessTransactionDocumentBankAccount” 46576A,and there is zero or one 46572A of BankChargesBankAccount entity 46570Afor a BankAccount package 46560A.

The CollectivePaymentOrder package 46566 includes a PaymentOrder package46578A that includes a PaymentOrder entity 46580A at the third level46506. The PaymentOrder entity 46580A includes an ID 46588A, aBillOfExchangeDueDate 46596A, a NetAmount 46504B, a GrossAmount 46512B,a CashDiscountAmount 46520B, a WithholdingTaxAmount 46528B, a Note46536B, a BankChargeBearerCode 46544B and a PriorityCode 46552B, at theforth-level 46508. The PaymentOrder entity 46580A is of a type AGDT46584A “BusinessTransactionDocumentID” 46586A, and there is at least oneto an unlimited amount 46582A of PaymentOrder entity 46580A for aCollectivePaymentOrder package 46566.

The ID 46588A is of a type GDT 46592A “BusinessTransactionDocumentID”46594A, and there is zero or one 46590A ID 46588A for a PaymentOrder46580A. The BillOfExchangeDueDate 46596A is of a type GDT 465900B “Date”46502B, and there is zero or one 46598A BillOfExchangeDueDate 46596A fora PaymentOrder 46580A.

As depicted in FIG. 465D, the NetAmount 46504B is of a type GDT 46508B“Amount” 46510B, and there is one 46516B NetAmount 46504B for aPaymentOrder 46580A. The GrossAmount 46512B is of a type GDT 46516B“Amount” 46518B, and there is zero or one 46514B GrossAmount 46512B fora PaymentOrder 46580A. The CashDiscountAmount 46520B is of a type GDT46524B “Amount” 46526B, and there is zero or one 46522BCashDiscountAmount 46520B for a PaymentOrder 46580A. TheWithholdingTaxAmount 46528B is of a type GDT 46532B “Amount” 46534B, andthere is zero or one 46530B WithholdingTaxAmount 46528B for aPaymentOrder 46580A. The Note 46536B is of a type GDT 46540B “Note”46542B, and there is zero or one 46538B Note 46536B for a PaymentOrder46580A. The BankChargeBearerCode 46544B is of a type GDT 46548B“BankChargeBearerCode” 46550B, and there is zero or one 46546BBankChargeBearerCode 46544B for a PaymentOrder 46580A. The PriorityCode46552B is of a type GDT 46556B “BusinessTransactionPriorityCode” 46558B,and there is zero or one 46554B PriorityCode 46552B for a PaymentOrder46580A.

The PaymentOrder package 46578A includes a Party package 46560B thatincludes a PaymentTransactionDestinatedParty entity 46562B, anOriginalPaymentTransactionInitiatorParty entity 46570B, and aFinalPaymentTransactionlDestinatedParty entity 46578B at the forth level46508. The PaymentTransactionDestinatedParty entity 46562B is of a typeCDT 46566B “BusinessTransactionDocumentParty” 46568B, and there is zeroor one 46564B PaymentTransactionDestinatedParty entity 46562B for aParty package 46560B. The OriginalPaymentTransactionInitiatorPartyentity 46570B is of a type CDT 46574B “BusinessTransactionDocumentParty”46576B, and there is zero or one 46572BOriginalPaymentTransactionInitiatorParty entity 46570B for a Partypackage 46560B.

As depicted in FIG. 465E, the FinalPaymentTransactionDestinatedParty46578B is of a type CDT 46582B “BusinessTransactionDocumentParty”46584B, and there is zero or one 46580BFinalPaymentTransactionDestinatedParty 46578B for a Party package46560B.

The PaymentOrder package 46578A includes a BankAccount package 46586Bthat includes a PaymentTransactionDestinated BankAccount entity 46588Bat the forth level 46508. The PaymentTransactionDestinatedBankAccountentity 46588B is of a type GDT 46592B“BusinessTransactionDocumentBankAccount” 46594B, and there is zero orone 46590B PaymentTransactionDestinatedBankAccount entity 46588B for aBankAccount package 46586B.

The PaymentOrder package 46578A includes a PaymentInstruction package46596B that includes a PaymentInstruction entity 46598B and aCorrespondenceBankDetails entity 46506C at the forth level 46508. ThePaymentInstruction entity 46598B is of a type GDT 46502C“PaymentInstruction” 46504C, and there is zero to unlimited 46500CPaymentInstruction entity 46598B for a PaymentInstruction package46596B. The CorrespondenceBankDetails entity 46506C is of a type AGDT46510C “PaymentOrderCorrespondenceBankDetails” 46512C, and there is zeroto three 46508C CorrespondenceBankDetails entity 46506C for aPaymentInstruction package 46596B.

The CorrespondenceBankDetails entity 46506C includes aCorrespondenceBankTypeCode 46514C, a Bank 46522C, and a BankAccount46530C at the fifth level 46510. The CorrespondenceBankTypeCode 46514Cis of a type GDT 46518C “CorrespondenceBankTypeCode” 46520C, and thereis one 46516C CorrespondenceBankTypeCode 46514C for aCorrespondenceBankDetails 46506C. The Bank 46522C is of a type GDT46526C “Bank” 46528C, and there is zero to one 46524C Bank 46522C for aCorrespondenceBankDetails 46506C. The BankAccount 46530C is of a typeGDT 46534C “BusinessTransactionDocumentBankAccount” 46536C, and there iszero to one 46532C BankAccount 46530C for a CorrespondenceBankDetails46506C.

The PaymentOrder package 46578A includes a StateCentralBankReportpackage 46538C that includes a CentralBankReportItem entity 46540C atthe forth level 46508. The CentralBankReportItem entity 46540C is of atype GDT 46544C “CentralBankReportItem” 46546C, and there are zero tounlimited 46542C CentralBankReportItem entity 46540C for aStateCentralBankReport package 46538C.

As depicted in FIG. 465F, the PaymentOrder package 46578A includes aBusinessTransactionDocumentReference package 46548C which includes aPaymentReference entity 46550C, a ChequeReference entity 46558C, and aBillOfExchangeReference entity 46566C at the forth level 46508. ThePaymentReference entity 46550C is of a type GDT 46554C“BusinessTransactionDocumentReference” 46556C, and there is zero to one46552C PaymentReference entity 46550C for aBusinessTransactionDocumentReference package 46548C. The ChequeReferenceentity 46558C is of a type GDT 46562C“BusinessTransactionDocumentReference” 46564C, and there are zero to one46560C ChequeReference entity 46558C for aBusinessTransactionDocumentReference package 46548C. TheBillOfExchangeReference entity 46566C is of a type GDT 46570C“BusinessTransactionDocumentReference” 46572C, and there is zero to one46568C BillOfExchangeReference entity 46566C for aBusinessTransactionDocumentReference package 46548C.

The PaymentOrder package 46578A includes a PaymentExplanation package46575C that includes a PaymentExplanationItem entity 46576C at the forthlevel 46508. The PaymentExplanationItem entity 46576C is of a type GDT46580C “PaymentExplanationItem” 46582C, and there is zero to umlimited46578C PaymentExplanationItem entity 46576C for a PaymentExplanationpackage 46575C.

hh) Credit Payment Behavior Summary Interfaces

CreditPaymenBehaviorSummary interfaces transfer information about thepayment behavior of a business partner. They are based on the messagetype CreditPaymentBehaviorSummaryNotification. In a company, creditmanagement is responsible for checking the creditworthiness of businesspartners and for real-time monitoring of the total liability of businesspartners using dynamic credit limits. The tasks of a credit managerinclude the final acceptance or refusal of requests (e.g., creditdecisions) and the procurement and management of collateral that reducesthe risk of losses on receivables from business partners.Creditworthiness checks are carried out using internal and externalinformation. The information about the creditworthiness can be providedon request from credit management (CreditWorthinessQuery and Response)or as an unsolicited notification to credit management based on internalcompany rules (CreditWorthinessChangeInformation).

The bases for the creditworthiness checks include credit informationabout business partners provided by information providers(CreditAgencyReportQuery & Response). It also includes information aboutexisting payment obligations of the business partner; this informationcan be obtained actively by Credit Management (CreditCommitmentQuery &Response) or Credit Management receives it, for example, from salesaccording to internal company rules (CreditCommitmentNotification). Italso includes notifications about the payment behavior of businesspartners that Credit Management receives from payment(CreditPaymentBehaviorSummaryNotification).

Credit Management can also provide information internally on requestabout business partners whose creditworthiness is classified as critical(CreditWorthinessCriticalPartiesQuery & Response).

(1) Message Type Credit Payment Behaviour Summary Notification

The interface CreditPaymentBehaviorSummaryNotification assists thesending of information about business partners' payment behavior toCredit Management. Payment sends information about dunning notices, lastpayments, and remaining open items to Credit Management. This enables anoverview of the total payment receivables due to a company from abusiness partner. A CreditPaymentBehaviorSummaryNotification is anotification to Credit Management about the payment behavior (paymentsmade, open items, dunning notices) of a business partner. The messagetype CreditPaymentBehaviorSummaryNotification is based on the messagedata type CreditPaymentBehaviorSummaryMessage.

(2) Credit Payment Behavior Summary Choreography

FIG. 466 shows the message choreography for Credit Payment Behavior. Thefollowing message choreography describes the possible logical sequenceof the messages that can be used to realize the scenario between aFinancial Accounts Receivable server 46600, a Sales or Financials server46602, a Billing System (e.g., Telco Billing System) server 46604, aCredit Management server 46606, and a Credit Agency server 46608.

A CreditCommitmentRecordNofification message 46610 is sent to the CreditManagement server 46606 from the area of the company responsible forsales or financials or from Sales or Financials 46602. ACreditPaymentBehaviorSummaryNofification message 46612 is sent to theCredit Management server 46606 from Financial Accounts Receivable server46600. A CreditWorthinessQuery message 46614 is sent to theCreditManagement server 46606 from the Sales or Financials server 46602.A CreditAgencyReportQuery message 46616 is sent to the CreditAgencyserver 46608 from the Credit Management server 46606. In response, aCreditAgencyReportResponse message 46618 is sent to the CreditManagement server 46606 from the CreditAgency server 46608. ACreditCommitmentQuery message 46620 is sent to the Billing System (e.g.,Telco Billing System) 46604 from CreditManagement server 46606. Inresponse, a CreditCommitmentResponse message 46622 is sent to theCreditManagement server 46606 from the Billing System (e.g., TelcoBilling System) 46604. A CreditWorthinessResponse message 46624 is sentto the Sales or Financials server 46602 from the Credit Managementserver 46606. This is in response to the CreditWorthinessQuery message46614. A CreditWorthinessChangeInformation message 46626 is sent to theSales or Financials server 46602 from the Credit Management server46606. A CreditWorthinessCriticalPartiesQuery message 46628 is sent tothe Credit Management server 46606 from the Sales or Financials server46602. In response, a CreditWorthinessCriticalPartiesResponse message46630 is sent to the Credit Management server 46606 from the Sales orFinancials server 46602. Messages of these types may be transferred atspecific, fixed times or in specific time intervals (for example, oncedaily) according to internal company rules.

(3) Message Data Type Credit Payment Behavior Message

FIG. 467 depicts the data model for theCreditPaymentBehaviorSummaryMessage. TheCreditPaymentBehaviorSummaryMessage package 46700 message data typegroups the business information that is relevant for sending a businessdocument in a message and the CreditPaymentBehaviorSummaryMessage objectin the business document. As shown in FIG. 467,CreditPaymentBehaviorSummaryMessage package 46700 includes aCreditPaymentBehaviorSummaryMessage entity 46702, aBusinessDocumentMessageHeader package 46704, and aCreditPaymentBehaviorSummary package 46706.

(a) Credit Payment Behavior Summary Message

The message data type CreditPaymentBehaviorSummaryMessage provides thestructure for the message type CreditPaymentBehaviorSummaryNotificationand interfaces based on this message type.

(b) Business Document Message Header Package

In one implementation, the BusinessDocumentMessageHeader package 46704is not used, but it can provide intermediate elements needed between theCreditPaymentBehaviorSummaryMessage entity 46702 and theCreditPaymentBehaviorSummary package 46706.

(c) Credit Payment Behavior Summary Package

The CreditPaymentBehaviorSummary package 46706 includes aCreditPaymentBehaviorSummary entity 46708, a Party package 46710, aProductInformation package 46712, and a PaymentInformation package46714.

(i) Credit Payment Behavior Summary Entity

The CreditPaymentBehaviorSummary entity 46708 contains key figuresregarding the payment behavior (e.g., payments made, open items, dunningnotices) of a business partner. The CreditPaymentBehaviorSummary entity46708 can contains several element including a CreditSegmentInternalIDwhich is a proprietary identifier for a credit segment. A credit segmentgroups a company's business transactions from the perspective of creditassignment and control. A credit segment can also be used to monitorbusiness partners' credit limits. A CreditPaymentBehaviourSummaryassigned to a credit segment contains information about the paymentbehavior of a business partner with regard to transactions that belongto this credit segment. The CreditSegmentInternalID is of the GDTCreditSegmentInternalID. There is a 1:1 relationship 46716 between theCreditPaymentBehaviorSummary entity 46708 and theCreditPaymentBehaviorSummaryMessage entity 46702.

The CreditPaymentBehaviorSummary entity 46708 can containDunningCounterValue—number of dunned, outstanding receivables due to theDebtorParty of GDT DunningCounterValue; CumulatedReceivables Amountwhich relates to cumulated receivables total on which interest can becalculated with a fictitious interest rate of GDT Amount.

The CreditPaymentBehaviorSummary entity 46708 can also containDaysOfSalesOutstandingDuration—receivables total measured in days salesof transactions with the DebtorParty. Example: The total of all openitems of a DebtorParty with daily sales of

50,000 is

1,500,000. The value for DaysOfSalesOutstandingDuration is 30 days. TheDaysOfSalesOutstandingDuration can be of GDT Duration, whereby a numberof days can be specified.

The CreditPaymentBehaviorSummary entity 46708 can also containOverdueOpenItemsPercent of GDT Percent which relates to a proportion ofthe amount of all overdue open items to the total amount of all openitems with the DebtorParty; LastTwelveMonthsMaximumCreditExposureAmountof the GDT Amount which relates to a highest exposure total of theDebtorParty in the last twelve months; LastTwelveMonthsSalesVolumeAmountof GDT Amount which relates to sales to the DebtorParty in the lasttwelve months; CollectionAgencySubmittedAmount of GDT Amount whichrelatest to an amount of all debits for the Debtor Party submitted to acollection agency; WithoutDiscountPayments; and WithDiscount Payments.

WithoutDiscountPayments relates to key figures for payments of theDebtorParty where cash discount was either not taken or only partiallytaken (can be a sign of missing liquidity). WithoutDiscountPayments issubdivided into the elements: AverageArrearsDuration of GDT Duration(whereby a number of days can be specified) and which relates to averagepayment arrears for WithoutDiscountPayments; and CurrentYearTotalAmountof GDT Amount which relates to a gross total of items cleared byWithoutDiscountPayments.

WithDiscountPayments relates to key figures for payments of theDebtorParty where maximum possible cash discount was claimed (canindicate sufficient liquidity). WithDiscountPayments is subdivided intothe elements: AverageArrearsDuration of GDT Duraction (whereby a numberof days should be specified) and which relatest o average paymentarrears for WithDiscountPayments; and CurrentYearTotalAmount of GDTAmount which relates to a gross total of items cleared byWithDiscountPayments.

The CreditSegmentInternalID is used when both sender and recipient canaccess shared master data for the credit segment. If this is not thecase, the credit segment must be derived from other elements (forexample, Creditor, Seller, or ProductCategory).

The elements DunningCounterLevel to WithDiscountPayments are optional.However, at least one of these elements or an entity from theCreditPaymentBehaviourSummaryPaymentInformation package must bespecified. A CreditPaymentBehaviourSummary with at least one of thesespecifications is required to provide information that can be evaluatedin Credit Management.

(ii) Party Package

The Party Package 46710 is a summary of information about the partiesrelevant for the notification of information about payment behavior. Itcontains a DebtorParty entity 46718, a CreditorParty entity 46720, and aSellerParty entity 46722.

(a) Debtor Party Entity

The DebtorParty entity 46718 is the party that has to pay a paymentobligation. The DebtorParty entity 46718 is of type GDT:BusinessTransactionDocumentParty. In one implementation, only theelement InternalID is used. There is a 1:1 relationship 46724 betweenthe DebtorParty entity 46718 and the CreditPaymentBehaviorSummary entity46708.

(b) Creditor Party Entity

The CreditorParty entity 46720 is the party that owns a receivable duefrom the DebtorParty entity 46718. The CreditorParty entity 46720 is oftype GDT: BusinessTransactionDocumentParty. In one implementation, onlythe element InternalID is used. The CreditorParty entity 46720determines the credit segment and, in one implementation, is notrequired if the credit segment is specified via theCreditSegmentInternalID or determined from the ProductCategory. There isa 1:c relationship 46726 between the CreditorParty entity 46720 and theCreditPaymentBehaviorSummary entity 46708.

(c) Seller Party Entity

The SellerParty entity 46722 is the party that has sold a product to theDebtorParty entity 46718. The SellerParty entity 46722 is of type GDT:BusinessTransactionDocumentParty; only the element InternalID is used.The SellerParty entity 46722 determines the credit segment and, in oneimplementation, is not required if the credit segment is specified viathe CreditSegmentInternalID or determined from the ProductCategory.There is a 1:c relationship 46728 between the SellerParty entity 46722and the CreditPaymentBehaviorSummary entity 46708.

(iii) Product Information Package

The ProductInformation package 46712 is a summary of information aboutthe product sold to the DebtorParty entity 46718. It contains aProductCategory entity 46730.

(a) Product Category Entity

The ProductCategory entity 46730 is the product category of the productsold to the DebtorParty entity 46718. ProductCategory entity 46730 is oftype GDT: BusinessTransactionDocumentProductCategory. In oneimplementation, only the element InternalID is used. The ProductCategoryentity 46730 determines the credit segment and, in one implementation,is not required if the credit segment is specified via theCreditSegmentInternalID or determined using the CreditorParty entity46720 or SellerParty entity 46722. There is a 1:c relationship 46732between the ProductCategory entity 46730 and theCreditPaymentBehaviorSummary entity 46708.

(iv) Payment Information Package

The PaymentInformation package 46714 summarizes information about thepayment behavior of a DebtorParty entity 46714. The PaymentInformationpackage 46714 contains a LastPayment entity 46734, an OldestOpenItementity 46736, and a MaximumLeveIDunnedOpenItem entity 46738. In one ofimplementation, at least one entity or one of the elements from theCreditPaymentBehaviorSummary package 46706 listed above is specified.

(a) Last Payment Entity

The LastPayment entity 46734 is the last payment received from aDebtorParty entity 46718. The LastPayment entity 46734 contains an ID,an identifier, of type GDT: BusinessTransactionDocumentID, and anAmount, a payment amount, of type GDT: Amount. It also contains a Date,a date of payment, of type GDT: Date. There is a 1:c relationship 46740between the LastPayment entity 46734 and theCreditPaymentBehaviorSummary entity 46708.

(b) Oldest Open Item Entity

The OldestOpenItem entity 46736 is a specification of the oldest openitem of a DebtorParty entity 46718. The OldestOpenItem entity 46736contains an AccountingDocumentID, an identifier of theAccountingDocument, of type GDT: BusinessTransactionDocumentID. It alsocontains an AccountingDocumentItemID, an identifier of the line itemwithin the AccountingDocument, of type GDT:BusinessTransactionDocumentItemID. It further contains an Amount, anopen amount of the oldest open item, of type GDT: Amount. Itadditionally contains an OverdueNetDate, a due date for net payment, oftype GDT: Date. An open item is an outstanding receivable. There is a1:c relationship 46742 between the OldestOpenItem entity 46736 and theCreditPaymentBehaviorSummary entity 46708.

(c) Maximum Level Dunned Open Item Entity

The MaximumLeveIDunnedOpenItem entity 46738 is the specification of theopen item of the DebtorParty entity 46718 with the highest dunninglevel. The MaximumLeveIDunnedopenItem entity 46738 contains anAccountingDocumentID, an identifier of the AccountingDocument, of typeGDT: BusinessTransactionDocumentID. It contains anAccountingDocumentlternID of type GDT: BusinessTransactionDocumentItemIDwhich is an identifier of the line item within the AccountingDocument.It further contains an Amount, an amount of the open item with thehighest dunning level, of type GDT: Amount. It also includes aMaximumLeveIDunningDate, a date on which the open item with the highestdunning level was last dunned, of type GDT: Date. It additionallycontains a DunningLevelValue, a dunning level of the open item with thehighest dunning level, of type GDT: DunningLevelValue. There is a 1:crelationship 46744 between the MaximumLeveIDunnedOpenItem entity 46738and the CreditPaymentBehaviorSummary entity 46708.

(d) Element Structure of Credit Payment Behaviour Summary Message

The message data type element structure for theCreditPaymentBehaviourSummaryMessage message is depicted in FIG. 468.The element structure is similar to the data model, but providesadditional information regarding the details of the interface. Theelement structure identifies the different packages 46800 in theinterface, and represents the entities at various levels within theinterface. As depicted in FIG. 468, the interface forCreditPaymentBehaviourSummaryMessage includes five levels 46802, 46804,46806, 46808, and 46810. The outermost package of this interface is aCreditPaymentBehaviourSummaryMessage package 46816, which includes aCreditPaymentBehaviourSummaryMessage entity 46818 at the first level46802. The CreditPaymentBehaviourSummaryMessage entity 46818 is of atype MDT 46822 “CreditPaymentBehaviourSummaryMessage” 46824. There isone 46820 CreditPaymentBehaviourSummaryMessage entity 46818 for eachCreditPaymentBehaviourSummaryMessage package 46816.

The CreditPaymentBehaviourSummaryMessage package 46816 includes aCreditPaymentBehaviourSummary package 46826. TheCreditPaymentBehaviourSummary package 46826 includes aCreditPaymentBehaviourSummary entity 46828 at the second level 46804, aParty package 46842, a ProductInformation package 46892, and aPaymentInformation package 468110.

The CreditPaymentBehaviourSummary entity 46828 has a data type name“CreditPaymentBehaviourSummary” 46832, and there is one 46830CreditPaymentBehaviourSummary entity 46828 for eachCreditPaymentBehaviourSummary package 46826. TheCreditPaymentBehaviourSummary entity 46828 includes aCreditSegmentInternalID entity 46834 at the third level 46806. TheCreditSegmentInternalID entity 46834 is of a type GDT 46838“CreditSegmentInternalID” 46840, and there is zero or one 46836CreditSegmentInternalID entity 46834 for a CreditPaymentBehaviourSummaryentity 46828.

The Party package 46842 includes a DebtorParty entity 46844, aCreditorParty entity 46860, and a SellerParty entity 46876 at the thirdlevel 46804. The DebtorParty entity 46844 is of a type GDT 46848“BusinessTransactionDocumentParty” 46850, and there is one 46846DebtorParty entity 46844 for each Party package 46842. The DebtorPartyentity 46844 includes an InternalID entity 46852 at the fourth level46808. The InternalID entity 46852 is of a type GDT 46856“PartyInternalID” 46858, and there is one 46854 InternalID entity 46852for a DebtorParty entity 46844.

The CreditorParty entity 46860 is of a type GDT 46864“BusinessTransactionDocumentParty” 46866, and there is zero or one 46862CreditorParty entity 46860 for each Party package 46842. TheCreditorParty entity 46860 includes an InternalID entity 46868 at thefourth level 46808. The InternalID entity 46868 is of a type GDT 46872“PartyInternalID” 46874, and there is one 46870 InternalID entity 46868for a CreditorParty entity 46860.

The SellerParty entity 46876 is of a type GDT 46880“BusinessTransactionDocumentParty” 46882, and there is zero or one 46878SellerParty entity 46876 for each Party package 46842. The SellerPartyentity 46876 includes an InternalID entity 46884 at the fourth level46808. The InternalID entity 46884 is of a type GDT 46888“PartyInternalID” 46890, and there is one 46886 InternalID entity 46884for a SellerParty entity 46876.

The ProductInformation package 46892 includes a ProductCategory entity46894. The ProductCategory entity 46894 is of a type GDT 46898“BusinessTransactionDocumentProductCategory” 468100, and there is zeroor one 46896 ProductCategory entity 46894 for each ProductInformationpackage 46892. The ProductCategory entity 46894 includes an InternalIDentity 468102 at the fourth level 46808. The InternalID entity 468102 isof a type GDT 468106 “ProductCategoryInternalID” 468108, and there isone 468104 InternalID entity 468102 for a ProductCategory entity 46894.

The PaymentInformation package 468110 includes a LastPayment entity468112, an OldestOpenItem entity 468142, a MeximumLeveIDunnedOpenItementity 468180, a DunningCounterValue entity 468226, aCumulatedReceivablesAmount entity 468234, aDaysofSalesOutstandingDuration entity 468242, an OverdueOpenItemsPercententity 468250, a LastTwelveMonthsMaximumCreditExposureAmount entity468258, a LastTwelveMonthsSalesVolumeAmount entity 468266, aCollectionAgencySubmittedAmount 468274, a WithoutDiscountPayments entity468282, and a WithDiscountPayments entity 468304.

The LastPayment entity 468112 has a data type name“CreditPaymentBehaviourSummaryLastPayment” 468116, and there is zero orone 468114 LastPayment entity 468112 for each PaymentInformation package468110. The LastPayment entity 468112 includes an ID entity 468118, anAmount entity 468126, and a Date entity 468134 at the fourth level46808. The ID entity 468118 is of a type GDT 468122“BusinessTransactionDocumentID” 468124, and there is one 468120 IDentity 468118 for a LastPayment entity 468112. The Amount entity 468126is of a type GDT 468130 “Amount” 468132, and there is one 468128 Amountentity 468126 for a LastPayment entity 468112. The Date entity 468134 isof a type GDT 468138 “Date” 468140, and there is one 468136 Date entity468134 for a LastPayment entity 468112.

The OldestOpenItem entity 468142 has a data type name“CreditPaymentBehaviourSummaryOldestOpenItem” 468146, and there is zeroor one 468144 OldestOpenItem entity 468142 for each PaymentInformationpackage 468110. The OldestOpenItem entity 468142 includes anAccountingDocumentID entity 468148, an AccountingDocumentItemID entity468156, an Amount entity 468164, and an OverdueNetDate entity 468172 atthe fourth level 46808. The AccountingDocumentID entity 468148 is of atype GDT 468152 “BusinessTransactionDocumentID” 468154, and there is one468150 AccountingDocumentID entity 468148 for an OldestOpenItem entity468142. The AccountingDocumentItemID entity 468156 is of a type GDT468160 “BusinessTransactionDocumentItemID” 468162, and there is one468158 AccountingDocumentItemID entity 468156 for an OldestOpenItementity 468142. The Amount entity 468164 is of a type GDT 468168 “Amount”468170, and there is one 468166 Amount entity 468164 for anOldestOpenItem entity 468142. The OverdueNetDate entity 468172 is of atype GDT 468176 “Date” 468178, and there is one 468174 OverdueNetDateentity 468172 for an OldestOpenItem entity 468142.

The MaximumLeveIDunnedOpenItem entity 468180 has a data type name“CreditPaymentBehaviourSummaryMaximumLevelDunnedOpenItem” 468184, andthere is zero or one 468182 MaximumLevelDunnedOpenItem entity 468180 foreach PaymentInformation package 468110. The MaximumLeveIDunnedOpenItementity 468180 includes an AccountingDocumentID entity 468186, anAccountingDocumentItemID entity 468194, an Amount entity 468202, aMaximumLeveIDunningDate entity 468210, and a DunningLevelValue entity468218 at the fourth level 46808. The AccountingDocumentID entity 468186is of a type GDT 468190 “BusinessTransactionDocumentID” 468192, andthere is one 468188 AccountingDocumentID entity 468186 for aMaximumLeveIDunnedOpenItem entity 468180. The AccountingDocumentItemIDentity 468194 is of a type GDT 468198“BusinessTransactionDocumentItemID” 468200, and there is one 468196AccountingDocumentItemID entity 468194 for a MaximumLeveIDunnedOpenItementity 468180. The Amount entity 468202 is of a type GDT 468206 “Amount”468208, and there is one 468204 Amount entity 468202 for aMaximumLeveIDunnedOpenItem entity 468180. The MaximumLeveIDunningDateentity 468210 is of a type GDT 468214 “Date” 468216, and there is one468212 MaximumLeveIDunningDate entity 468210 for aMaximumLeveIDunnedOpenItem entity 468180. The DunningLevelValue entity468218 is of a type GDT 468222 “DunningLevelValue” 468224, and there isone 468220 DunningLevelValue entity 468218 for aMaximumLeveIDunnedOpenItem entity 468180.

The DunningCounterValue entity 468226 is of a type GDT 468230“DunningCounterValue” 468232, and there is zero or one 468228DunningCounterValue entity 468226 for each PaymentInformation package468110. The CumulatedReceivablesAmount entity 468234 is of a type GDT468238 “Amount” 468240, and there is zero or one 468236CumulatedReceivablesAmount entity 468234 for each PaymentInformationpackage 468110. The DaysOfSalesOutstandingDuration entity 468242 is of atype GDT 468246 “Duration” 468248, and there is zero or one 468244DaysOfSalesOutstandingDuration entity 468242 for each PaymentInformationpackage 468110. The OverdueOpenItemsPercent entity 468250 is of a typeGDT 468254 “Percent” 468256, and there is zero or one 468252OverdueOpenItemsPercent entity 468250 for each PaymentInformationpackage 468110.

The LastTwelveMonthsMaximumCreditExposureAmount entity 468258 is of atype GDT 468262 “Amount” 468264, and there is zero or one 468260LastTwelveMonthsMaximumCreditExposureAmount entity 468258 for eachPaymentInformation package 468110.

The LastTwelveMonthsSalesVolumeAmount entity 468266 is of a type GDT468270 “Amount” 468272, and there is zero or one 468268LastTwelveMonthsSalesVolumeAmount entity 468266 for eachPaymentInformation package 468110.

The CollectionAgencySubmittedAmount entity 468274 is of a type GDT468278 “Amount” 468280, and there is zero or one 468276CollectionAgencySubmittedAmount entity 468274 for eachPaymentInformation package 468110.

The WithoutDiscountPayments entity 468282 has a data type name“CreditPaymentBehaviourSummaryPayments” 468286, and there is zero or one468284 WithoutDiscountPayments entity 468282 for each PaymentInformationpackage 468110. The WithoutDiscountPayments entity 468282 includes anAverageArrearsDuration entity 468288 and a CurrentYearTotalAmount entity468296 at the fourth level 46808. The AverageArrearsDuration entity468288 is of a type GDT 468292 “Duration” 468294, and there is one468290 AverageArrearsDuration entity 468288 for aWithoutDiscountPayments entity 468282. The CurrentYearTotalAmount entity468296 is of a type GDT 468300 “Amount” 468302, and there is one 468298CurrentYearTotalAmount entity 468296 for a WithoutDiscountPaymentsentity 468282.

The WithDiscountPayments entity 468304 has a data type name“CreditPaymentBehaviourSummaryPayments” 468308, and there is zero or one468306 WithDiscountPayments entity 468304 for each PaymentInformationpackage 468110. The WithDiscountPayments entity 468304 includes anAverageArrearsDuration entity 468310 and a CurrentYearTotalAmount entity468318 at the fourth level 46808. The AverageArrearsDuration entity468310 is of a type GDT 468314 “Duration” 468316, and there is one468312 AverageArrearsDuration entity 468310 for a WithDiscountPaymentsentity 468304. The CurrentYearTotalAmount entity 468318 is of a type GDT468322 “Amount” 468324, and there is one 468320 CurrentYearTotalAmountentity 468318 for a WithDiscountPayments entity 468304.

ii) CustomsVendorDeclaration Interface

CustomsVendorDeclaration interfaces are used to exchange vendordeclarations in an A2A process between a buyer and a vendor. The vendorsguarantee their customers in a vendor declaration that the goodsdelivered are originating products eligible for preference according tothe agreements concluded with the individual countries. These vendordeclarations are required for preference processing (that is forreceiving preferential customs treatment).

In customs procedures and foreign trade the origin of the goods is ofconsiderable importance. The origin of the goods determines, among otherthings, which duties are levied or which trade regulations are applied.

In customs law, preferential measures represent preference processingfor goods from specific countries and customs territories. Thispreference processing consists of the use of particular customs dutyrates (preferential customs duty rates) for the import of goods. The useof customs tariff preferences is based on a large number of preferenceagreements concluded by countries or country groups and the autonomouspreference policies that countries or country groups apply unilaterallyin favor of specific countries, country groups (for example developingcountries) or customs territories.

Preference processing is not merely granted on the grounds that thegoods originate in the respective countries or the EU. Only goods whichfulfill the respective specified prerequisites are eligible forpreferences.

The CustomsVendorDeclaration is motivated by the business scenarioPreference Processing. Most vendor declarations are currently sent ashard copies. The contained data or preference statement must then bemaintained manually in the systems. Since vendor declarations can bevery long (often more than a hundred pages for large companies) thismanual maintenance means a lot of work.

With the business scenario Preference Processing, an ERP system providesinformation on vendor product relationships to SAP Risk ManagementPreference Processing. SAP GTS creates a worklist with this informationso that it can be used for further processing. From the worklist, thesystem selects the products with their associated vendor master data forwhich vendor declarations do not exist.

The buyers send a CustomsVendorDeclarationCompleteRequest message forthe selected products to their vendors. Most parts of the vendordeclaration for the individual products are already filled out.

The vendor adds the preference status to the vendor declaration and,where necessary, additional information on the product and sends it backto the buyer using the CustomsVendorDeclarationNotification message.Next, the buyer determines if there is a valid vendor declaration for aproduct and aggregates the valid, invalid and missing vendordeclarations. A threshold value is then determined by performingpreference determination. During this process, the statements for everymaterial are combined based on the rules and procedures in thepreference agreements, irrespective of whether there are any valid orinvalid vendor declarations. The results of the preference determinationare saved, so that it is possible to continue monitoring them with audittrails and the Monitoring function.

Whenever an order or a billing document is created or changed in the ERPsystem, the system compares the threshold value with the factory priceof the order item or the billing document. If the product is eligiblefor preferential treatment, the system sets the preference indicator. Onthe basis of this indicator the buyer can in turn issue vendordeclarations for customers.

(1) Message Categories

A customs tariff preference is preferential treatment for the customsduty rates (reduced customs duty rates or duty free) of goods fromspecific countries or customs territories. The customs tariffpreferences are defined in international preference agreements orautonomous national preference policies.

A vendor declaration is a legally binding declaration of a vendorconcerning the goods delivered to a buyer, which allows the buyer toclaim customs tariff preferences. A vendor declaration can be made inthe form of an individual declaration for an individual delivery or as along-term declaration that is, in general, valid for one year.

(i) CustomsVendorDeclaration CompleteRequest

A CustomsVendorDeclarationCompleteRequest is a request a buyer makes toa vendor to complete a long-term vendor declaration for customspurposes. The structure of the message categoryCustomsVendorDeclarationCompleteRequest is defined by the message datatype CustomsVendorDeclarationMessage. TheCustomsVendorDeclarationCompleteRequest is not required if a completeCustomsVendorDeclaration exists or has been sent (using theCustomsVendorDeclarationNotification).

(ii) CustomsVendorDeclarationNotification

A CustomsVendorDeclarationNotification is a notification from a vendorto inform a buyer of a long-term vendor declaration for customspurposes. A vendor declaration refers to goods that are delivered fromthe vendor to the buyer. The structure of the message categoryCustomsVendorDeclarationNotification is specified by the message datatype CustomsVendorDeclarationMessage.

(2) Message Choreography

The following message choreography (see FIG. 469) describes the possiblelogical sequence of the messages that can be used to realize thescenario between a Buyer 46900 and a Vendor 46902.

For products for which no vendor declarations exist, the Buyer 46900 cansend a CustomsVendorDeclarationCompleteRequest message 46904 (which ispre-filled as far as possible) to the Vendor 46902. The Vendor 46902 canadd the vendor declaration and send it back to the Buyer 46900 using aCustomsVendorDeclarationNotification message 46906. When processing theCustomsVendorDeclarationNotification message 46906, the validity periodresets the validity period of the information that might exist from aprevious message.

During the request process, the request ID is used to relate theindividual messages to each other. This means that theCustomsVendorDeclarationCompleteRequest message 46904 receives its ownID in the MessageHeader. The CustomsVendorDeclarationNotificationmessage 46906 refers to the request message using the ReferenceID.

Transmission errors are handled by the infrastructure (message broker).A receiver system accepts inbound messages that are formally correct.Problems regarding the content are solved on the receiver side.

(3) Data Model of Customs Vendor Declaration Message

FIG. 470 depicts the data model for the CustomsVendorDeclarationMessage.The CustomsVendorDeclarationMessage package 47000 message data typegroups together the business information that is relevant for sending abusiness document in a message and the CustomsVendorDeclaration objectin the business document. The CustomsVendorDeclarationMessage package47000 includes a CustomsVendorDeclarationMessage entity 47002, aMessageHeader package 47004, and a CustomsVendorDeclaration package47006.

(i) Message Header Package

A MessageHeader package 47004 groups the business information that isrelevant for sending a business document in a message. It includes aMessageHeader entity 47008.

(a) Message Header Entity

The MessageHeader entity 45008 is of type GDT:BusinessDocumentMessageHeader. There is a 1:1 relationship 45010 betweenthe MessageHeader entity 47008 and CustomsVendorDeclarationMessageentity 47002. The MessageHeader entity 47008 includes an ID entity and aCreationDateTime entity.

(ii) Customs Vendor Declaration Package

The CustomsVendorDeclaration package 47006 groups together aCustomsVendorDeclaration entity 47012, a Party package 47014, anAttachment package 47016, and an Item package 47018.

(a) Customs Vendor Declaration Entity

The CustomsVendorDeclaration entity 47012 is the legally bindingdeclaration of the vendors concerning the goods they delivered to abuyer which allows the buyer to claim customs tariff preferences. Avendor declaration can be made as an individual declaration for anindividual delivery or as a long-term declaration that is, in general,valid for one year.

There is a 1:1 relationship 47020 between the CustomsVendorDeclarationentity 47012 and the CustomsVendorDeclarationMessage entity 47002. TheCustomsVendorDeclaration entity 47012 includes: an ID, a Buyer ID, and aCreation Date. The ID is a unique identifier of theCustomsVendorDeclaration assigned by the vendor, and it is of type GDT:BusinessTransactionDocumentID. The BuyerID is a unique identifier of theCustomsVendorDeclaration assigned by the buyer, and it is of type GDT:BusinessTransactionDocumentID. The CreationDate is a creation date ofthe CustomsVendorDeclaration, and it is of type GDT: Date.

(iii) Party Package

The Party package 47014 groups the parties of a vendor declaration. Itincludes a VendorParty entity 47022 and a BuyerParty entity 47024.

(a) Vendor Party Entity

The VendorParty entity 47022 is the party that issues a vendordeclaration for a product they must deliver. The VendorParty entity47022 is of type GDT: BusinessTransactionDocumentParty. There is a 1:1relationship 47026 between the VendorParty entity 47022 and theCustomsVendorDeclaration entity 47012.

(b) Buyer Party Entity

The BuyerParty entity 47024 is the party that requires a vendordeclaration for a product they are going to buy. The BuyerParty entity47024 is of type GDT: BusinessTransactionDocumentParty. There is a 1:1relationship 47028 between the BuyerParty entity 47024 and theCustomsVendorDeclaration entity 47012.

(iv) Attachment Package

The Attachment package 47016 groups the all relevant attachments withreference to the CustomsVendorDeclaration entity 47012. The Attachmentpackage 47016 contains the Attachment entity 47030.

(a) Attachment Entity

The Attachment entity 47030 is any type of document that refers to theCustomsVendorDeclaration entity 47012. The Attachment entity 47030 is oftype GDT: Attachment. There is a 1:cn relationship 47032 betweenAttachment entity 47030 and the CustomsVendorDeclaration entity 47012.

(v) Item Package

The Item package 47018 is the summary of the specifications that vendorsmake in the CustomsVendorDeclaration entity 47012 on a product theydeliver. The Item package 47018 groups an Item entity 47034, aProductInformation package 47036, and a CustomsInformation package47038.

(a) Item Entity

The Item entity 47034 can include the following elements: a validityperiod, a preferential origin country code (i.e., the country of originof the product) and a customs commodity classification code. The countrycode may be the country where the last processing decisive fordetermining the origin of the product in the sense of the rules oforigin occurred. The rules of origin determine under which conditions aproduct receives its origin in the respective country. Which processesshould be regarded as sufficient, is fixed for the preferential customsterritory in the respective processing lists (lists the processes thatmust be carried out for the non-originating materials withoutoriginating status to confer originating status to the manufacturedproducts). The preferential origin country code is of type GDT:CountryCode. The customs commodity classification code represents thecustoms classification of trading goods in a CustomsVendorDeclaration,and is of type GDT: Cus-tomsCommodityClassificationCode. There is a 1:cnrelationship 47040 between the Item entity 47034 and theCustomsVendorDeclaration entity 47012.

(vi) Product Information Package

The ProductInformation package 47036 groups product information for theCustomsVendorDeclaration entity 47012. It includes a Product entity47042.

(a) Product Entity

The Product entity 47042 contains information on the product provided bythe vendor in the CustomsVendorDeclaration entity 47012. The Productentity 47042 is of type GDT: BusinessTransactionDocumentProduct. Thereis a 1:1 relationship 47044 between the Product entity 47042 and theItem entity 47034.

(vii) Customs Information Package

The CustomsInformation package 47038 groups customs information which isrelevant in a CustomsVendorDeclaration entity 47012. It includes aPreferentialStatement entity 47046 and aNonPreferentialProductConstituent entity 47048.

(a) Preferential Statement Entity

The PreferentialStatement entity 47046 is the legally binding statementof vendors on goods they have delivered, which allows the buyer to claimcustoms tariff preferences for these goods. The PreferentialStatemententity 47046 can include: a StatusCode which is a coded representationof the status of a PreferentialStatement, and is of type GDT:CustomsPreferentialStatementStatusCode; and a DestinationCountryCode,which is a country of destination of the product. The country is of typeGDT: CountryCode. There is a 1:cn relationship 47050 between thePreferentialStatement entity 47046 and the Item entity 47034. Forproducts, a PreferentialStatement entity 47046 may be specified percountry of origin and destination.

(b) Non-Preferential Product Constituent Entity

The NonPreferentialProductConstituent entity 47048 is a specification onparts or precursor materials of a product for which no customs tariffpreferences can be claimed. The NonPreferentialProductConstituent entity47048 can include: an ID, which is a sequential number of aNonPreferentialProductConstituent entity 47048, and has a type of GDT:Identifier; a CustomsCommodityClassificationCode, which is a codedrepresentation of the customs classification of aNonPreferentialProductConstituent entity 47048, and has a type of GDT:CustomsCommodityClassificationCode; and an amount which is a value ofthe NonPreferentialProductConstituent entity 47048, and has a type ofGDT: Amount. There is a 1:cn relationship 47052 between theNonPreferentialProductConstituent entity 47048 and the Item entity47034.

(4) Element Structure of Customs Vendor Declaration Message

The message data type element structure for theCustomsVendorDeclarationMessage is depicted in FIG. 471. The elementstructure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 47100 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 471, the interface for CustomsVendorDeclarationMessageincludes six levels 47102, 47104, 47106, 47108, 47110 and 47112. Theoutermost package 47100 of this interface is aCustomsVendorDeclarationMessage package 47118, which includes aCustomsVendorDeclarationMessage entity 47120 at the first level 47102, aMessageHeader package 47126, and an CustomsVendorDeclaration package47160. The CustomsVendorDeclarationMessage entity 47120 is of a type MDT47122 “CustomsVendorDeclarationMessage” 47124.

The MessageHeader package 47126 includes a MessageHeader entity 47128 atthe second level 47104. The MessageHeader 47128 is of a type GDT 47132BusinessDocumentMessageHeader 47134, and there is one 47130MessageHeader entity 47128 for each MessageHeader 47126.

The MessageHeader entity 47128 includes an ID 47136, ReferenceID 47144,and CreationDateTime 47152 at the third level 47106. The ID 47136 is ofa type GDT 47140 “BusinessDocumentMessageID” 47142, and there is one47138 ID 47136 for a MessageHeader 47128. The ReferenceID 47144 is of atype GDT 47148 “BusinessDocumentMessageID” 47150, and there is zero orone 47146 ReferenceID 47144 for a MessageHeader 47128. TheCreationDateTime 47152 is of a type GDT 47156 “DateTime” 471058, andthere is one 47154 CreationDateTime 47152 for each MessageHeader 47128.

The CustomsVendorDeclaration package 47160 includes aCustomsVendorDeclartion entity 47162 at the second level 47104, a Partypackage 47194, an Attachment package 47108B, and an Item package 47118B.The CustomsVendorDeclaration entity 47162 is a “CustomsVendorDeclartion”47168, and there is one 47164 CustomesVendorDeclaration entity 47162 foreach CustomsVendorDeclaration package 47160.

The CustomsVendorDeclaration 47162 includes an ID 47170, BuyerID 47178,CreationDate 47186, and BuyerParty 47196 at the third level 47106. TheID 47170 is of a type GDT 47174 “BusinessTransactionDocumentID” 47176,and there is zero or one 47172 ID 47170 for eachCustomsVendorDeclaration 47162. The BuyerID 47178 is of type GDT 47182“BusinessTransactionDocumentID 47184, and there is zero or one 47180BuyerID 47178 for each CustomesVendorDeclaration 47162. The CreationDate47186 is of a type GDT 47190 “Date” 47192, and there is one 47188CreationDate 47186 for each CustomsVendorDeclaration 47162.

The Party package 47194 includes a BuyerParty 47196 and a VendorParty47152A at the third level 47106. The BuyerParty 47196 is of a type GDT47100A “BusinessTransactionDocumentParty” CC002A, and there is one 47198BuyerParty 47196 for each Party 47194.

The Buyer Party 47196 includes an InternalID 47104A, BuyerID47112A,VendorID 47120A, Address 47128A and CotactPerson CC36A at the fourthlevel 47108. The InternalID 47104A is of a type GDT 47108A“PartyInternalID” 47110A, and there is zero or one 47106A InternalID47104A for each BuyerParty 47196. The BuyerID 47112A is of a type GDT47116A “PartyPartyID” 47118A, and there is zero or one 47114A BuyerID47112A for each BuyerParty 47196. The VendorID 47120A is of a type GDT47124A “PartyPartyID” 47126A, and there is zero or one 47122A VendorID47120A for each BuyerParty 47196. The Address 47128A is of a type GDT47132A “Address” 47134A, and there is one Address 47128A for eachBuyerParty 47196. The ContactPerson 47136A is of a type GDT 47140A“ContactPerson” 4714A, and there is zero or one 47138A ContactPerson47136A for each BuyerParty 47196.

The ContactPerson 47136A includes an Address 47144A at the fifth level47110. The Address 47144A is of a type GDT 47148A “Address” 47150A, andthere is one 47146A Address 47144A for each Contact Person 47136A.

The VendorParty 47152A is of a type GDT 47156A“BusinessTransactionDocumentParty” 47158A, and there is one 47154A foreach Party 47194. The VendorParty 47152A includes an InternalID 47160A,a BuyerID 47168A, a VendorID 47176A, an Address 47184A, and aContactPerson 47192A at the fourth level 47108. The InteralID 47160A isof a type GDT 47164A “PartylnteralID” 47166A, and there is zero or one47162A InternalID 47160A for each VendorParty 47152A. The BuyerID 47168Ais of a type GDT 47172A “PartyPartyID” 47174A, and there is zero or one47170A BuyerID 47168A for each VendorParty 47152A. The VendorID 47176Ais of a type GDT 47180A “PartyPartID” 47182A, and there is zero or one47178A for each VendorParty 47152A. The Address 47184A is of a type GDT47188A “Address” 47190A, and there is one 47186A for each VendorParty47152A.

The ContactPerson 47192A is of a type GDT 47196A “ContactPerson” 47198A,and there is zero or one 47194A ContactPerson 47192A for eachVendorParty 47152A. The ContactPerson 47192A includes an Address 471000Bat the fifth level 47110. The Address 47100B is of type GDT 47104B“Address” 47106B, and there is one 47102B Address 47100B for eachContact Person 47192A.

The Attachment package 47108B includes an Attachment entity 47110B atthe third level 47106. The Attachment entity 47110B is at the type GDT47114B “Attachment” 47116B, and there is any number of 47112B Attachmententities 47110B for each Attachment package 47108B.

The Item package 47118B includes an Item entity 47120B at the thirdlevel 47106, a ProductInformation 47152B package, and aCustomsInformation 47194B package. The Item entity 47120B is of type“CustomsVendorDeclarationItem” 47126B, and there is any number of 47122BItem entities 47120B for each Item package 47118B.

The Item entity 47120B includes a ValidityPeriod 47128B, aPreferentialOriginCountryCode 47136B, and aCustomsCommodityClassificationCode 47144B at the fourth level 47108. TheValidityPeriod 47128B is of a type GDT 47132B “DatePeriod” 47134B, andthere is one CC30B ValidityPeriod 47128B for each Item 47120B. ThePreferentialOriginCountryCode 47136B is of a type GDT 47140B“CountryCode” 47142B, and there is zero or one 47138B for each Item47120B. The CustomsCommodityClassificationCode 47144B is of a type GDT47148B “CustomsCommodityClassificationCode” 47150B, and there is zero orone 47146B CustomsCommodityClassificafionCode 47144B for each Item47120B.

The ProductInformation package 47152B includes a Product 47154B at thefourth level 47108. The Product 47154B is of a type GDT 47158B“BusinessTransactionDocumentProduct” 47160B, and there is one 47156BProduct 47154B for each Productlnformafion 47152B. The Product 47154Bincludes an InternalID 47152B, a BuyerID 47170B, a VendorID 47178B, anda Note 47186B at the fifth level 47110. The InternalID 47162B is of atype GDT 47166B “ProductlnteralID” 47168B, and there is zero or one47164B for each Product 47154B. The BuyerID 47170B is of a type GDTCC74B “ProductPartyID” 47176B, and there is zero or one 47172B BuyerID47170B for each Product 47154B. The VendorID 47178B is of a type GDT47182B “ProductPartyID” 47184B, and there is zero or one 47180B VendorIDCC78B for each Product 47154B. The Note 47186B is of a type GDT 47190B“Note” 47192B, and there is zero or one 47188B Note 47186B for eachProduct 47154B.

The CustomsInformation package 47194B includes a PreferentialStatement47196B at the fourth level 47108. The PreferentialStatement 47196B is ofa type “CustomsVendorDeclarationItemPreferentialStatement” 47102C, andthere is any number of 47198B PreferentialStatement 47196B for eachCustomsInformation 47194B.

The PreferentialStatement 47196B includes a StatusCode 47104C,DestinationCountryCode 47112C, and NonPreferenetialCommodityConstituent47122C at the fifth level 47110. The StatusCode 47104C is of a type GDT47108C “CustomPreferentalStatementStatusCode” 47110C, and there is zeroor one 47106C StatusCode 47104C for each PreferentialStaement 47196B.The DestinationCountryCode 47112C is of a type GDT 47116C “CountryCode”47118C, and there is one 47114C for each DestinationCountryCode 47112C.The NonPreferentialCommodityConstituent 47122C is of a type“CustomsVendorDeclarationItemPreferentialStatementNonPreferentialProductConstitutent”47128C, and there is any number of NonPreferentialCommodityConstiturent47122C for each PreferenetialStaement 47196B. TheNonPreferentialCommodityConstituent 47122C includes an ID 47130C,CustomesCommodityClassificationCode 47138C, and Amount 47146C entitiesat the sixth level 47112. The ID 47130C is of a type CCT 47134C“Identifier” 47136C, and there is one 47132C ID 47130C for eachNonPreferentialCommodityConstituent 47122C. TheCustomsCommodityClasifiecationCode 47138C is of a type GDT 47142C“CustomsCommodityClassificationCode 47144C, and there is one 47140CCustomsCommodityClassificationCode 47138C for eachNonPreferentialCommodityConstituent 47122C. The Amount 47146C is of atype GDT 47150C “Amount” 47152C, and there is one 47148C Amount 47146Cfor each NonPreferentialCommodityConstituent 47122C.

jj) Invoice Interfaces

The interfaces InvoiceRequest and InvoiceConfirmation exchange invoicesand invoice confirmations between an invoicing party and an invoicerecipient (e.g. between a seller and a buyer) in a B2B process. TheInvoiceInformation message is used to inform interested applications ofreceived, verified, and accepted invoices and of cancellations of theseinvoices. The InvoiceSettlementReleaseRequest message is used to requestthe release of an invoice for settlement.

In some implementations, companies can create invoices in electronic aswell as in paper form. Traditional methods of communication, such asmail or fax, for invoicing are cost intensive, prone to error, andrelatively slow, since the data must be recorded manually. Electroniccommunication eliminates such problems.

The motivating business scenarios for the Invoice Request and InvoiceConfirmation messages are the Procure to Stock (PTS) and Sell from Stock(SFS) scenarios. In the PTS scenario, goods are purchased and settledusing the invoice interfaces. In the PTS scenario, goods are sold andinvoiced using the invoice interfaces.

The InvoiceRequest and InvoiceConfirmation messages directly integratethe applications implementing these interfaces, and also form the basisfor mapping data to widely-used XML standard formats such as RosettaNet,PIDX (Petroleum Industry Data Exchange), xCBL (XML Common BusinessLibrary), and CIDX (Chemical Industry Data Exchange).

The SupplierInvoiceInformation, SupplierInvoiceSettlementReleaseRequestand SupplierInvoiceCancellationExecutionRequest messages are motivatedby the Leasing business scenario.

Leasing is a business process that involves three parties: the lessee,lessor, and vendor. In this business process, a vendor provides thelessee with a certain item in return for a payment. The financing forthis item is handled by the lessor as an intermediate party.

The details of the leasing process are as follows. A leasing contract isconcluded between the lessor and lessee. The lessor orders the relevantproduct from the vendor. The vendor then delivers this product to thelessor and issues an invoice to the lessor. The lessor does not settlethis invoice until he or she has received advance payments (for example,the first installments) from the lessee, as agreed in the leasingcontract.

Since the leasing contract is usually modeled in the lessor's salessystem, this system first has to be informed by Invoicing that thevendor's invoice has been verified and accepted (InvoiceInformation)before it can request that the invoice be released for settlement(InvoiceSettlementReleaseRequest). However, the lessor's sales systemcan also come to the conclusion that an invoice has to be cancelledbecause, for example, the lessee has not yet paid any of the leaseinstallments. In this case, Invoicing has to perform suitable follow-onactions since it is the recipient of a request to cancel the invoice(SupplierInvoiceCancellationExecutionRequest).

(1) Message Types

(a) InvoiceRequest

An InvoiceRequest is a legally binding notification of payables orreceivables for delivered goods and rendered services and, usually, apayment request for these goods and services. The structure of themessage type InvoiceRequest is specified by the message data typeInvoiceMessage. The message of message type InvoiceRequest is sent fromthe invoicing party to the invoice recipient, and is used to start a newinvoicing process. It transfers (as defined) invoices in the broadersense. This includes the specific invoice (request to settle a payable),the debit memo, and the credit memo.

(b) InvoiceConfirmation

An InvoiceConfirmation is a response sent by the recipient to theinvoicing party confirming or rejecting the entire invoice received orstating that it has been assigned temporarily the status “pending”. Thestructure of the message type InvoiceConfirmation is specified by themessage data type InvoiceMessage. The message of message typeInvoiceConfirmation is sent from the invoice recipient to the invoicingparty. It is used to confirm or reject an entire invoice, or to assignit temporarily the status “pending”. An InvoiceConfirmation is notmandatory in a B2B invoicing process. However, it helps to automatecollaborative processes and dispute management.

(c) SupplierInvoiceInformation

A SupplierInvoiceInformation is a piece of information from Invoicingabout an accepted invoice or its cancellation. The structure of themessage type SupplierInvoiceInformation is specified by the message datatype SupplierInvoiceInformationMessage.

(d) SupplierInvoiceSettlementReleaseRequest

A SupplierInvoiceSettlementReleaseRequest is the request to release anaccepted invoice for settlement. The structure of the message typeSupplierInvoiceSettlementReleaseRequest is specified by the message datatype SupplierInvoiceSettlementReleaseRequestMessage.

(e) SupplierInvoiceCancellationExecutionRequest

A SupplierInvoiceCancellationExecutionRequest is the request to cancel avendor invoice. The structure of the message typeSupplierInvoiceCancellationExecutionRequest is specified by the messagedata type SupplierInvoiceCancellationExecutionRequestMessage. Thereceiving system decides how the cancellation request should beimplemented. Depending on the extent to which the vendor invoice hasbeen processed, it can simply be deleted and the invoicing partyinformed of this, for example, or it might be the case that acancellation invoice has to be generated and posted.

(2) Message Choreography

FIG. 472 depicts an exemplary message choreography for an invoicingprocess between business applications or entities (e.g., Billing entity47202, Invoicing entity 47204, and Purchasing (SRM) entity 47206)implementing Invoicing Interfaces in accordance with the subject matterdescribed herein. In the implementation shown in FIG. 472, an invoice iscreated after a goods receipt or service performance has been confirmed.Billing 47202 starts the invoicing process by sending an InvoiceRequestmessage 47208.

Upon receiving the InvoiceRequest message 47208, Invoicing 47204 can usethe InvoiceConfirmation message 47210 to completely accept or reject theinvoice received or to assign it temporarily the status “pending”.

The InvoiceConfirmation message 47210 is not a negotiation tool (as isthe case in order management), since the only options available areeither to accept or reject the entire invoice. The invoice data in theInvoiceConfirmation message 47210 merely confirms that the invoice hasbeen forwarded correctly and does not communicate any desired changes tothe invoice. Therefore, the InvoiceConfirmation message 47210 containsthe precise invoice data that was received and verified by Invoicing47204.

If Invoicing 47204 rejects an invoice, Billing 47202 can send a newinvoice after checking the reason for rejection (AcceptanceStatus andConfirmationDescription at Invoice and InvoiceItem level).

If the invoice recipient does not respond, the invoice is generallyregarded as being accepted and the invoicing party can expect payment.

Interested applications are informed by Invoicing 47204 of acceptedinvoices (InvoiceInformation 47212) and authorized recipients of thisinformation can request that Invoicing 47210 release the invoice forsettlement (InvoiceSettlementReleaseRequest 47214). If the interestedapplication does not accept the invoice, a request that the invoice becanceled can be created instead(SupplierInvoiceCancellationExecutionRequest 47216).

The evaluated receipt settlement (ERS) procedure is based on the data inthe good receipt or service confirmation. The buyer must have agreedwith the relevant seller that no invoice is to be created for theorders. Instead, the buyer or the company responsible for verifyinginvoices posts an invoice based on the purchase order and itsconfirmation. As a result, invoice variances or communication errors areavoided and transactions are completed more quickly.

In the ERS process, the partner functions of the invoice recipient andthe invoicing party are swapped with regard to the invoicing process.Generally speaking, the buyer creates the invoices and then sends acredit memo for the amount of the payable concerned, using theInvoiceRequest message 47208, to either the seller or the companyresponsible for invoicing.

In the invoicing process, messages can be transmitted once in order(EQIO) and serialized using message queues. Each invoicing process canhave its own message queue (as opposed to one queue for all invoices) sothat one failed message does not block all other messages in the entiresystem.

In an invoicing process, the IDs of the objects and messages concernedare used to correlate the individual messages. An InvoiceRequest message47208 is referenced by the ReferenceMessageID in an InvoiceConfirmation47210 or in a subsequent InvoiceRequest 47208 (credit memo). TheInvoiceConfirmation 47210 contains the same Invoice object as theInvoiceRequest 47208 to which it is related but has its own MessageID.This procedure can correspond to the RosettaNet standard.

In accordance with the Communication Paradigms, forward processing canbe used to resolve errors. A recipient system can accept formallycorrect incoming messages.

In order to restart a process that is corrupt due to a failed message,the invoicing system provides an option for transmitting the currentstatus of the invoice using an Invoice Request message 47208.

Many different business conflict scenarios are conceivable followingreceipt of an invoice. A few examples are: the invoice is not approveddue to discrepancies in price and/or quantity; the invoice is approved,posted, and paid, but the triggering purchase order is then cancelled;invoicing occurs before goods are received; and goods that have beenpaid for are defective and have to be returned.

Business conflict scenarios (dispute management) are resolved usinginvoice confirmations and invoice cancellations (seeInvoiceCancellationInvoiceIndicator). For instance, an invoice that wasissued prior to goods receipt or which contains excessive price orquantity specifications can initially be assigned the status “pending”using the invoice confirmation. The invoice can then be approved andpaid once the goods or credit memo has been checked. If payment hasalready been made or if the invoice has already been posted inAccounting, an invoice cancellation or a credit memo for partlydefective products, for example, can be issued.

(3) Message Interfaces

Invoice messages are implemented by four message interfaces, two on theinvoice recipient side (InvoiceRequest_In and InvoiceConfirmation_Out)and two on the invoicing party side (InvoiceRequest_Out andInvoiceConfirmation_In).

(4) Country-Specific Enhancements

Often, the invoice must be supplemented with country-specificinformation in order to fulfill the legal requirements of the particularregion. For instance, an invoice is not recognized as being legal inGermany unless it contains the “tax evasion combat number,” issued forbusiness partners by the tax office.

Country-specific invoice information may result in the message data typeInvoice being enhanced in the future or in additions made by customersaccording to their individual requirements. In either case, the specificinformation can be added to the appropriate business objects.

For example, the data type InvoiceMessage can include thecountry-specific element NotaFiscalTypeCode (Invoice Package). TheNotaFiscalTypeCode is a coded representation of nota fiscal types.Examples of special nota fiscal types are complementary (similar to thecredit or debit memo); corrections; cancellations; and conhecimento(freight invoice).

In addition, the data type InvoiceMessage can include thecountry-specific element PaymentReferenceID (PaymentInformationPackage). The PaymentReferenceID is an identification number thatsellers in Scandinavian countries include on outgoing invoices. Sellersin Switzerland, which has adopted the procedure of inpayment slips withreference numbers, also use payment reference numbers. Since the buyerindicates the payment reference number when paying the invoice, it isclear to the seller which invoice is being paid. The payment referenceconsists of a sequential number and a check digit. The check digits canbe calculated differently in every country.

In the schemeAgencyID attribute of the PaymentReferenceID, the number ofthe participant using the procedure of inpayment slips with referencenumbers can be specified. This identification number is issued to eachparticipant in the procedure by the Swiss PostFinance.

(5) Message Data Type SupplierInvoiceInformationMessage

FIGS. 473A-D depict a data model of the message data typeSupplierInvoiceInformationMessage. The message data typeSupplierInvoiceInformationMessage contains the business information thatis relevant for sending a business document in a message. TheSupplierInvoiceInformationMessage package 47301 contains a MessageHeaderpackage 47302, a SupplierInvoice package 47303, and aSupplierInvoiceInformationMessage entity 47304. The message data typeSupplierInvoiceInformationMessage thus provides the structure for themessage type SupplierInvoiceInformation and the interfaces that arebased on it.

(a) MessageHeader Package

A MessageHeader package 47302 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader package 47302 is not required in theSupplierInvoiceInformationMessage. The MessageHeader package 47302contains the MessageHeader entity 47305. There is a 1:c relationshipbetween the SupplierInvoiceInformationMessage entity 47304 and theMessageHeader entity 47305. Where a relationship is identified betweenentitites in FIGS. 473A-D for this Interface, the respectiverelationship is a 1:c relationship unless otherwise noted herein orindicated in FIGS. 473A-D. The MessageHeader package 47302 also includesa SenderParty entity 47306 and a RecipientParty entity 47307. There is a1:c relationship between the MessageHeader entity 47305 and theSenderParty entity 47306 and between the MessageHeader entity 47305 andthe RecipientParty entity 47307.

(b) SupplierInvoice Package

The SupplierInvoice package 47303 groups together a Party package 47308,a Location package 47309, a DeliveryInformation package 47310, aPaymentInformation package 47311, a PriceInformation package 47312, aTax package 47313, a Attachment package 47314, a Description package47315, a Item package 47316, and a SupplierInvoice entity 47317.

(i) SupplierInvoice

The SupplierInvoice entity 47317 is a vendor's list of payables andreceivables for delivered goods and rendered services which are paid forby a certain time. There is a 1:1 relationship between theSupplierInvoiceInformationMessage entity 47304 and the SupplierInvoiceentity 47317. The SupplierInvoice entity 47317 provides not only theremuneration and tax to be paid by the participating business partnersfor products and services, but also provides detailed information aboutterms of payment and delivery. The SupplierInvoice entity 47317 containsthe following elements: ID, BillToID, TypeCode, DateTime,CancellationInvoiceIndicator, AcceptanceStatusCode, and Note. The ID isan invoice number; a unique identifier that is assigned to the invoiceby the invoicing party. The ID is of type GDT:BusinessTransactionDocumentID. The BillToID is a unique identifier thatis assigned to the invoice by the invoice recipient and is of type GDT:BusinessTransactionDocumentID. The TypeCode is a coded representationfor the invoice type (a specific invoice/payment request, debit memo, orcredit memo) and is of type GDT: BusinessTransactionDocumentTypeCode.The DateTime is an invoice date and is of type GDT: DateTime. TheCancellationInvoiceIndicator indicates whether the invoice is acancellation invoice or not and is of type GDT:InvoiceCancellationInvoiceIndicator. The AcceptanceStatusCode is a codedrepresentation for the status of the invoice recipient's acceptance ofthe invoice and is of type GDT: AcceptanceStatusCode. The Note is ashort description/name of the invoice and is of type GDT: Note. TheSupplierInvoice entity 47317 is of type GDT: SupplierInvoice.

In some implementations, monetary amounts and prices are in the samecurrency within any given invoice and the invoice number attributes arenot used. In some implementations, The BillToID can be used only in theInvoiceConfirmation. In some implementations, the AcceptanceStatusCodemust not be used in the InvoiceRequest. In some implementations, in theInvoiceConfirmation, the AcceptanceStatusCode must be set to one of thefollowing options: AP (accepted—invoice has been accepted), AJ(pending—it is not yet possible to make a final decision about theinvoice), and RE (rejected—the invoice has been rejected).

In some implementations, the AcceptanceStatusCode, along with theBillToID and the ConfirmationDescription are the only elements that canbe used in the InvoiceConfirmation. No other data may containdiscrepancies with the invoice data received.

(ii) Party Package

The Party package 47308 groups together business partners that can beinvolved in an invoicing process. The Party package 47308 contains theentities: BillToParty entity 47318, BillFromParty entity 47319,BuyerParty entity 47320, SellerParty entity 47321, ProductRecipientPartyentity 47322, VendorParty entity 47323, ManufacturerParty entity 47324,PayerParty entity 47325, PayeeParty entity 47326, and CarrierPartyentity 47327. There is a 1:1 relationship between the SupplierInvoiceentity 47317 and the BillToParty entity 47318 as well as theSupplierInvoice entity 47317 and the BillFromParty entity 47319.

A default logic is used for business partners: business partners thatare specified at SupplierInvoice level are used for items for whichcorresponding partners are not explicitly transmitted. The default logicis used for the partner as a whole, including the contact person. Atitem level, parts of a partner cannot be specified more precisely. Thedefault logic is only a simplified version of the transmitted message.In terms of logic, partners at SupplierInvoice level behave as if theyhave been explicitly transmitted for all the items of the message.

The BillToParty entity 47318 is a company or person to which the invoicefor deliveries received or services rendered is to be sent. TheBillToParty entity 47318 is of type GDT:BusinessTransactionDocumentParty. The BillToParty entity 47318 can alsofulfill the function of BuyerParty entity 47320, ProductRecipientPartyentity 47322, and PayerParty entity 47325.

The BillFromParty entity 47319 is a company or person executing theinvoicing process. The BillFromParty entity 47319 is of type GDT:BusinessTransactionDocumentParty. The BillFromParty entity 47319 canalso fulfill the function of SellerParty entity 47321, VendorPartyentity 47323, and PayeeParty entity 47326.

The BuyerParty entity 47320 is a company or person authorizing thedeliveries or services. The BuyerParty entity 47320 is of type GDT:BusinessTransactionDocumentParty. In some implementations, theBuyerParty entity 47320 must always be specified. If no BuyerPartyentity 47320 is explicitly specified in an invoice, the BillToPartyentity 47318 also acts as the BuyerParty entity 47320.

The SellerParty entity 47321 is a company or person selling(sales/service area). The SellerParty entity 47321 is of type GDT:BusinessTransactionDocumentParty. In some implementations, theSellerParty entity 47321 must always be specified. If no SellerPartyentity 47321 is explicitly specified in an invoice, the BillFromPartyentity 47319 also acts as the SellerParty entity 47321.

The ProductRecipientParty entity 47322 is a company or person to whichgoods are delivered or for which services are rendered. TheProductRecipientParty entity 47322 is of type GDT:BusinessTransactionDocumentParty. If no ShipToLocation is explicitlyspecified in an invoice, the address of the ProductRecipientParty entity47322 is the delivery address. If no ProductRecipientParty entity 47322is explicitly specified in an invoice, the BuyerParty entity 47320 alsoacts as the ProductRecipientParty entity 47322.

The VendorParty entity 47323 is a company or person delivering the goodsor providing the service. The VendorParty entity 47323 is of type GDT:BusinessTransactionDocumentParty. If no ShipFromLocation is explicitlyspecified in an invoice, the address of the VendorParty entity 47323 isthe ship-from address. If no VendorParty entity 47323 is explicitlyspecified in an invoice, the SellerParty entity 47321 also acts as theVendorParty entity 47323. The CarrierParty entity 47327, not theVendorParty entity 47323, is the company or person that is solelyresponsible for transporting the goods.

The ManufacturerParty entity 47324 is a company or person that producedthe goods being invoiced. The ManufacturerParty entity 47324 is of typeGDT: BusinessTransactionDocumentParty. The ManufacturerParty entity47324 can be used for invoice items relating to materials. TheManufacturerParty entity 47324 can be used to uniquely define thecontext of a ManufacturerProductID.

The PayerParty entity 47325 is a company or person that pays for thegoods or services rendered. The PayerParty entity 47325 is of type GDT:BusinessTransactionDocumentParty. If no PayerParty entity 47325 isexplicitly specified in an invoice, the BillToParty entity 47318 alsoacts as the PayerParty entity 47325.

The PayeeParty entity 47326 is a company or person that receives paymentfor the goods or services rendered. The PayeeParty entity 47326 is oftype GDT: BusinessTransactionDocumentParty. If no PayeeParty entity47326 is explicitly specified in an invoice, the BillFromParty entity47319 also acts as the PayeeParty entity 47326.

The CarrierParty entity 47327 is a company or person that transportedthe goods. The CarrierParty entity 47327 is of type GDT:BusinessTransactionDocumentParty. In some implementations, theCarrierParty entity 47327 should only be used for invoice items relatingto materials; it can be ignored by the recipient for services. TheCarrierParty entity 47327 can be required for fiscal law purposes incertain business transactions involving delivery across countries.

(iii) Location Package

The Location package 47309 groups together locations that can beinvolved in an invoicing process. The Location package 47309 containsthe entities: ShipToLocation entity 47328 and ShipFromLocation entity47329. A default logic is used for locations: locations that arespecified at SupplierInvoice level are used for items for whichcorresponding locations are not explicitly transmitted. ShipToLocationentity 47328 and ShipFromLocation entity 47329 can be used to provide amore detailed description of the flow of goods (between delivery pointand dispatch point). In certain countries (e.g., USA) this detailedinformation is required for calculating taxes.

The ShipToLocation entity 47328 is a location to which goods weredelivered or where services were rendered. The ShipToLocation entity47328 is of type GDT: BusinessTransactionDocumentLocation. For example,a sold-to party (BuyerParty entity 47320) headquartered in Californiaorders steel beams for a building. The construction site (ShipToLocationentity 47328) for the building is located in Arizona. The tax amount iscalculated using the tax rates that apply in Arizona.

The ShipFromLocation entity 47329 is the location from which goods wereshipped. The ShipFromLocation entity 47329 is of type GDT:BusinessTransactionDocumentLocation.

(iv) DeliveryInformation Package

The DeliveryInformation package 47310 summarizes information for adelivery in the invoicing process. The DeliveryInformation package 47310contains the entity: DeliveryTerms entity 47330. A default logic similarto that used for parties is also used for DeliveryTerms entity 47330(see the Party package 47308).

The DeliveryTerms entity 47330 is the conditions and agreements thatapply when delivering and transporting the ordered goods and providingthe necessary services and activities for this. The DeliveryTerms entity47330 is of type GDT: DeliveryTerms. Of the GDT DeliveryTerms entity47330, the elements Incoterms 47331 and Transport can only be used formaterial items. The default logic only takes Incoterms 47331 andTransport into account for material items; they are ignored for otheritems.

(v) PaymentInformation Package

The PaymentInformation package 47311 summarizes payment information inthe invoicing process. The PaymentInformation package 47311 contains theentities: CashDiscountTerms entity 47332 and PaymentForm entity 47333.

The CashDiscountTerms entity 47332 contains the payment conditions (cashdiscount rates and payment deadlines). The CashDiscountTerms entity47332 is of type GDT: CashDiscountTerms. The CashDiscountTerms entity47332 contains MaximumDiscount 47334 and NormaIDiscount 47335.

The PaymentForm entity 47333 specifies the method of payment for aproduct. The PaymentForm entity 47333 contains the elementPaymentFormCode and the entity PaymentCard entity 47336. ThePaymentFormCode is a coded representation of the payment form and is oftype GDT: PaymentFormCode. The PaymentCard entity 47336 is a credit cardor customer card. The PaymentCard entity 47336 is of type GDT:PaymentCard.

(vi) PriceInformation Package

The PriceInformation package 47312 summarizes information about thetotal amount invoiced for the products provided or services rendered,which are listed at item level. The PriceInformation package 47312contains a Price entity 47337.

The Price entity 47337 is the total amount invoiced for productsdelivered and services rendered, including the tax and net portions. ThePrice entity 47337 contains the elements: GrossAmount, NetAmount,TaxAmount, and ExchangeRate. The GrossAmount is a gross invoice amount(net amount plus tax amount) and is of type GDT: Amount. The NetAmountis a net invoice amount and is of type GDT: Amount. The TaxAmount is atax amount in invoice and is of type GDT: Amount. The ExchangeRate is anexchange rate information for an invoice. The exchange rate can bespecified if the products ordered are settled in a currency that isdifferent than the currency in the purchase order. This is often thecase with collective invoices, for example. The ExchangeRate is of typeGDT: ExchangeRate. A default logic is used for exchange rateinformation: exchange rates that are specified at SupplierInvoice levelare used for items for which corresponding exchange rates are notexplicitly transmitted.

(vii) Tax Package

The Tax package 47313 summarizes all information about tax pricecomponents in the total amount invoiced for products delivered orservices rendered. The Tax package 47313 contains the ProductTax entity47338.

The ProductTax entity 47338 is the tax amount invoiced for productsdelivered or services rendered, added for all invoice items. TheProductTax entity 47338 is of type GDT: ProductTax. There is a 1:cnrelationship between the SupplierInvoice entity 47317 and the ProductTaxentity 47338.

(viii) Attachment Package

The Attachment package 47314 groups together attachment informationrelating to the invoice. The Attachment package 47314 contains theAttachment entity 47339.

The Attachment entity 47339 is a document of any type that relates tothe invoice and is transmitted with it. The Attachment entity 47339 isof the type GDT: Attachment. There is a 1:cn relationship between theSupplierInvoice entity 47317 and the Attachment entity 47339.

(ix) Description Package

The Description package 47315 groups together explanatory texts relatingto the invoice. The Description package 47315 contains the entities:Description entity 47340 and ConfirmationDescription entity 47341.

The Description entity 47340 is a natural language text regarding theinvoice, and is visible to all business parties. The Description entity47340 is of type GDT: Description. The Description entity 47340 can beused for all types of textual information relating to the invoicetransmitted. For example, the text can be information stating that aSales employee responsible will be on vacation starting on a specificdate and indicating the name and telephone number of a substitutestarting on that date.

The ConfirmationDescription entity 47341 is a natural language textregarding the invoice confirmation, and is visible to business parties.The ConfirmationDescription entity 47341 is of type GDT: Description. Insome implementations, in an InvoiceRequest, the ConfirmationDescriptionentity 47341 is not used. The ConfirmationDescription entity 47341 canbe used for all types of textual information relating to the invoiceconfirmation. For example, an invoice recipient's reason for rejecting aparticular invoice.

(c) SupplierInvoiceItem Package

The SupplierInvoiceItem package 47316 groups together information aboutthe amounts invoiced or credited for products, broken down by type andscope of the goods delivered and/or services rendered. TheSupplierInvoiceItem package 47316 contains the following packages:ProductInformation package 47342, PriceInformation package 47343, Taxpackage 47344, Party package 47345, Location package 47346,DeliveryInformation package 47347, BusinessTransactionDocumentReferencepackage 47348, Accounting package 47349, Attachment package 47350, andDescription package 47351. The SupplierInvoiceItem package 47316contains the following entities: SupplierInvoiceItem entity 47352 andHierarchyRelationship entity 47353.

The SupplierInvoiceItem entity 47352 is a part of an invoice thatcontains the prices and taxes for the quantity of a product that hasbeen delivered or for a service that has been rendered. In addition tothe information about prices and taxes, SupplierInvoiceItem entity 47352includes information about participating business partners, paymentconditions and delivery terms, if these differ from information providedin the invoice header. There is a 1:n relationship between theSupplierInvoice entity 47317 and the SupplierInvoiceItem entity 47352.The SupplierInvoiceItem entity 47352 has the following elements: ID,BillToID, TypeCode, DeliveryPeriod, and Quantity.

The ID is an invoice item number; a unique identifier that is assignedto the invoice item by the invoicing party. The ID is of type GDT:BusinessTransactionDocumentItemID.

The BillToID is a unique identifier that is assigned to the invoice itemby the invoice recipient. The BillToID is of type GDT:BusinessTransactionDocumentItemPartyID.

The TypeCode is a coded representation for the invoice item type(invoice item in the sense of a receivable, credit memo item, deliverycost item, subsequent debit item, or subsequent credit item). TheTypeCode is of type GDT: BusinessTransactionDocumentItemTypeCode . Insome implementations, an invoice cannot be changed for legal reasons,therefore invoices that contain errors can either be cancelledcompletely and reissued, or adjusted using debit and credit amounts inanother invoice. In this case, only the difference amount required tocorrect the financial data is transferred and not, for example, the newabsolute value for a product per price unit of measure. It is alsoimportant to note that the amount to be settled in a subsequent creditor debit item cannot be offset against the open purchase order ordelivery quantity.

For example, in one case there may be a purchase order item such as 10pens at

3 each, an invoice item such as 10 pens at

3 each, and a subsequent debit item such as 2 pens at

0.50 each. After the bill has been issued (invoice item 10), ittranspires that 2 pens cost

3.50 rather than

3. In this case, the invoicing party can send a subsequent debit for the2 items in a second invoice, which represents a financial adjustment forthe total settlement amount.

The DeliveryPeriod is the delivery date of the products invoiced or thetime period in which the service was rendered. The DeliveryPeriod is oftype GDT: DateTimePeriod.

The Quantity is the quantity invoiced. The Quantity is of type GDT:Quantity.

The SupplierInvoiceItem entities 47352 are arranged hierarchically usingthe HierarchyRelationship entity 47353. An invoice must contain at leastone item. In some implementations, The BillToID can be used only in theInvoiceConfirmation. In some implementations, an invoice can containeither only payable items, credit memo items and delivery cost items, orsubsequent debit items and subsequent credit items. In someimplementations, Item categories are not combined.

The HierarchyRelationship entity 47353 is the relationship between asubitem and a higher-level parent item in an item hierarchy. There is a1:c relationship between the SupplierInvoiceItem entity 47352 and theHierarchyRelationship entity 47353 as well as a 1:cn relationshipbetween the SupplierInvoiceItem entity 47352 and theHierarchyRelationship entity 47353. The HierarchyRelationship entity47353 contains the elements: ParentItemID, ParentItemBillToID, andTypeCode. The ParentItemID is a reference to a parent item with the itemnumber assigned by the invoicing party. TheSupplierInvoiceItemHierarchyRelationshipParentItemID is of type GDT:BusinessTransactionDocumentItemID. The ParentItemBillToID is a referenceto a parent item with the item number assigned by the invoice recipient.The SupplierInvoiceItemHierarchyRelationshipParentItemID is of type GDT:BusinessTransactionDocumentItemID. The TypeCode is a codedrepresentation of the type of hierarchical relationship between thesubitem and its higher-level parent item. TheSupplierInvoiceItemHierarchyRelationshipTypeCode is of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode.

There are various types of items, and they are governed by differentintegrity conditions (constraints). An item can have several integritytypes. In this case, the item must satisfy all the integrity conditionsfor all of its integrity types. The description of the integrity typesindicates which integrity types can be combined with one another and howthey can be combined. The various integrity types are as follows:

Standard items are items to which no lower-level items have beenassigned. An items that is not referenced by another item using theelement ParentItemID in the HierarchyRelationship entity is a standarditem.

Hierarchy items are items to which at least one other lower-level itemhas been assigned in the hierarchy. An item that is referenced by atleast one other item, using the ParentItemID is a hierarchy item. Itemsare either standard or hierarchy items.

Subitems are items that have been assigned below a hierarchy item andnot directly to the purchase order header. Subitems can be both standarditems and hierarchy items. An item that references another item usingthe ParentItemID is a subitem.

Material items are items whose product is a material. An item whoseProductTypeCode is “1” (Material) is a material item.

Service items are items whose product is a service. An item whoseProductTypeCode is “2” (Service) is a service item.

Unspecified product items are items for which no information is providedindicating whether they refer to a material or a service. An item whoseProductTypeCode is not specified is an unspecified product item. Itemsare material, service, or unspecified product items. An unspecifiedproduct item must satisfy all the integrity conditions of a material,service, or limit item.

Grouping hierarchy items are hierarchy items that logically grouptogether other items. Multilevel grouping hierarchies are permitted,i.e., a grouping hierarchy item can contain subitems that are alsogrouping hierarchy items. A hierarchy item whose subitems haveHierarchyRelationshipTypeCode “002” (group) is a grouping hierarchyitem; in some implementations, subitems with a differentHierarchyRelationshipTypeCode are not permitted. Grouping hierarchyitems are not permitted as subitems of other types of hierarchy items.

Substitute product hierarchy items are hierarchy items for which thereis at least one subitem with a substitute product. Multilevel substituteproduct hierarchies are not permitted, i.e., a substitute product canitself not be substituted. A hierarchy item whose subitems all haveHierarchyRelationshipTypeCode “006” (substitute product) is a substituteproduct hierarchy item; subitems with a differentHierarchyRelationshipTypeCode are not permitted. Substitute producthierarchy items can be used as subitems in grouping hierarchies.

BOM hierarchy items are hierarchy items that group together other itemsin a BOM. Multilevel BOM hierarchies are permitted. A hierarchy itemwith at least one subitem with HierarchyRelationshipTypeCode “001” (billof material) is a BOM hierarchy item; additional subitems are permittedwith the HierarchyRelationshipTypeCode “003” (discount in kind).

Discount in kind hierarchy items are hierarchy items for which a goodsdiscount is granted in the form of an inclusive or exclusive bonusquantity. Multilevel discount in kind hierarchies are not permitted,i.e., no discount in kind can be granted for discount in kind. The goodsdiscount is described in the form of one or more subitems in thediscount in kind hierarchy item. A Hierarchy item with at least onesubitem with HierarchyRelationshipTypeCode “003” (discount in kind) is adiscount in kind hierarchy item; additional subitems are permitted withthe HierarchyRelationshipTypeCode “001” (bill of material). Hierarchyitems are grouping, BOM, or discount in kind hierarchy items. Ahierarchy item can be both a BOM and a discount-in-kind hierarchy item,if a discount in kind has been granted for a BOM.

(i) SupplierInvoiceItemProductInformation Package

The SupplierInvoiceItemProductInformation package 47342 summarizesinformation for identifying, describing, and classifying a product in aninvoice item. The Productlnfoprmation package 47342 contains theentities: Product entity 47354 and ProductCategory entity 47355. TheSupplierInvoiceItemProductInformation package 47342 can not be used ingrouping hierarchy items.

The Product entity 47354 identifies, describes, and classifies theproduct that has been invoiced. The Product entity 47354 is of type GDT:BusinessTransactionDocumentProduct. With the exception of groupinghierarchy items, at least either the product number or productdescription (note) must be provided when a new item is created. If boththe product number and description are provided, the description ismerely additional information in the message and can be ignored by therecipient.

The ProductCategory entity 47355 is the assignment of an invoicedproduct to a higher-level, company-specific category. TheProductCategory entity 47355 is of type GDT:BusinessTransactionDocumentProductCategory. The product category isderived directly from the product if a product number is provided forthe product. It can differ for the buyer and seller if they haveclassified the same product differently. This can be permitted andtolerated by the systems involved.

(ii) SupplierInvoiceItemPriceInformation Package

The SupplierInvoiceItemPriceInformation package 47343 summarizesinformation about the amount invoiced for a product delivered or aservice rendered, including all price components. The PriceInformationpackage 47343 contains the Price entity 47356 The Price entity 47356 isthe amount invoiced for a delivered product or a service rendered,including the tax and net portions. The Price entity 47356 contains theelements: GrossAmount, NetAmount, TaxAmount, NetUnitPrice, ExchangeRate,PricingDate and the Component entity 47357. The GrossAmount is a grossitem amount (net amount plus tax amount) and is of type GDT: Amount. TheNetAmount is a net item amount and is of type GDT: Amount. The TaxAmountis a tax amount for an item and is of type GDT: Amount. The NetUnitPriceis a net price for the base quantity of a product that was used tocalculate the net amount (e.g. 110 for 5 pieces) and is of type GDT:Price. The ExchangeRate is information about the exchange rate. Theexchange rate can be specified if the quantity ordered of a product issettled in a currency that is different from the currency in thepurchase order item. This is often the case with collective invoices,for example. The ExchangeRate is of type GDT: ExchangeRate. ThePricingDate is a date on which the price is calculated and is of typeGDT: Date. In some implementations, the elements NetAmount andGrossAmount are specified if the invoice item specified is not agrouping hierarchy item. A default logic is used for the exchange rateinformation if an exchange rate is not specified explicitly at itemlevel or if the exchange rate at invoice level applies.

The Component entity 47357 is a non-fiscal part of a price in an invoiceitem. The Component entity 47357 is of type GDT: PriceComponent. Aninvoice item can contain several price components. There is a 1:cnrelationship between the Price entity 47356 and the Component entity47357. A detailed list of the price components (including, e.g.,rounding difference clearing, etc.) is provided to help the invoicerecipient understand how the amount invoiced was calculated. In B2Bstandards, such as RosettaNet (PIP 3C3 version 1.1) or xCBL 3.0, pricecomponents are not available in this form. As a result, the usualelements in B2B standards, namely, GrossAmount and NetAmount, arehighlighted and shown (redundantly) along with the detailed list thatincludes price components. Taxes are also price components that can beshown explicitly because of legal aspects. Tax information (ProductTax)is not shown redundantly.

(iii) SupplierInvoiceItemTax Package

The SupplierInvoiceItemTax package 47344 summarizes information abouttax price components in the total amount invoiced for products deliveredor services rendered. The Tax package 47344 contains a ProductTax entity47358.

The ProductTax entity 47358 is a tax component of an invoice item thatis incurred for each tax type and rate. The ProductTax entity 47358 isof type GDT: ProductTax. There is a 1:cn relationship between theSupplierInvoiceItem entity 47352 and the ProductTax entity 47358.

(iv) SupplierInvoiceItemParty Package

The SupplierInvoiceItemParty package 47345 groups the business partnersthat can be involved in an invoice item and that differ from thepartners specified at SupplierInvoice level. The Party package 47345contains the entities: BuyerParty entity 47359, SellerParty entity47360, ProductRecipientParty entity 47361, VendorParty entity 47362,ManufacturerParty entity 47363, and CarrierParty entity 47364. Theseentities perform operations analogous to the entities of the same namewithin the Party package 47308.

(v) SupplierInvoiceItemLocation Package

The SupplierInvoiceItemLocation package 47346 groups together locationsthat can be involved in an invoicing process and that differ from thelocations specified at SupplierInvoice level. The Location package 47346contains the entities: ShipToLocation entity 47365 and ShipFromLocationentity 47366. These entities perform operations analogous to theentities of the same name within the Location package 47309.

(vi) SupplierInvoiceItemDeliveryInformation Package

The SupplierInvoiceItemDeliveryInformation package 47347 summarizesinformation for a delivery in the invoicing process where theinformation differs from the information specified at SupplierInvoicelevel. The DeliveryInformation package 47347 contains a DeliveryTermsentity 47367, which contains an Incoterms entity 47368. These entitiesperform operations analogous to the entities of the same name within theDeliveryInformation package 47310.

(vii) SupplierInvoiceItemBusinessTransactionDocumentReference Package

The SupplierInvoiceItemBusinessTransactionDocumentReference package47348 groups together references to business documents that can occur inthe invoicing process at item level. TheBusinessTransactionDocumentReference package 47348 contains theentities: PurchaseOrderReference entity 47369, SalesOrderReferenceentity 47370, DeliveryReference entity 47371,ServiceAcknowledgementReference entity 47372, QriginInvoiceReferenceentity 47373, PurchaseContractReference entity 47374,SalesContractReference entity 47375, BuyerProductCatalogueReferenceentity 47376, SellerProductCatalogueReference entity 47377,ProjectReference entity 47378, and ProjectElementAssignment entity47379.

In some implementations, the entities in theBusinessTransactionDocumentReference package 47348 cannot be used ingrouping hierarchy items. If possible, individual items are referencedin the invoice from item level (e.g. purchase order item 10 in purchaseorder 4711 is directly referenced from purchase order item 1). If anitem assignment is not recognized, an entire document can be referenced(e.g., contract 0815 is referenced from purchase order 4712).

The PurchaseOrderReference entity 47369 is a reference to a purchaseorder or an item within a purchase order. The PurchaseOrderReferenceentity 47369 is of type GDT: BusinessTransactionDocumentReference. ThePurchaseOrderReference entity 47369 contains the purchase order numberand purchase order item number issued by the buyer. There can be morethan one PurchaseOrderReference. There is a 1:cn relationship betweenthe SupplierInvoiceItem entity 47352 and the PurchaseOrderReferenceentity 47369.

The SalesOrderReference entity 47370 is a reference to a sales order oran item within a sales order. The SalesOrderReference is of type GDT:BusinessTransactionDocumentReference. The SalesOrderReference entity47370 contains the order number and order item number issued by theseller. There can be more than one SalesOrderReference. There is a 1:cnrelationship between the SupplierInvoiceItem entity 47352 and theSalesOrderReference entity 47370.

The DeliveryReference entity 47371 is a reference to a delivery. TheDeliveryReference entity 47371 is of type GDT:BusinessTransactionDocumentReference. The DeliveryReference entity 47371contains the delivery note number assigned by the seller.

The ServiceAcknowledgementReference entity 47372 is a reference to aconfirmation, created by the seller, that a service has been rendered(e.g., in the service entry system). The ServiceAcknowledgementReferenceentity 47372 is of type GDT: BusinessTransactionDocumentReference. TheServiceAcknowledgementReference entity 47372 includes the serviceacknowledgment number issued by the service provider.

The OriginInvoiceReference entity 47373 is a reference to an invoicepreviously sent. The OriginInvoiceReference entity 47373 is of type GDT:BusinessTransactionDocumentReference. The OriginInvoiceReference entity47373 contains the invoice number issued by the invoicing party. Thisreference can be required if a credit memo is issued for an amount thathas been invoiced. The PurchaseContractReference entity 47374 is areference to a purchase contract or an item within a purchase contract.The PurchaseContractReference entity 47374 is of type GDT:BusinessTransactionDocumentReference. Provided there is no agreement tothe contrary, the seller can be responsible for determining the correctSalesContractReference for a specified PurchaseContractReference entity47374.

The SalesContractReference entity 47375 is a reference to a salescontract or an item within a sales contract. The SalseContractReferenceentity 47375 is of type GDT: BusinessTransactionDocumentReference.

The BuyerProductCatalogueReference entity 47376 is a reference to abuyer's product catalog or an item within such a catalog. TheBuyerProductCatalogueReference entity 47376 is of type GDT:CatalogueReference. The BuyerProductCatalogueReference entity 47376 canbe filled when an invoice item refers to a catalog whose number and itemnumbers were issued by the buyer.

The SellerProductCatalogueReference entity 47377 is a reference to aseller's product catalog or an item within such a catalog. TheSellerProductCatalogueReference entity 47377 is of type GDT:CatalogueReference. The SellerProductCatalogueReference entity 47377 canbe filled when an invoice item refers to a catalog whose number and itemnumbers were issued by the seller.

The ProjectReference entity 47378 is a reference to a project or anelement within a project. The ProjectReference entity 47378 is of typeGDT: ProjectReference. In some implementations, the ProjectReferenceentity 47378 is not used in the InvoiceMessage. TheProjectElementAssignment entity 47379 is an assignment between twoproject elements to which an invoice item refers. TheProjectElementAssignment entity 47379 is of the type GDT:ProjectElementAssignment. In some implementations, theProjectElementAssignment entity 47379 is not used in the InvoiceMessage.Either a ProjectReference entity 47378 or a ProjectElementAssignmententity 47379 can be specified, not both. Only one assignment of a role(ProjectElementTypeCodes=“2”) to a task (ProjectElementTypeCodes=“1”) ispermitted. In a procurement process, the ProjectElementAssignment entity47379 continues to be passed on when goods are received, servicesentered, and invoicing occurs. This means that a project system alwayshas access to information about the progress of arequirement/requisition.

(viii) SupplierInvoiceItemAccounting Package

The SupplierInvoiceItemAccountingObjectSetAssignment package 47349groups together account assignment information for Accounting. TheAccounting package 47349 contains an AccountingObjectSetAssignmententity 47380. The SupplierInvoiceItemAccounting package 47349 containsinformation about account assignment objects in Accounting to which aninvoice item refers. An account assignment can be divided up (inpercentage form) among different objects (e.g. cost center, order,etc.). In some implementations, the total of the various assignmentsmust be 100%.

The AccountingObjectSetAssignment entity 47380 is the assignment of aninvoice item net amount or of a partial amount (i.e. a percentage,value-based, or quantity-based amount) to a set of account assignmentobjects (AccountingObjectSet). The AccountingObjectSetAssignment entity47380 is of type GDT: AccountingObjectSetAssignment. In someimplementations, the AccountingObjectSetAssignment entity 47380 is notused in the InvoiceMessage. For example, 40% of the invoice item amountcan be assigned to cost center CC1000 and profit center PC3050, and theremaining 60% to sales order 100002345.

(ix) SupplierInvoiceItemAttachment Package

The SupplierInvoiceItemAttachment package 47350 groups togetherattachment information relating to the invoice that differ from theattachment information specified at SupplierInvoice level. TheAttachment package 47350 contains an Attachment entity 47381. Thisentity performs operations analogous to the entity of the same namewithin the Attachment package 47314.

(x) SupplierInvoiceItemDescription Package

The SupplierInvoiceItemDescription package 47351 groups togetherexplanatory texts relating to the invoice that differ from the texts atSupplierInvoice level. The Description package 47351 contains theentities: Description entity 47382 and ConfirmedDescription entity47383. These entities perform operations analogous to the entities ofthe same name within the Description package 47315.

(6) Message Data Type: SupplierInvoiceSettlementReleaseRequestMessage

FIG. 474 depicts a data model of the message data typeSupplierInvoiceSettlementReleaseRequestMessage. The message data typeSupplierInvoiceSettlementReleaseRequestMessage contains the businessinformation that is relevant for sending a business document in amessage. A SupplierInvoiceSettlementReleaseRequestMessage package 47402contains the packages: MessageHeader package 47404 and SupplierInvoicepackage 47406. The SupplierInvoiceSettlementReleaseRequestMessagepackage 47402 also contains aSupplierInvoiceSettlementReleaseRequestMessage entity 47408. The messagedata type SupplierInvoiceSettlementReleaseMessage thus provides thestructure for the message type SupplierInvoiceSettlementReleaseRequestand the interfaces that are based on it.

(a) MessageHeader Package

The MessageHeader package 47404 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader package 47404 is not required for theSupplierInvoiceSettlementReleaseRequest message.

(b) SupplierInvoice Package

The SupplierInvoice package 47406 groups together invoices. TheSupplierInvoice package 47406 contains a SupplierInvoice entity 47410.

The SupplierInvoice entity 47410 in the view required for theSupplierInvoiceSettlementReleaseRequest contains the information that isnecessary to request the release of an accepted invoice for settlement.There is a 1:1 relationship between theSupplierInvoiceSettlementReleaseRequestMessage entity 47408 and theSupplierInvoice entity 47410. The SupplierInvoice entity 47410 containsa BillToID element. The BillToID element is a unique identifier that isassigned to the invoice by the invoice recipient and is of type GDT:BusinessTransactionDocumentID. The SupplierInvoice entity 47410 is oftype GDT: SupplierInvoiceSettlementReleaseRequest. In someimplementations, the BillToID element must be specified.

(7) Message Data Type:SupplierInvoiceCancellationExecutionRequestMessage

FIG. 475 depicts a data model of the message data typeSupplierInvoiceCancellationExecutionRequestMessage. The message datatype SupplierInvoiceCancellationExecutionRequestMessage contains thebusiness information that is relevant for sending a business document ina message. A SupplierInvoiceCancellationExecutionRequestMessage package47502 contains the packages: MessageHeader package 47504 andSupplierInvoice package 47506. The message data typeSupplierInvoiceCancellationMessage thus provides the structure for themessage type SupplierInvoiceCancellationExecutionRequest and theinterfaces that are based on it.

(a) MessageHeader Package

The MessageHeader package 47504 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader package 47504 is not required for theSupplierInvoiceCancellationExecutionRequest message.

(b) SupplierInvoice Package

The SupplierInvoice package 47506 groups the SupplierInvoice. TheSupplierInvoice package 47506 contains a SupplierInvoice entity 47510.

The SupplierInvoice entity 47510 in the view required for theSupplierInvoiceCancellationExecutionRequest contains the informationthat is necessary to request the deletion of a SupplierInvoice. There isa 1:1 relationship between theSupplierInvoiceCancellationExecutionRequestMessage entity 47508 and theSupplierInvoice entity 47510.The SupplierInvoice entity 47510 containsan ID element. The ID element is a unique identifier for a procurementinvoice. The ID is of type GDT: BusinessTransactionDocumentID. TheSupplierInvoice entity 47510 is of type GDT:SupplierInvoiceCancellationExecutionRequest.

(8) Message Data Type: InvoiceMessage

FIGS. 476A-D depict a data model of the message data typeInvoiceMessage. The message data type InvoiceMessage groups together thebusiness information that is relevant for sending an invoice in a B2Bbusiness process between business partners. An InvoiceMessage package47601 contains a MessageHeader package 47602 and an Invoice package47603 as well as an InvoiceMessage entity 47604.

The following rules apply to the use and changing of elements orentities in the message data type InvoiceMessage within an invoicingprocess:

Data relating to the InvoiceRequest cannot be changed in theInvoiceConfirmation. The additional information passed on is the invoiceconfirmation status and a description of the invoice recipient.

If the use of certain elements or entities of the InvoiceMessage messagedata type is not permitted in a message type that is based on theInvoiceMessage message data types, this can be specified explicitly inthe “Notes” section.

The message data type InvoiceMessage thus provides the structure for themessage types InvoiceRequest and InvoiceConfirmation, and the interfacesthat are based on them.

(a) MessageHeader Package

The MessageHeader package 47602 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader package 47602 contains a MessageHeader entity 47605 TheMessageHeader entity 47605 groups together the following businessinformation from the perspective of the sending application: informationfor identifying the business document in a message, information aboutthe sender, and, if necessary, information about the recipient. TheMessageHeader entity 47605 is broken down into the following entities:SenderParty entity 47606 and RecipientParty entity 47607. TheMessageHeader entity 47605 is of type GDT:BusinessDocumentMessageHeaderParty. The MessageHeader entity 47605contains the following elements: ID, ReferenceID, and CreationDateTime.The ID is a means of identifying a business document in a technicalmessage and is of type GDT: BusinessDocumentMessageID. The ReferenceIDis a means of identifying another instance of a business document in atechnical message that the current business document references and isof type GDT: BusinessDocumentMessageID. The CreationDateTime is a dateon which a business document in a technical message was generated and isof type GDT: DateTime. The MessageID is set by the sending application,and may not be required in the InvoiceInformationMessage message datatype.

The SenderParty entity 47606 is the party that is responsible forsending a business document at business application level. TheSenderParty entity 47606 is of type GDT:BusinessDocumentMessageHeaderParty. The SenderParty entity 47606 can bespecified by the sending application; in this way, it can name a contactperson for any problems that arise with the message. This can used whenthere is an additional infrastructure, such as a marketplace, betweenthe sender and the recipient. The SenderParty entity 47606 only plays anauxiliary role during message transfer, and so can be ignored by therecipient application. However, it can be specified by the senderespecially if the participating partners are not transmitted with theInvoice package.

The RecipientParty entity 47607 is the party that is responsible forreceiving a business document at business application level. TheRecipientParty entity 47607 is of type GDT:BusinessDocumentMessageHeaderParty. The RecipientParty entity 47607 canbe specified by the sending application; in this way, it can name arecipient contact person for any problems that arise with the message.This can be used when there is an additional infrastructure, such as amarketplace, between the sender and the recipient. The RecipientPartyentity 47607 only plays an auxiliary role during message transfer, andso can be ignored by the recipient application. However, it can bespecified by the sender especially if the participating partners are nottransmitted with the Invoice package.

(b) Invoice Package

The Invoice package 47603 summarizes invoice information that isrequired for a B2B invoicing process. The Invoice is a list of payablesand receivables for delivered goods and rendered services which have tobe paid for by a certain time.

Apart from “SupplierInvoice” changing to “Invoice,” the Invoice package47603 in the InvoiceMessage message data type is analogous to theSupplierInvoice package 47303 in the SupplierInvoiceInformationMessagemessage data type, but does not contain the following components:ProjectReference and ProjectElementAssignment entities inBusinessTransactionDocumentReference package 47648, and Accountingpackage in InvoiceItem package 47616.

(a) Element Structure for Invoice

The message data type element structure for the Invoice message isdepicted in FIG. 477A-J. The element structure is similar to the datamodel, but provides additional information regarding the details of theinterface. The element structure identifies the different packages 47700in the interface, and represents the entities at various levels withinthe interface. As depicted in FIG. 477A, the interface for InvoiceMessage includes five levels 47702, 47704, 47706, 47708, and 47710. Theoutermost package of this interface is a Invoice package 47718, whichincludes a Invoice entity 47720 at the first level 47702. The Invoiceentity 47720 is of a data type MDT 47722 “InvoiceMessage” 47724.

The Invoice message package 47718 includes a MessageHeader package 47728and an Invoice package 47790. The MessageHeader package 47728 includes aMessageHeader entity 47730. The MessageHeader entity 47730 is a GDT47734 “MessageHeader” 47736, and there is either zero of one 47732MessageHeader entity 47730 for each MessageHeader package 47728. TheMessageHeader entity 47730 includes an ID 47740, a ReferenceID 47750, aCreationDateTime 47760, a SenderParty 47770, and a Recipient 47780. TheID 47740 is a GDT 47744 “MessageID” 47744, and there is one ID 47740 fora MessageHeader entity 47730. The Reference ID 47750 is a GDT 47754“MessageID” 47756, and there is either zero or one 47752 Reference ID47750 for a MessageHeader entity 47730. The CreationDateTime 47760 is aGDT 47764, and there is one 47762 for a CreationDateTime 47760MessageHeader entity 47730. The SenderParty 47770 is a GDT 47774“BusinessDocumentMessageHeaderParty” 47776, and there is either zero orone 47772 SenderParty 47770 for a MessageHeader entity 47730. TheRecipient Party 47780 is a GDT 47784“BusinessDocumentMessageHeaderParty” 47786, and there is either zero orone 47782 RecipientParty 47780 for a MessageHeader entity 47730.

The Invoice package 47790 includes an Invoice entity 47792. There is one47794 Invoice entity 47792 for each Invoice package 47790. The Invoiceentity 47792 is an ID 47798, a BillToID 47708A, a TypeCode 47718A, aDateTime 47728A, a CancellationInvoiceIndicator 47738A, anAcceptanceStatusCode 47748A, a Note 47758A at the third level. The ID47798 is a GDT 47702A “BusinessTransactionDocumentID” 47704A, and thereis one 47700A ID 47798 for an Invoice entity 47792. The BillToID 47708Ais a GDT 47712A “BusinessTransactionDocumentID” 47714A, and there iseither zero or one 47710A BillToID 47708A for an Invoice entity 47792.The TypeCode 47718A is a GDT 47722A“BusinessTransactionDocumentTypeCode” 47724A, and there is one 47720ATypeCode 47718A for an Invoice entity 47792. The DateTime 47728A is GDT47732A “DateTime” 47734A, and there is one 47720A DateTime 47728A for anInvoice entity 47792. The CancellationInvoiceIndicator 47738A is a GDT47742A “InvoiceCancellationInvoice” 47744A, and there is either zero orone 47740A CancellationInvoiceIndicator 47739A for an Invoice entity47792. The AcceptanceStatusCode 47748A is a GDT 47752A“AcceptanceStatusCode” 47754A, and there is either zero or one 47750AAcceptanceStatusCode 47748A for an Invoice entity 47792. The Note 47758Ais a GDT 47762A “Note” 47764A, and there is either zero or one 47760ANote 47758A for an Invoice entity 47792.

The Invoice package 47790 includes a Party package 47768A, a Locationpackage 47770B, a Delivery Information package 47792B, a PriceInformation package 47742C, a Tax package 47790C, an Attachment package47702D, a Description package 47712D, and an Item package 47734D. TheParty package 47768A includes a BillToParty 47770A, a BillFromParty47780A, a BuyerParty 47790A, a SellerParty 47700B, ProductRecipientParty47710B, a VendorParty 47720B, a ManufacturerParty 47730B, a PayerParty47740B, a PayeeParty 47750B, and a CarrierParty 47760B. The BillToParty47770A is a GDT 47774A “BusinessTransactionDocumentParty” 47776A, andthere is one 47772A BillToParty 47770A for each Party 47768A. TheBillFromParty 47780A GDT 47784A “BusinessTransactionDocumentParty”47776A, and there is one 47782A BillFromParty 47780A for each Party47768A. The BuyerParty 47790A GDT 47794A“BusinessTransactionDocumentParty” 47796A, and there is either zero orone 47792A BuyerParty 47790A for each Party 47768A. The SellerParty47700B is a GDT 47704B “BusinessTransactionDocumentParty” 47706B, andthere is either zero or one 47702B SellerParty 47700B for each Party47768A. The ProductRecipientParty 47710B GDT 47714B“BusinessTransactionDocumentParty” 47716B, and there is either zero orone 47712B ProductRecipientParty 47710B for each Party 47768A. TheVendorParty 47720B GDT 47724B “BusinessTransactionDocumentParty” 47726B,and there is either zero or one 47722B VendorParty 47720B for each Party47768A. The ManufacturerParty 47730B is a GDT 47734B“BusinessTransactionDocumentParty” 47736B, and there is either zero orone 47732B ManufacturerParty 47730B for each Party 47768A. ThePayerParty 47740B is a GDT 47744B “BusinessTransactionDocumentParty”47746B, and there is either zero or one 47762B PayerParty 47740B foreach Party 47768A. The PayeeParty 47750B is a GDT 47754B“BusinessTransactionDocumentParty” 47756B, and there is either zero orone 47752B “PayeeParty 47750B for each Party 47768A. The CarrierParty47760B is GDT 47764B “BusinessTransactionDocumentParty” 47766B, andthere is either zero or one 47762B CarrierParty 47760B for each Party47768A.

The Location package 47770B includes a ShipToLocation entity 47772B anda ShipFromLocation 47782B. The ShipToLocation entity 47772B is GDT47776B “BusinessTransactionDocumentParty” 47778B, and there is eitherzero or one 47774B ShipToLocation entity 47772B for each Locationpackage 47770B. The ShipFromLocation entity 47782B is a GDT 47786B“BusinessTransactionDocumentParty” 47788B, and there is either zero orone 47784B ShipFromLocation entity 47782B for each Location package47770B.

The DeliveryInformation entity 47792B includes a DeliveryTerms 47794Bthat is a GDT 47798B “DeliveryTerms” 47700C, and there is either zero orone 47796B DeliveryTerms 47794B for each DeliveryInformation package47792B.

The PaymentInformation package 47704C includes a CashDiscountTerms47706C and a PaymentForm 47716C at the third level. TheCashDiscountTerms entity 47706C is a GDT 47710C “CashDiscountTerms”47712C, and there is either zero or one 47708C CashDiscountTerms entity47706C for each PaymentInformation package 47704C. There is either zeroor one 47718C PaymentForm entity 47716C for each PaymentInformationpackage 47704C. The PaymentForm entity includes a Code 47722C and aPaymentCard 47732C at the fourth level. The Code is a GDT 47726C“PaymentFormCode” 47728C, and there is either zero or one 47724C Code47722C for a PaymentForm entity 47716C. The PaymentCard 47732C is a GDT47736C “PaymentCard” 47738C, and there is either zero or one 47734CPaymentCard 47732C for a PaymentForm 47716C.

The PriceInformation package 47742C includes a Price entity 47744C atthe third level. There is one 47746C Price entity 47744C for eachPriceInformation package 47742C. The Price entity 47744C includes aGrossAmount 47750C, a NetAmount 47760C, a TaxAmount 47770C, and anExchangeRate 47780C at the fourth level. The GrossAmount 47750C is a GDT47754C “Amount” 47756C,and there is one 47752C GrossAmount 47750C for aPrice 47744C. The NetAmount 47760C is a GDT 47764C “Amount” 47766C, andthere is either zero or one 47762C NetAmount 47760C for a Price 47744C.The TaxAmount 47770C is a GDT 47774C “Amount” 47776C, and there iseither zero or one 47772C TaxAmount 47770C for a Price 47744C. TheExchangeRate 47780C is a GDT 47784C “ExchangeRate” 47786C, and there iseither zero or one 47782C ExchangeRate 47780C for a Price 47744C.

The Tax package 47790C includes a ProductTax 47792C. The ProductTaxentity 47792C is a GDT 47796C “ProductTax” 47798C, and there is zero toany number 47706C ProductTax 47792C for each Tax package 47790C.

The Attachment package 47702D includes an Attachment 47704D. TheAttachment entity 47704D is a GDT 47796C “Attachment” 47798C, and thereis zero to any number 47706C Attachment 47704D for each Attachmentpackage 47702D.

The Description package 47712D includes a Description 47714D and aConfirmedDescription 47724D. The Description 47714D is a GDT 47718D“Description” 47720D, and there is either zero or one 47716D Description47714D for each Description package 47712D. The ConfirmedDescription47724D is a GDT 47728D “Description” 47730D, and there is either zero orone 47726D ConfirmedDescription 47724D for each Description package47712D.

The Item package 47734D includes an Item entity 47736D. There is one toany number 47738D Item entity 47736D for each Item package 47734D. TheItem entity 47736D includes an ID 47742D, a BillToID 47752D, a TypeCode47762D, a Quantity 47772D, a Hierarchy Relationship 47782D, and aDeliveryPeriod 47708E at the fourth level. The ID 47742D is a GDT 47746D“BusinessTransactionDocumentID” 47748D, and there is one 47744D ID47742D for an Item entity 47736D. The BillToID 47752D is a GDT 47756D“BusinessTransactionDocumentID” 47758D, and there is either zero or one47754D BillToID 47752D for an Item entity 47736D. The TypeCode 47762D isa GDT 47746D “BusinessTransactionDocumentID” 47748D, and there is one47764D TypeCode 47762D for an Item entity 47736D. The Quantity 47772D isa GDT 47776 “Quantity” 47778, and there is either zero or one 47674Quantity 47772D for an Item entity 47736D. There is either zero or oneHierarchy Relationship 47586D for each Item entity 47762D.

The HierarchyRelationship 47782D includes a Parent Item ID 47788D and aType Code 47798D at the fifth level. The Parent Item ID 47788D is a GDT47792D “BusinessTransactionDocumentItemID” 47794D, and there is one47790D Parent Item ID 47788D for a HierarchyRelationship 47782D. TheType Code 47798D is a CDT 47702E“BusinessTransactionDocumentItemHierarchyRelationshipTypeCode” 47704 e,and there is one 47700E Type Code 47798D for a HierarchyRelationship47782D.

The DeliveryPeriod 47708E is a GDT 47712E “DateTimePeriod” 47714E, andthere is either zero or one 47710E DeliveryPeriod 47708E for an Itementity 47736D.

The ProductInformation package 47718E includes a Product entity 47720Eand a ProductCategory entity 47730E. The Product entity 47720E is a GDT47724E “BusinessTransactionDocumentProduct” 47726E, and there is eitherzero or one 47722E Product entity 47720E for each Product Information47718E. The ProductCategory entity 47730E is a GDT 47734E“BusinessTransactionDocumentProductCategory” 47736E, and there is eitherzero or one 47732E ProductCategory entity 47730E for each ProductInformation package 47718E.

There is one 47746C Price entity 47742E for each PriceInformationpackage 47740E. The Price entity 47742E includes a GrossAmount 47748E, aNetAmount 47758E, a TaxAmount 47768E, a NetUnitPrice 47778E, anExchangeRate 47788E, a PriceDate 47798E, and a Component 47708F at thefifth level. The GrossAmount 47748E is a GDT 47752E “Amount” 47754E,andthere is one 47750E GrossAmount 47748E for a Price 47742E. The NetAmount47758E is a GDT 47762E “Amount” 47764E, and there is either zero or one47760E NetAmount 47758E for a Price 47742E. The TaxAmount 47768E is aGDT 47772E “Amount” 47774E, and there is either zero or one 47770ETaxAmount 47768E for a Price 47742E. The NetUnitPrice 47778E is a GDT47782E “Price” 47784E, and there is either zero or one NetUnitPrice477C78E for a Price entity CC42E. The ExchangeRate 47788C is a GDT47792E “ExchangeRate” 47794E, and there is either zero or one 47790EExchangeRate 47788E for a Price 47742E. The PriceDate 47798E is a GDT47702F “Date” 47704F, and there is either zero or one 47700F PriceDate47798F for a Price 47742E. The Component 47708F is a GDT 47712F“PriceComponent” 47714F, and there is zero to any number 47710FComponent 47708F for a Price 47742E.

The Tax package 47718F includes a ProductTax 47720F that is a GDT 47724F“ProductTax” 47726F, and there is zero to any number 47722F Product Tax47720F for each Tax package 47718F.

The Party package 47730F includes a BuyerParty 47732F, a SellerParty47742F, ProductRecipientParty 47752F, a VendorParty 47762F, aManufacturerParty 47772F, and a CarrierParty 47782F. The BuyerParty47732F GDT 47736F “BusinessTransactionDocumentParty” 47738F, and thereis either zero or one 47734F BuyerParty 47732F for each Party package47730F. The SellerParty 47742F is a GDT 47746F“BusinessTransactionDocumentParty” 47748F, and there is either zero orone 47744F SellerParty 47742F for each Party package 47730F. TheProductRecipientParty 47750F GDT 47756F“BusinessTransactionDocumentParty” 47758F, and there is either zero orone 47754F ProductRecipientParty 47752F for each Party package 47730F.The VendorParty 47762F GDT 47766F “BusinessTransactionDocumentParty”47768F, and there is either zero or one 47764F VendorParty 47762F foreach Party package 47730F. The ManufacturerParty 47772F is a GDT 47776F“BusinessTransactionDocumentParty” 47778F, and there is either zero orone 47774F ManufacturerParty 47772F for each Party package 47730F. TheCarrierParty 47782F is a GDT 47786F “BusinessTransactionDocumentParty”47788F, and there is either zero or one 47784F The CarrierParty 47782Ffor each Party package 47730F.

The Location package 47792F includes a ShipToLocation 47794F and aShipFromLocation 47704G at the fourth level. The ShipToLocation 47794Fis GDT 47798F “BusinessTransactionDocumentLocation” 47700G, and there iseither zero or one 47796F ShipToLocation 47794F for each Locationpackage 47792F. The ShipFromLocation 47704G is a GDT 47708G“BusinessTransactionDocumentLocation” 47710G, and there is either zeroor one 47706G ShipFromLocation 47704G for each Location package 47792F.

The DeliveryInformation 47714G includes a Delivery Terms 47716G that isa GDT 47720G “DeliveryTerms” 47722G, and there is either zero or one47718G DeliveryTerms 47716G for each Delivery Information 47714G.

The BusinessTransactionDocumentReference 47726G includes aPurchaseOrderReference 47728G, a SalesOrderReference 47738G, aDeliveryReference 47748G, a Service AcknowledgtementReference 47758G, aOriginInvoiceReference 47768G, a PurchaseContractReference 47778G, aSalesContractReference 47788G, a BuyerProductCatalogReference 47798G,and a SellerProductCatalog 47708H at the fourth level. ThePurchaseOrderReference 47728G is a GDT 47732G“BusinessTransactionDocumentReference” 47734G, and there is zero to anynumber 47730G PurchaseOrderReference 47728G for eachBusinessTransactionDocumentReference package 47726G. TheSalesOrderReference 47738G is a GDT 47742G“BusinessTransactionDocumentReference” 47744G, and there is zero to anynumber 47740G SalesOrderReference 47738G for eachBusinessTransactionDocumentReference 47726G. The DeliveryReference47748G is a GDT 47752G “BusinessTransactionDocumentReference” 47754G,and there is either zero or one 47750G DeliveryReference 47748G for eachBusinessTransactionDocumentReference 47726G. TheServiceAcknowledgementReference 47758G is a GDT 47762G“BusinessTransactionDocumentReference” 47774G, and there is either zeroor one 47760G ServiceAcknowdgementReference 47758G for eachBusinessTransactionDocumentReference 47726G. The OriginInvoiceReference47768G is a GDT 47772G “BusinessTransactionDocumentReference” 47774G,and there is either zero or one 47770G OriginInvoiceReference 47768G foreach BusinessTransactionDocumentReference 47726G. ThePurchaseContractReference 47778G is a GDT 47782G“BusinessTransactionDocumentReference” 47784G, and there is either zeroor one 47780G PurchaseContractReference 47778G for eachBusinessTransactionDocumentReference 47726G. The SalesContractReference47788G is a GDT 47792G “BusinessTransactionDocumentReference” 47794G,and there is either zero or one 47790G SalesContractReference 47788G foreach BusinessTransactionDocumentReference package 47726G. TheBuyerProducatCatalogReference 47798G is a GDT 47702H“CatalogueReference” 47704H, and there is either zero or one 47700HSellerProducatCatalogReference 47798G for eachBusinessTransactionDocumentReference package 47726G. TheSellerProducatCatalogReference 47708H is a GDT 47712H“CatalogueReference” 47701H, and there is either zero or one 4771 0HSellerProducatCatalogReference 47708H for eachBusinessTransactionDocumentReference package 47726G.

The Attachment package 47718H includes an Attachment entity 47720H thatis a GDT 47724H “Attachment” 47726H, and there is from zero to anynumber 47722H Attachment entity 47720H for each Attachment package47718H.

The Description package 47730H includes a Description 47732H and aConfirmedDescription 47742H. The Description 47732H is a GDT 47736H“Description” 47738H, and there is either zero or one 47734H Description47732H for each Description package 47730H. The ConfirmedDescription47742H is a GDT 47746H “Description” 47748H, and there is either zero orone 47744H ConfirmedDescription 47742H for each Description package47730H.

kk) Loan Contract Interfaces

LoanContract Interfaces can be used to implement a financial servicesbusiness process that provides an integrated customer-oriented solutionfor processing a loan contract creation request between businessapplications or entities (e.g., Contract Origination entity 47802 andLoan Management entity 47804 in FIG. 478). The LoanContract Interfacesare based on the following message types: a LoanCalculationQueryMessage,a LoanCalculationResponseMessage, a LoanContractCreateRequestMessage,and a LoanContractCreateConfirmationMessage.

The motivating business scenario for LoanContract Interfaces are thefinancial services business scenario “Contract Origination” whichrepresents an integrated customer-oriented solution ranging from thebank counter (mySAP CRM) to the back office (mySAP Banking/mySAPInsurance). Financial contracts originate in CRM. Loan contracts areconducted as part of loan origination. Loans are processed in SAPsolutions (e.g., mySAP Banking or mySAP Insurance) or in legacy systems.

(1) Message Type(s)

(a) Loan Calculation Query

A LoanCalculationQuery is a query made to a loan management system(e.g., Loan Management (CML) 47804 in FIG. 478) requesting a loancalculation. The message data type LoanCalculationQueryMessage definesthe structure of the message type LoanCalculationQuery.

(b) Loan Calculation Response

A LoanCalculationResponse is a response from the loan management systemto the query requesting a loan calculation. The LoanCalculationResponseincludes a responsive LoanCalculation. The message data typeLoanCalculationResponseMessage defines the structure of the message typeLoanCalculationResponse.

(c) Loan Contract Create Request

A LoanContractCreateRequest is a request for the loan management systemto create a loan contract. The message data typeLoanContractCreateRequestMessage defines the structure of the messagetype LoanContractCreateRequest.

(d) Loan Contract Create Confirmation

A LoanContractCreateConfirmation is a confirmation from the loanmanagement system stating whether a loan contract has been created. Themessage data type LoanContractCreateConfirmationMessage defines thestructure of the message type LoanContractCreateConfirmation.

(2) Message Choreography

FIG. 478 depicts an exemplary message choreography for a loan contractcreation process between business applications or entities (e.g.,Contract Origination entity 47802 and Loan Management (or CML) entity47804) implementing Loan Contract Interfaces in accordance with thesubject matter described herein. In the implementation shown in FIG.478, the Contract Origination entity 47802 initiates the loan contractcreation process by sending a LoanCalculationQuery 47806 to the LoanManagement entity 47804. In response, the Loan Management entity 47804sends a LoanCalculationResponse 47808 to the Contract Origination entity47802. The LoanCalculationResponse 47808 includes a responsiveLoanCalculation that may be processed by the Contract Origination entity47802 before the Contract Origination entity 47802 sends aLoanContractCreateRequest 47810 to the Loan Management 47804. Inresponse, the Loan Management 47804 sends aLoanContractCreateConfirmation 47812 to the Contract Origination entity47802 to confirm the loan creation in accordance with the subject matterdescribed herein.

(3) Message Data Type Loan Calculation Query Message

FIG. 479 depicts a data model of the message data typeLoanCalculationQueryMessage. The message data typeLoanCalculationQueryMessage groups the Business information that isrelevant for sending the business document in a message and the objectLoanCalculationQuery included in the business document. As shown in FIG.479, message data type LoanCalculationQuery Message includes aLoanCalculationQueryMessage package 47902, which includes aMessageHeader package 47904, a LoanCalculationQuery package 47906, and aLoanCalculationQueryMessage entity 47908.

(a) Message Header Package

The MessageHeader package 47904 groups business information from thepoint of view of the sender application (e.g., Contract Originationentity 47802) that is relevant for sending the business document in amessage. The MessageHeader package 47904 includes a MessageHeader entity47910. There is a 1:1 relationship between theLoanCalculationQueryMessage entity 47908 and the MessageHeader entity47910. Where a relationship is identified between entitites in FIG. 479for this Interface, the respective relationship is a 1:1 relationshipunless otherwise noted herein or indicated in FIG. 479. TheMessageHeader package 47904 also includes a SenderParty entity 47912 anda RecipientParty entity 47914. There is a 1:c relationship between theMessageHeader entity 47910 and the SenderParty entity 47912 and betweenthe MessageHeader entity 47910 and the RecipientParty entity 47914.

The SenderParty 47912 is the party responsible for sending a businessdocument at the business application level. The SenderParty entity 47912is of type GDT: BusinessDocumentMessageHeaderParty. There is a 1:crelationship between the MessageHeader entity 47910 and the SenderPartyentity 47912.

The RecipientParty 47914 is the party responsible for receiving abusiness document at the business application level. The RecipientPartyentity 47914 is of type GDT: BusinessDocumentMessageHeaderParty. Thereis a 1:cn relationship between the MessageHeader entity 47910 and theRecipientParty entity 47914.

The MessageHeader entity 47910 is of the type GDT:BusinessDocumentMessageHeader and, in one implementation, uses an IDelement and a ReferenceID element.

(b) Loan Calculation Query Package

The LoanCalculationQuery package 47906 includes a ProductInformationpackage 47916, a LoanConditionInformation package 47918, and aLoanCalculationQuery entity 47920.

The LoanCalculationQuery entity 47920 describes the query request for aloan calculation. The LoanCalculationQuery entity 47920 includesinformation about the loan to be calculated, loan conditions, and typeof calculation to be made. In one implementation, theLoanCalculationQuery entity 47920 includes the following elements: aLoanKeyFigureTypeCode, a MaturityPeriod, a FixedInterestPeriod, anAmount, an EffectiveYieldCalculationMethodCode, a DisagioPercent, and aDisagioDeductionEventTypeCode. The LoanKeyFigureTypeCode identifieswhich calculation is to be made in the loan management system and is oftype GDT: LoanKeyFigureTypeCode. The MaturityPeriod is a term of therequested loan and is of type GDT: DatePeriod. The FixedInterestPeriodis a fixed interest rate period for the requested loan and is of typeGDT: DatePeriod. The Amount is the requested loan amount and is of typeGDT: Amount. The EffectiveYieldCalculationMethodCode is a calculationmethod to determine the effective interest rate and is of type GDT:EffectiveYieldCalculationMethodCode. The DisagioPercent is a disagiopercent (e.g., charge made for exchanging depreciated or foreign money)of the requested loan and is of type GDT: DisagioPercent. TheDisagioDeductionEventTypeCode identifies an event in which a deductioncorresponding to the DisagioPercent is to be applied. TheDisagioDeductionEventTypeCode is of type GDT:DisagioDeductionEventTypeCode.

In one implementation, the elements LoanKeyFigureTypeCode,FixedInterestPeriod, and Amount are required and the other elements areoptional.

(i) Loan Calculation Query Product Information Package

The LoanCalculationQuery ProductInformation package 47916 groupsinformation about the product upon which the loan is based. TheLoanCalculationQuery ProductInformation package 47916 includes aProductCategory entity 47922 and a Product entity 47924.

The ProductCategory entity 47922 identifies which (financial) productcategory the loan is based. The ProductCategory entity 47922 may beused, for example, to differentiate between real estate and consumerloans. The ProductCategory entity 47922 is of the type GDT:BusinessTransactionDocumentProductCategory.

The Product entity 47924 identifies which (financial) product the loanis based. The Product entity 47924 may also describe the sales-relevantdesign (special offers for special target groups) of the loan. TheProduct entity 47924 is of the type GDT:BusinessTransactionDocumentProduct. There is a 1:c relationship betweenthe LoanCalculationQuery entity 47920 and the Product entity 47924.

(ii) Loan Calculation Query Loan Condition Information Package

The LoanCalculationQuery LoanConditionInformation package 47918 groupsconditions for a loan. The conditions serve as a basis for calculating apayment plan by the recipient (e.g., Loan Management 47804). Theconditions, however, may differ from the conditions agreed upon in theloan contract as identified in the message data typeLoanContractCreateRequest discussed below. The LoanCalculationQueryLoanConditionInformation package 47918 includes a LoanInterestConditionentity 47926, a LoanAmortizementCondition 47928, and a LoanFeeConditionentity 47930. There is a 1:cn relationship between theLoanCalculationQuery 47920 and each of the LoanInterestCondition entity47926, the LoanAmortizementCondition 47928, and the LoanFeeConditionentity 47930.

The LoanInterestCondition entity 47926 is an interest condition for aloan and is of type GDT: LoanInterestCondition. TheLoanAmortizementCondition 47928 is a repayment condition for a loan andis of type GDT: LoanAmortizementCondition. The LoanFeeCondition entity47930 is a fee condition for a loan and is of the type GDT:LoanFeeCondition.

(4) Message Data Type Loan Calculation Response Message

FIG. 480 depicts a data model of the message data typeLoanCalculationResponseMessage. The message data typeLoanCalculationResponseMessage provides the structure for messages ofthe type LoanCalculationResponse. The message data typeLoanCalculationResponseMessage groups business information that isrelevant for sending the business document in a message and an objectLoanCalculation contained in the business document. As shown in FIG.480, message data type LoanCalculationResponseMessage includes aLoanCalculationMessage package 48002, which includes a MessageHeaderpackage 48004, a LoanCalculation package 48006, and aLoanCalculationMessage entity 48008.

(a) Message Header Package

The MessageHeader package 48004 groups business information that isrelevant for sending the business document in a message from the pointof view of the sender (e.g., Loan Management entity 47804). TheMessageHeader package 48004 includes a MessageHeader entity 48010, aSenderParty entity 48012, and a RecipientParty entity 48014, each ofwhich are similar to and have the same relationships as the similarlynamed entities described above for the MessageHeader package 47904 inthe LoanCalculationQueryMessage package 47902. There is a 1:1relationship between the LoanCalculationMessage entity 48008 and theMessageHeader entity 48010. Where a relationship is identified betweenentitites in FIG. 480 for this Interface, the respective relationship isa 1:1 relationship unless otherwise noted herein or indicated in FIG.480.

(b) Loan Calculation Package

The LoanCalculation package 48006 includes a PaymentPlan package 48016and a LoanCalculation entity 48018. The LoanCalculation entity 48018describes the results of a loan calculation responsive to theLoanCalculationQuery. The LoanCalculation entity 48018 includes thefollowing elements: a MaturityPeriod, an EffectiveYieldPercent, anEffectiveYieldCalculationMethodCode, and an InstallmentAmount. TheMaturityPeriod is a term of the loan and is of type GDT: DatePeriod. TheEffectiveYieldPercent identifies an effective interest rate for theloan. The EffectiveYieldPercent is of type GDT: Percent. TheEffectiveYieldCalculationMethodCode is a calculation method used todetermine the effective interest rate for the loan. TheEffectiveYieldCalculationMethodCode is of type GDT:EffectiveYieldCalculationMethodCode. The InstalmentAmount identifies theloan instalment for repaying the loan, including interest and therepayment amount. The InstalmentAmount is of type GDT: Amount.

(c) Loan Payment Plan Package

The LoanPaymentPlan package 48016 includes a LoanPaymentPlan entity48020 and a LoanPaymentPlanItem entity 48022. There is a 1:crelationship between the LoanCalculation entity 48018 and theLoanPaymentPlan entity 48020 and a 1:n relationship between theLoanPaymentPlan entity 48020 and the LoanPaymentPlanItem entity 48022.

The LoanPaymentPlan 48020 includes the planned payments for the loan.The key attributes of the loan used to calculate the payment plan are:Repayment instalments, Loan amount, Nominal interest rate, Term, Fees,and Effective interest rate.

The LoanPaymentPlanItem 48022 is a payment planned for a key date forthe loan. The LoanPaymentPlanItem 48022 is of the type GDT:LoanPaymentPlanItem.

(5) Message Data Type Loan Contract Create Request Message

FIG. 481A depicts a data model of the message data typeLoanContractCreateRequestMessage. The message data typeLoanContractCreateRequestMessage provides the structure for messages ofthe type LoanContractCreateRequest. The message data typeLoanContractCreateRequestMessage groups business information that isrelevant for sending the business document in a message and an objectLoanContract included in the business document as required to process aLoanConractCreateRequest. As shown in FIG. 481A, message data typeLoanContractCreateRequestMessage includes aLoanContractCreateRequestMessage package 48102, which includes aMessageHeader package 48104, a LoanContract package 48106, and aLoanContractCreateRequestMessage entity 48108.

(a) MessageHeader Package

The MessageHeader package 48104 groups business information that isrelevant for sending the business document in a message from the pointof view of the sender (e.g., Contract Origination entity 47802). TheMessageHeader package 48104 includes a MessageHeader entity 48110, aSenderParty entity 48112, and a RecipientParty entity 48114, each ofwhich are similar to and have the same relationships as the similarlynamed entities described above for the MessageHeader package 47904 inthe LoanCalculationQueryMessage package 47902. There is a 1:1relationship between the LoanContractCreateMessage entity 48108 and theMessageHeader entity 48110. Where a relationship is identified betweenentitites in FIGS. 481A-C for this Interface, the respectiverelationship is a 1:1 relationship unless otherwise noted herein orindicated in FIGS. 481A-C.

(b) Loan Contract Package

The LoanContract package 48106 includes a Party Package 48116, aProductInformation package 48118, a PaymentInformation package 48120, anAttachment package 48122, a LoanContractItem package 48124, and aLoanContract entity 48126.

The LoanContract entity 48126, from the perspective required by theLoanContractCreateRequest, contains all of the information that isrequired for creating a loan contract. The loan is based on loanconditions that define the interest rate, repayment, and fees. Inaddition to the loan conditions, the loan contract entity 48126 includesa description of parties to the contract (e.g., a LenderParty, aBorrowerParty, and, in one implementation, a PayerParty,LoanBrokerParty, and GuarantorParty). The loan contract entity 48126includes payment information and key loan attributes such as start dateand end date of the loan as well as reason for the loan. The loancontract entity 48126 may include an alternative payer with paymentinformation for each condition. The loan contract entity 48126 mayinclude fundamental agreements and documents, such as general terms andconditions, financial statements, personal information, informationabout the financing object, and a collateral agreement.

The LoanContract entity 48126 includes the following elements: aLoanOfferID, a PaymentPlanReference, a LoanPurposeCode, aMaturityPeriod, a FixedInterestPeriod, an Amount, anEffectiveYieldPercent, an EffectiveYieldCalculationMethodCode, aDisagioPercent, and a DisagioDeductionEventTypeCode. The LoanOfferID isa unique identifier of the loan offer from the sender and is of typeGDT: BusinessTransactionDocumentID. The PaymentPlanReference is areference to the associated PaymentPlan and is of type GDT:BusinessTransactionDocumentReference. The LoanPurposeCode identifies thepurpose for the loan and is of type GDT: LoanPurposeCode. TheMaturityPeriod is a term of the requested loan and is of type GDT:DatePeriod. The FixedInterestPeriod is a fixed interest rate period forthe requested loan and is of type GDT: DatePeriod. The Amount is therequested loan amount and is of type GDT: Amount. TheEffectiveYieldPercent identifies an effective interest rate associatedwith the LoanContract. The EffectiveYieldPercent is of type GDT:Percent. The EffectiveYieldCalculationMethodCode is a calculation methodused to determine the effective interest rate for the loan. TheEffectiveYieldCalculationMethodCode is of type GDT:EffectiveYieldCalculationMethodCode. TheEffectiveYieldCalculationMethodCode is a calculation method to determinethe effective interest rate and is of type GDT:EffectiveYieldCalculationMethodCode. The DisagioPercent is a disagiopercent (e.g., charge made for exchanging depreciated or foreign money)of the requested loan and is of type GDT: DisagioPercent. TheDisagioDeductionEventTypeCode identifies an event in which a deductioncorresponding to the DisagioPercent is to be applied. TheDisagioDeductionEventTypeCode is of type GDT:DisagioDeductionEventTypeCode.

In one implementation, the elements FixedInterestPeriod and Amount arerequired and the other elements are optional.

Loan types may be a real estate loan or an installment credit. Realestate loans are loans that are granted to finance real estate andsecured by a mortgage. Real estate loans are usually long-term and areprovided in one amount. Real estate loans may be repaid in annuities,instalments, or in one amount upon due date.

An instalment credit is a consumer loan providing private customers witha medium-term or long-term loan in one amount. An instalment credit isrepaid in equal instalments in accordance with a fixed payment plan.

(i) Loan Contract Party Package

As shown in FIG. 481B, the LoanContractParty package 48116 includes aLenderParty entity 48128, a BorrowerParty entity 48130, a PayerPartyentity 48132, a BrokerParty entity 48134, and a BailsmanParty entity48136.

The LenderParty entity 48128 is a party who grants the loan (lender).The LenderParty entity 48128 is of the type GDT:BusinessTransactionDocumentParty, where, in one implementation, only theelement InternalID is required.

The BorrowerParty entity 48130 is a party who takes up the loan(borrower). The BorrowerParty entity 48130 is of the type GDT:BusinessTransactionDocumentParty, where, in one implemention, only theelement InternalID is required. There is a 1:n relationship between theLoanContract entity 48126 and the BorrowerParty entity 48130. If severalborrowers (BorrowerParty entities 48130) are involved in the loan, thenthe first BorrowerParty entity 48130 is the primary party to thecontract.

The PayerParty 48132 is an alternative party to the BorrowerParty 48130who pays interest, repayments, and fees for a loan. The BorrowerParty48130 pays interest, repayments, and fees when no PayerParty 48132 hasbeen specified. The PayerParty is of the type GDT:BusinessTransactionDocumentParty, where, in one implemention, only theelement InternalID is required. There is a 1:c relationship between theLoanContract entity 48126 and the PayerParty entity 48132.

The BrokerParty 48134 is a party who acts as an agent for issuing theloan. The BrokerParty 48134 is of the type GDT:BusinessTransactionDocumentParty, where, in one implemention, only theelement InternalID is required. There is a 1:cn relationship between theLoanContract entity 48126 and the BrokerParty 48134.

The BailsmanParty 48136 is a party who is responsible for guaranteeingthe loan. The BailsmanParty 48136 is of the type GDT:BusinessTransactionDocumentParty, where, in one implemention, only theelement InternalID is required. The BailsmanParty is liable to thelender if the borrower does not pay. There is a 1:cn relationshipbetween the LoanContract entity 48126 and the BailsmanParty 48136.

(ii) Loan Contract Product Information Package

The LoanContract ProductInformation package 48118 groups informationabout the product upon which the loan is based. The LoanContractProductInformation package 48118 includes a ProductCategory entity 48138and a Product entity 48140.

The ProductCategory entity 48138 identifies which (financial) productcategory the loan is based. The ProductCategory entity 48138 is of thetype GDT: BusinessTransactionDocumentProductCategory. TheProductCategory to differentiate between, for example, real estate andconsumer loans.

The Product entity 48140 identifies which (financial) product the loanis based. The Product entity 48140 is of the type GDT:BusinessTransactionDocumentProduct. There is a 1:c relationship betweenthe LoanContract entity 48126 and the Product entity 48140.

(iii) Loan Contract Payment Information Package

The LoanContract PaymentInformation package 48120 groups the informationabout payment processing associated with the loan. The LoanContractPaymentInformation package 48120 includes a PaymentForm entity 48142 anda BankAccount entity 48144.

The PaymentForm entity 48142 groups information about the payment form.The PaymentForm entity 48142 includes a Code element that is a codedrepresentation of the payment form. The Code is of the type GDT:PaymentFormCode. The following payment forms may be identified by theCode element: a Direct debiting procedure, a Collection authorizationprocedure, a Check, a Bank transfer and a Cash deposit.

The BankAccount entity 48144 identifies information about the bankaccount associated with the payment form. In one implementation, theBankAccount entity 48144 is used with the following payment forms:Direct debiting procedure and Collection authorization procedure. TheBankAccount entity 48144 is of the type GDT:BusinessTransactionDocumentBankAccount. There is a 1:c relationshipbetween the PaymentForm entity 48142 and the BankAccount entity 48144.

(iv) Loan Contract Attachment Package

The LoanContract Attachment package 48122 groups references to documentsthat are relevant for the loan. The LoanContract Attachment package48122 includes the AttachmentWebAddress entity 48146.

The AttachmentWebAddress entity 48146 includes a reference to one ormore documents that are relevant for each loan (e.g., terms andconditions, collateral agreement, and financial statements). TheAttachmentWebAddress is of the type GDT: AttachmentWebAddress. There isa 1:cn relationship between the LoanContract entity 48126 and theAttachmentWebAddress entity 48146.

(v) Loan Contract Item Package

As shown in FIG. 481C, the LoanContract Item package 48124 includes aLoanConditionInformation package 48148, a Party package 48150, aPaymentInformation package 48152, and a LoanContractItem entity 48154.There is a 1:n relationship between the LoanContract entity 48126 andthe LoanContractItem entity 48154.

The LoanContractItem 48154 defines the conditions of the loan. Theconditions may be interest conditions, repayment conditions, or fees. APayerParty entity 48162 and/or a PaymentForm entity 48164 Code may beassociated with each condition.

(a) Loan Contract Item Loan Condition Information Package

The LoanContractItem LoanConditionInformation package 48148 groupsconditions for the loan. The LoanContractItem LoanConditionInformationpackage 48148 includes a LoanInterestCondition entity 48156, aLoanAmortizementCondition entity 48158, and a LoanFeeCondition 48160.There is a 1:c relationship between the LoanContractItem entity 48154and each of the LoanInterestCondition entity 48156, theLoanAmortizementCondition entity 48158, and the LoanFeeCondition 48160.

The LoanInterestCondition 48156 is an interest condition for the loan.The LoanInterestCondition 48156 is of the type GDT:LoanInterestCondition.

The LoanAmortizementCondition entity 48158 is a repayment condition forthe loan. The LoanAmortizementCondition is of the type GDT:LoanAmortizementCondition.

The LoanFeeCondition 48160 is a fee condition for the loan. TheLoanInterestCondition is of the type GDT: LoanInterestCondition.

(b) Loan Contract Item Party Package

A LoanContractItem Party package 48150 includes a PayerParty entity48162, which is similar to the PayerParty entity 48132 associated withthe LoanContract entity 48126. There is a 1:c relationship between theLoanContractItem entity 48154 and the PayerParty entity 48162.

(c) Loan Contract Item Payment Information Package

The LoanContractItem PaymentInformation package 48152 corresponds to theLoanContract PaymentInformation package 48120 and groups the informationabout payment processing for the loan associated with theLoanContractItem 48154. The LoanContractItem PaymentInformation package48152 includes a PaymentForm entity 48164 and a BankAccount entity48166, each of which is similar to the similarly named entities in theLoanContract PaymentInformation package 48120 as described above. Thereis a 1:c relationship between the LoanContractItem entity 48154 and thePaymentForm entity 48164. There is also a 1:c relationship between thePaymentForm entity 48164 and the BankAccount entity 48166.

(6) Message Data Type Loan Contract Create Confirmation Message

FIG. 482 depicts a data model of the message data typeLoanContractCreateConfirmationMessage. The message data typeLoanContractCreateConfirmationMessage provides the structure formessages of the type LoanContractCreateConfirmation. The message datatype LoanContractCreateConfirmationMessage groups business informationthat is relevant for sending the business document in a message and anobject LoanContract included in the business document as required toprocess a LoanConractCreateConfirmation in accordance with the subjectmatter described herein. As shown in FIG. 482, message data typeLoanContractCreateConfirmationMessage includes aLoanContractCreateConfirmationMessage package 48202, which includes aMessageHeader package 48204, a LoanContract package 48206, and aLoanContractCreateConfirmationMessage entity 48208.

(a) MessageHeader Package

The MessageHeader package 48204 includes a MessageHeader entity 48210, aSenderParty entity 48212, and a RecipientParty entity 48214, each ofwhich are similar to and have the same relationships as the similarlynamed entities described above for the MessageHeader package 47904 inthe LoanCalculationQueryMessage package 47902. There is a 1:1relationship between the LoanContractCreateConfimmationMessage entity48208 and the MessageHeader entity 48210.

(b) Loan Contract Package

The Loan Contract package 48206 includes a Log package 48216, aPaymentInformation package 48218, and a LoanContract entity 48220.

The LoanContract entity 48220, from the perspective required by theLoanContractCreateConfirmation, includes information about creating aloan contract in the loan management system (e.g., by the LoanManagemententity 47804). The LoanContract 48220 includes an ID element and aLoanOfferID element. The ID element is a unique identifier of theLoanContract entity 48220 in the recipient system and is of type GDT:BusinessTransactionDocumentID. The LoanOfferID is a unique identifier ofthe loan offer from the sender and is of type GDT:BusinessTransactionDocumentID.

(i) Loan Contract Log Package

The Log package 48216 groups the business log messages that arise when aloan is created. The Log package 48216 includes a Log entity 48222,which includes one or messages that arise when an application associatedwith creating the loan is executed. The Log entity 48222 is of the typeGDT: Log. There is a 1:c relationship between the LoanContract entity48220 and the Log entity 48222.

(ii) Loan Contract Payment Information Package

The LoanContract PaymentInformation package 48218 groups the informationabout payment processing from the perspective required by theLoanContractCreateConfirmation. LoanContract PaymentInformation package48218 includes a BankAccount entity 48224 that includes informationabout the bank account that is to be used for paying the loan similar tothe BankAccount entity 48166 described above. There is a 1:crelationship between the LoanContract entity 48220 and the BankAccountentity 48224.

(7) Element Structure of Loan Contract Create Request Message

The message data type element structure for the loan contract createrequest message is depicted in FIG. 483. The element structure issimilar to the data model, but provides additional information regardingthe details of the interface. The element structure identifies thedifferent packages 48300 in the interface, and represents the entitiesat various levels within the interface. The interface loan contractcreate request message includes six levels 48302, 48304, 48306, 48308,48310, and 48312. The outermost package of this interface is aLoanContractCreateRequestMessage package 48318, which includes aLoanContractCreateRequestMessage entity 48320 at the first level 48302,second level 48304 and the third level 48306. TheLoanContractCreateRequest Message entity 48316 is of a data type MDT48322 “LoanContractCreateRequest Message” 48324.

The LoanContractCreateRequestMessage package 48318 also includes twonested packages: a Message Header package 48326 and a LoanContractpackage 48336. The Message Header package 48326 includes a MessageHeader entity 48328 at the second level. The Message Header entity 48328has zero or one 48330 Message Header entity 48328 for Message Headerpackage 48326. The Message Header entity is of type GDT 48332“BusinessDocumentMessageHeader 48334.

The LoanContract package 48336 includes a LoanContract entity 48338 atthe second level 48304. The LoanContract entity 48338 has one 48340entity for Message Header package 48326 and has a data type name“LoanContractCreateRequest” 48342. The LoanContract entity 48338includes a LoanOfficerID 48344, a LoanPurposeCode 48352, and aMaturityPeriod 48380. The LoanOfficerID 48344 is of type GDT 48348“BusinessTransactionDocumentID” 48350, and there is zero or oneLoanOfficerID for a LoanContract entity 48338. The LoanPurposeCode 48352is of type GDT 48356 “LoanPurposeCode” 48358, and there is zero or oneLoanPurposeCode 48352 for a LoanContract entity 48338. TheMaturityPeriod 48380 is of type GDT 48364 “Date Period” 48366, and thereis zero or one MaturityPeriod 48380 for a LoanContract entity 48338.

As depicted in FIG. 483B, the LoanContract entity 48338 also includes aFixedInterestPeriod 48368, an Amount 48376, an EffectiveYieldPercent48384, an EffectiveYieldCalculationMethodCode 48392, a DisagioPercent48300A, a DisagioDeductionEventTypeCode 48308A, and a LenderParty48318A. For the FixedInterestPeriod 48368, there is one48370FixedInterestPeriod 48368 for a LoanContract entity 48338, the type isGDT 48372 and the name is DatePeriod 48374. There is one 48378 Amountentity 48376 for a LoanContract entity 48338, the type is GDT 48380 andthe name is Amount 48382. There is zero or one 48386EffectiveYieldPercent entity 48384 for a LoanContract entity 48338, thetype is GDT 48388, and the name is Percent 48390. There is zero or one48394 EffectiveYieldCalculationMethodCode entity 48392 for aLoanContract entity 48338, the type is GDT 48396, and the name isEffectiveYieldCalculationMethodCode 48398. There is zero or one 48302ADisagioPercent entity 48300A for a LoanContract entity 48338, the datatype is GDT 48304A, and the name is DisagioPercent 48306A. There is zeroor one 48310A DisagioDeductionEventTypeCode entity 48308A for aLoanContract entity 48338, the type is GDT 48312A, and the name isDisagioDeductionEventTypeCode 48314A.

A Party package 48316A includes a LenderParty entity 48318A. For theLenderParty entity 48318A, there is one 48320A LenderParty entity 48318Afor a LoanContract entity 48338, the type is GDT 48322A, and the name isBusinessTransactionDocumentParty 48324A. FIG. 483C depicts an InternalIDentity 48326A with one 48328A Internal ID entity48326A for a LenderParty48318A. The type is GDT 48330A, and the name is PartyInternalID 48332A.

As depicted in FIG. 483C, the Party package 48316A also includes aBorrowerParty entity 48334A, a PayerParty entity 48350A, a BrokerPartyentity 48366A, and a BailsmanParty entity 48382A in the third level.There may be any number 48336A of BorrowerParty 48334A entity for aLenderParty 48318A, the type is GDT 48338A, and the name isBusinessTransactionDocumentParty 48340A. The BorrowerParty 48334Aincludes an InternalID entity 48342A with a cardinality of one 48344A tothe BorrowerParty 48334A, the type is GDT 48346A, and the name isPartyInternalID 48348A. There is zero or one 48352A PayerParty entity48350A for a LenderParty 48318A, the type is GDT 48354A, and the name isBusinessTransactionDocumentParty 48356A. The PayerParty 48350A includesan InternalID entity 48358A with a cardinality of one 48360A to thePayerParty 48350A, the type is GDT 48362A, and the name isPartyInternalID 48364A. There is zero or one 48368A BrokerParty entity48366A for a LenderParty 48318A, the type is GDT 48370A, and the name isBusinessTransactionDocumentParty 48372A. The BrokerParty 48366A includesan InternalID 48374A with a cardinality of one 48376A to the BrokerParty48366A, the type is GDT 48378A, and the name is PartyInternalID 48380A.There may be any number 48384A of BailsmanParty entity 48382A for aLenderParty 48318A, the type is GDT 48386A, and the name isBusinessTransactionDocumentParty 48388A. The BailsmanParty 48382Aincludes an InternalID entity 48390A with a cardinality of 148392A tothe BailsmanParty 48382A, the type is GDT 48394A, and the name isPartyInternalID 48396A.

As depicted in FIG. 483D, a ProductInformation package 48398A isincluded in the LoanContractCreate Request Message package 48318. TheProductInformation package48398A includes a ProductCategory entity48300B and a Product entity 48308B at the third level. TheProductCategory entity 48300B has a cardinality of one 48302B, the typeis GDT 48304B, and the name isBusinessTransactionDocumentProductCategory 48306B. The Product entity48308B has a cardinality of zero or one 48310B withLoanContractCreateRequestMessage package 48318, the type is GDT 48312B,and the name is BusinessTransactionDocumentProduct 48314B.

The LoanContractCreate Request Message package 48318 also includes aPaymentInformation entity 48316B at the third level. ThePaymentInformation entity 48316B includes a PaymentForm entity 48318Bwith a cardinality of one 48320B to PaymentInformation 48316B. ThePaymentForm entity 48318B includes a Code entity 48322B and aBankAccount entity 48330B. The Code entity 48322B has a cardinality ofone 48324B, the type is GDT 48326B, and the name is PaymentFormCode48328B. The BankAccount entity 48330B has a cardinality of zero or one48332B, the type is GDT 48334B, and the name isBusinessTransactionDocumentBankAccount 48336B.

The LoanContractCreate Request Message package 48318 also includes anAttachment package 48338B. The Attachment package 48338B includes anAttachmentWebAddress entity 48340B with a cardinality including anynumber 48342B of AttachmentWebAddress entities 48340B for aLoanContractCreate Request Message package 48318. The type is GDT48344B, and the name is AttachmentWebAddress 48346B.

As depicted in FIG. 483E, an Item package 48348B includes an Item entity48350B in the first level with a cardinality of any number 48352B ofItem entities 48350B for an Item package 48348B, and the name isLoanContractItem 48354B. The Item package also includesLoanConditionInformation entity 48356B, a Party entity 48382B, and aPaymentInformation 48392B entity. The LoanConditionInformation entity48356B includes a LoanInterestCondition entity 48358B with a cardinalityof zero or one 48360, the type GDT 48362B, and the nameLoanInterestCondition 48364B. The LoanAmortizementCondition entity48366B has a cardinality of zero or one 48368B, the type is GDT 48370B,and the name is LoanAmortizementCondition 48372B. The LoanFeeConditionentity 48374B has a cardinality of zero or one 48376B, the type is GDT48378B, and the name is LoanFeeCondition 48380B.

The Item package 48348B also includes a Party entity 48382B in the firstlevel. The Party entity 48382B includes a PayerParty entity 48384B witha cardinality of zero or one 48385B, the type is GDT 48386B, and thename is BusinessTransactionDocumentParty 48387B. The PayerParty entity48384B includes an InternalID 48388B in the sixth level, with acardinality of one 48389B, the type is GDT 48390B, and the name isPartyInternalID 48391B.

The Item package 48348B also includes a PaymentInformation entity 48392Bin the first level. The PaymentInformation entity 48392B includes aPaymentForm entity 48393B with a cardinality of zero or one 48394. ThePaymentForm entity 48393B includes a Code entity 48395B and aBankAccount entity 48399C. The Code 48395B has a cardinality of zero orone 48396B, the type is GDT 48397B, and the name is PaymentFormCode48398B. The BankAccount entity 48399C has a cardinality of zero or one48300D, the type is GDT 48302D, and the name isBusinessTransactionDocumentBankAccount 48304D.

The message data type element structure for the loan calculation messageis depicted in FIG. 484. The element structure is similar to the datamodel, but provides additional information regarding the details of theinterface. The element structure identifies the different packages 48400in the interface, and represents the entities at various levels withinthe interface. The interface loan calculation message includes fivelevels 48402, 48404, 48406, 48408, and 48410. The outermost package ofthis interface is a LoanCalculationMessage package 48418, which includesa LoanCalculationMessage entity 48420 at the first level 48402. TheLoanCalculationMessage entity 48420 is of a data type MDT 48422“LoanCalculationMessage” 48424.

The LoanCalculationMessage package 48418 includes a MessageHeader entity48426 and a LoanCalculation entity 48436. The MessageHeader 48426includes a MessageHeader entity 48428 that has a cardinality of zero orone 48430, the type is GDT 48432, and the name isBusinessDocumentMessageHeader 48434. the LoanCalculation package 48436includes a LoanCalculation entity 48438 with a cardinality of one and athe name LoanCalculation 48442. The LoanCalculation entity 48438includes a MaturityPeriod entity 48444, an EffectiveYieldPercent entity48452, and an EffectiveYieldCalculationMethodCode entity 48460. TheMaturityPeriod entity 48444 has a cardinality of zero or one 48446, thetype is GDT 48448, and the name is DatePeriod 48450. TheEffectiveYieldPercent entity 48452 has a cardinality of zero or one48454, the type is GDT 48456, and the name is Percent 48458. TheEffectiveYieldCalculationMethodCode entity 48460 has a cardinality ofzero or one 48462, the type is GDT 48464, and the name isEffectiveYieldCalculationMethodCode 48466. As depicted in FIG. 484B, theLoanCalculation entity 48438 also includes an Installment Amount entity48468 with a cardinality of zero or one, the type is GDT 48472, and thename is Amount 48464.

The LoanCalculation Message package 48418 includes a LoanPaymentPlanpackage 48476. The LoanPaymentPlan package 48476 includes aLoanPaymentPlan 48478 with a cardinality of zero or one 48480 and thename is LoanPaymentPlan 48482. the LoanPayment Plan entity 48478includes a LoanPaymentPlanItem entity 48484 having any number 48486 ofLoanPaymentPlanItem entities 48484 for a LoanPaymentPlan entity 48478,the type is GDT 48488, and the name is LoanPaymentPlanItem 48490.

The message data type element structure for the loan contract createconfirmation message is depicted in FIG. 485. The element structure issimilar to the data model, but provides additional information regardingthe details of the interface. The element structure identifies thedifferent packages 48500 in the interface, and represents the entitiesat various levels within the interface. The interface loan calculationmessage includes three levels 48502, 48504, and 48506. The outermostpackage of this interface is a LoanContractCreateConfirmation Messagepackage 48512, which includes a LoanContractCreate Confirmation Messageentity 48514 at the first level 48502. The LoanContractCreateConfirmation Message entity 48514 is data type MDT 48516“LoanContractCreate Confirmation Message” 48518.

The LoanContractCreate Confirmation Message package 48514 includes aMessageHeader entity package 48520. The MessageHeader entity package48520 includes a MessageHeader entity 48522 with a cardinality of one48524, the type is GDT 48526, and the name isBusinessDocumentMessageHeader 48528.

The LoanContractCreateConfirmationMessage package 48512 includes aLoanContract package 48530. The LoanContract package 48530 includes aLoanContract entity 48532 with a cardinality of one 48534 and the nameLoanContractCreateConfirmation 48536. The LoanContract entity 48532includes an ID entity 48538 and a LoanOfferID entity 48546. The ID 48538has a cardinality of zero or one 48540, the type is GDT 48542, and thename is BusinessTransactionDocumentID 48544. The LoanOfferID entity48546 has a cardinality of one 48548, the type is GDT 48550, and thename is BusinessTransactionDocumentID 48552.

The LoanContractCreateConfirmationMessage package 48512 also includes aLog package 48554. The Log package 48554 includes a Log entity 48556with a cardinality of zero or one, the type is GDT 48570, and the nameis Log 48562.

The LoanContractCreateConfirmationMessage package 48512 also includes aPaymentInformation entity 48564. The PaymentInformation entity 48564includes a BankAccount entity 48566 with a cardinality of zero or one48568, the type is GDT 48570 and the name isBusinessTransactionDocumentBankAccount 48572.

The message data type element structure for the loan calculation querymessage 48612 is depicted in FIG. 486. The element structure is similarto the data model, but provides additional information regarding thedetails of the interface. The element structure identifies the differentpackages 48600 in the interface, and represents the entities at variouslevels within the interface. The interface loan calculation messageincludes three levels 48602, 48604, and 48606. The outermost package ofthis interface is a LoanCalculationQueryMessage package 48612, whichincludes a LoanCalculationQueryMessage entity 48614 at the first level48602. The LoanCalculationQueryMessage entity 48614 is of a data typeMDT 48616 “LoanCalculationQueryMessage” 48618.

The LoanCalculationQueryMessage package 48612 includes a MessageHeaderpackage 48620 and a LoanCaculationQuery package 48630. The MessageHeaderpackage 48620 includes a MessageHeader entity 48622 with a cardinalityof zero or one 48624, the type is GDT 48626, and the name isBusinessDocumentMessageHeader 48628. The LoanCalculationQuery package48630 includes a LoanCalculationQuery entity 48632 with a cardinality ofone 48634 and the name LoanCalculationQuery 48636. TheLoanCalculationQuery entity 48632 includes a LoanKeyFigureTypeCodeentity 48638, a MaturityPeriod entity 48646, a FixedInterestPeriodentity 48654, and an Amount entity 48662. The LoanKeyFigureTypeCodeentity 48638 has any number 48640 of LoanKeyFigureTypeCode entities fora LoanCalcuationQuery entity 48632, the type is GDT 48642, and the nameis LoanKeyFigureTypeCode 48644. The MaturityPeriod entity 48646 has acardinality of zero or one 48648, the type is GDT 48650, and the name isDatePeriod 48652. The FixedInterestPeriod entity 48654 has a cardinalityof one 48656, the type is GDT 48658, and the name is DatePeriod entity48660. The Amount entity 48662 has a cardinality of 1 48664, the type isGDT 48666, and the name is Amount 48668.

As depicted in FIG. 486B, the LoanCalculationQuery entity 48632 alsoincludes an EffectiveYieldCalculationMethodCode entity 48670, aDisagioPercent entity 48678, and a DisagioDeductionEventTypeCode entity48686. The EffectiveYieldCalculationMethodCode entity 48670 has acardinality of zero or one 48672, the type is GDT 48674, and the name isEffectiveYieldCalculationMethodCode 48676. The DisagioPercent entity48678 has a cardinality of zero or one 48680, the type is GDT 48682, andthe name is DisagioPercent 48684. The DisagioDeductionEventTypeCodeentity 48686 has a cardinality of zero or one 48688, the type is GDT48690, and the name is DisagioDeductionEventTypeCode 48692.

The LoanCalculationQueryMessage package 48612 also includes aProductioninformation package 48694 and a LoanConditionInformationpackage 48612A. The ProductInformation package 48694 includes aProductCategory entity 48696, and a Product entity 48604A. TheProductCategory entity 48696 has a cardinality of one, 48698, the typeis GDT 48600A, and the name isBusinessTransactionDocumentProductCategory 48602A. The Product entity48604A has a cardinality of zero or one 48606A, the type is GDT 48608A,and the name is BusinessTransactionDocumentProduct 48610A.

The LoanCalculationQueryMessage package 48612 also includes aLoanConditionInformation package 48612A. The LoanConditionInformationpackage 48612A includes a LoanInterestCondition entity 48614A, aLoanAmortizementCondition entity 48622A, and a LoanFeeCondition entity48630A. The LoanInterestCondition entity 48614A has any number 48612A ofLoanInterestCondition entities for a LoanConditionInformation package48616A, the type is GDT 48618A, and the name is LoanInterestCondition48620A. The LoanAmortizementCondition entity 48622A has any number48624A of LoanAmortizementCondition entities for aLoanConditionInformation package 48616A, the type is GDT 48626A, and thename is LoanAmortizementCondition 48628A. The LoanFeeCondition 48630Ahas any number 48632A of LoanFeeCondition entities 48630Afor aLoanConditionInformation package 48616A, the type is GDT 48634A, and thename is LoanFeeCondition 48636A.

11) PurchaseRequest Interfaces

PurchaseRequest interfaces can be used to exchange purchase requisitionsfor products (materials, services) between a requester (an MRPcontroller, for example, in the Procure to Stock (PTS) scenario) and abuyer, and confirmations that these requisitions have been fulfilled.The PurchaseRequest interfaces include a PurchaseRequestRequestinterface or message, and a PurchaseRequestConfimation interface ormessage.

In some implementations, the motivating business scenario for thePurchaseRequestRequest and PurchaseRequestConfirmation interfaces may bea PTS scenario. In the PTS scenario, a planning system (SCP) or the“requester,” generates purchase requisitions that can be procuredexternally by a procurement system (SRM) or the “buyer.”

(1) Message Types

Two messages types may be available for mapping an A2A requisitionprocess: (1) the message type PurchaseRequestRequest is sent from therequester (a requirements planner in the PTS scenario or aplanning/requirements system, for example) to the buyer and can be usedto start a new requirements process. From now on, this document maysimply use the terms ‘requester’ and ‘buyer’; and (2) the message typePurchaseRequestConfirmation may be sent from the buyer to the requester.It can inform the requester of the extent to which the requirement hasbeen fulfilled.

(a) PurchaseRequestRequest

A PurchaseRequestRequest may be a request from a requester asking abuyer to procure products (materials or services) externally. Thestructure of the message type PurchaseRequestRequest may be specified bythe message data type PurchaseRequestMessage. A PurchaseRequestRequestmessage can result in the relevant requisition being created or changedin the procurement system. The procurement system can accept changesmade to a requisition (except for technical errors). If the procurementsystem (buyer) cannot procure a requisition or partial quantity of arequisition (rejection), the procurement system indicates this byoutputting the PurchaseRequestConfirmation message.

(b) PurchaseRequestConfirmation

A PurchaseRequestConfirmation may be a confirmation of the buyer thatinforms the requester of the extent to which a requisition has beenfulfilled. The structure of the message type PurchaseRequestConfirmationcan be specified by the message data type PurchaseRequestMessage. If aprocurement system (buyer) cannot fulfil a requisition or partialquantity of a requisition, the buyer can indicate this by outputting thePurchaseRequestConfirmation message. In some variations, the buyercannot cancel a rejection of a requisition.

(2) Message Choreography

FIG. 487 depicts the message choreography for an exemplary purchaserequisition process. The purchase requisition process uses purchaserequest interfaces (also referred to as purchases requirementinterfaces, see FIGS. 288-290)to exchange purchase requisitions forproducts (such as materials and/or services) between a requester 48702(such as, an MRP controller or SupplyChainPlanning, for example in thePTS scenario) and a buyer 48704 (e.g., Purchasing in FIG. 487), and toexchange confirmations that these requisitions have been fulfilled. Thebuyer 48704 may then interface with a supplier 48706 for actual purchaseof the requested products.

The requester 48702 starts the requisition process by sending aPurchaseRequestRequest message 48708 to the buyer 48704. ThePurchaseRequestRequest message 48708 requests the buyer 48704 to fulfila requisition generated by the requester 48702. The requisition systemuses the PurchaseRequestRequest message 48708 when requisitions arecreated or changed. The buyer 48704 uses the PurchaseRequestConfirmationmessage 48710 to tell the requester 48702 the status of the requisition.For example, the PurchaseRequestConfirmation message 48710 may indicatewhich follow-on documents for each item have been created and how muchof the required quantity has been procured. ThePurchaseRequestConfirmation message 48710 may also include informationregarding whether a requisition or partial quantity of a requisition canno longer be fulfilled.

The PurchaseRequestConfirmation message 48710 may need to becommunicated in specified circumstances. In some variations, if therequirements-generating system manages the relevant follow-on documentsitself or receives a copy of them and can carry out quantity offsettingin the requisition (as in the PTS scenario), the requirements-generatingsystem requires the PurchaseRequestConfirmation message 48710 if therequisition or a remaining quantity can no longer be procured. Theprocurement system sends the PurchaseRequestConfirmation message 48710if a purchase requisition item has been changed (once a purchase orderwith reference to a requisition has been created or changed, forexample). The current procurement status may be transferred in full witheach PurchaseRequestRequest message 48708.

(3) Message Data Type Purchase Request Message

FIG. 488A-D depicts an exemplary data model for thePurchaseRequestRequest 48708. The message data typePurchaseRequestMessage includes a PurchaseRequestMessage package 48800that groups together the business information relevant for sending abusiness document in a message and the PurchaseRequest object or entityin the business document. The PurchaseRequestMessage package 48800includes a MessageHeader package 48802, a PurchaseRequest package 48804,and a PurchaseRequestMessage entity 48806.

The MessageHeader package 48802 groups together the business from theperspective of the sending application (e.g., the requester 48702 inFIG. 487). In some implementations, the MessageHeader package 48802 maybe omitted from or remain empty in the structure of thePurchaseRequestRequest message.

The PurchaseRequest package 48804 includes a Party package 48808, aLocation package 48810, an Item package 48812, and a PurchaseRequestentity 48814. There is a 1:1 relationship between thePurchaseRequestMessage entity 48806 and the PurchaseRequest entity48814.

A PurchaseRequest entity 48814 includes a requester's 48702 requirementfor procuring products (materials or services). The PurchaseRequestentity 48814 is subdivided into PurchaseRequestItems entities 48850 thateach specify a product to be procured or additional information relevantfor such a product, such as information about product category or valuelimits as described below for the PurchaseRequestItem package 48812. Inaddition to the buying party and the seller as well as the proposedseller, additional parties can be involved in the PurchaseRequest asidentified in the Party package 48808. Locations can be specified forthe PurchaseRequest delivery as identified in the Location package48810. PurchaseRequest entity 48814 is of type GDT: PurchaseRequest.

The PurchaseRequest entity 48814 includes aBaseBusinessTransactionDocumentID, a CreationDateTime, and a Note. TheBaseBusinessTransactionDocumentID is a unique identifier assigned by therequisition system for the object or entity on which the requisitionrequirement is based. The BaseBusinessTransactionDocumentID is of typeGDT: BusinessTransactionDocumentID. The CreationDateTime is the time atwhich the requisition was created in the requisition system. TheCreationDateTime is of type GDT: DateTime. The Note is a shortdescription/name for the requisition. The Note is of type GDT: Note.

(i) Purchase Request Party Package

Party package 48808 groups together the business parties involved in thePurchaseRequest. It includes a BuyerParty entity 48816, a SellerPartyentity 48818, a ProposedSellerParty entity 48820, a RequestorPartyentity 48822, a ProductRecipientParty entity 48824, and aManufacturerParty entity 48826. There is a 1:c relationship 48828between the PurchaseRequest entity 48814 and the BuyerParty entity48816. There is a 1:c relationship 48830 between the PurchaseRequestentity 48814 and the SellerParty entity 48818. There is a 1:crelationship between the PurchaseRequest entity 48814 and theProposedSellerParty entity 48820. There is a 1:c relationship betweenthe PurchaseRequest entity 48814 and each of the entities in the Partypackage 48808. In addition. there is a 1:c relationship between entitiesin this Interface unless otherwise noted herein or indicated in the FIG.488.

Either the ID or the ID and address can be transferred for each party.If the ID is transferred, the ID address defined in the master data isused. If the ID and address are transferred, the ID identifies the partyand the address is deemed to be a document address that is different tothe master data address. Where possible, the ID and address should besent to avoid misunderstandings. The receiving application shouldimplement a suitable optimization strategy to prevent many identicaldocument addresses from being created.

A default logic is used for parties: from the header to the items andwithin item hierarchies. Parties specified in the header are valid forthe items for which a corresponding party is not explicitly transferredand that are directly assigned to the header. In accordance with thesame logic, parties transferred at item level are used for subitemsassigned to the relevant item in an item hierarchy. The default logicapplies for the party as a whole, including the contact person. Parts ofa party specified at header level or for a hierarchy item cannot bespecified in more detail at item level. The default logic is asimplified version of the transferred message. As regards logic, partiesat header level and for hierarchy items behave as if they have beenexplicitly transferred for the subitems of the message.

(a) Buyer Party

A BuyerParty entity 48816 is a party that buys goods or services. TheBuyerParty entity 48816 is of type GDT:BusinessTransactionDocumentParty. Although, in some implementations, theBuyerParty entity 48816 only includes the StandardID and InternalIDelements, as well as the Address and ContactPerson entities. TheContactPerson includes the InternalID element and the Address entity.

The BuyerParty 48816 is specified if more than one company processes itspurchases in the recipient system (hosting scenario). In otherimplementations, the BuyerParty 48816 is unique and does not need to bespecified. Changes can be made to the BuyerParty/Contact and a differentBuyerParty/Contact can exist for each item. Changes can be made to theaddress of the BuyerParty, but different addresses are not permitted foreach item. If a ShipToLocation, a ShipToParty, and a RequestorParty havenot been explicitly specified in the requisition process, the address ofthe BuyerParty 48816 is used as the ship-to address.

(b) Seller Party

A SellerParty entity 48818 can be a party that sells goods or services.The SellerParty entity 48818 is of type GDT:BusinessTransactionDocumentParty. Although, in some implementations, theSellerParty entity 48818 may only include the StandardID and InternalIDelements, as well as the Address and ContactPerson entities, theContactPerson may include the InternalID element and the Address entity.In some examples, if the SellerParty and ShipFromLocation have not beenexplicitly specified in the requisition process, then the address of theSellerParty 48818 is used as the ship-from address. If, in contrast, theSellerParty 48818 is specified, then it is used as the vendor when therequirement is generated in the procurement system (unlike the preferredvendor). The SellerParty 48818 is normally specified when the vendor wasidentified in the requirements system by a source of supply. In thiscase, the relevant source of supply may also specified in thecorresponding BusinessTransactionDocumentReferencePackage entity.

(c) Proposed Seller Party

A ProposedSellerParty entity 48820 can be a preferred party for sellinggoods or services. The ProposedSellerParty entity 48820 is of type GDT:BusinessTransactionDocumentParty. Although, in some implementations, theProposedSellerParty entity 48820 may only include the StandardID andInternalID elements, as well as the Address and ContactPerson entities,the ContactPerson may include the InternalID element and the Addressentity. When a requisition is created, a user can specify a preferredvendor. In the procurement system, the professional buyer can use thepreferred vendor as the actual vendor.

(d) Requestor Party

A RequestorParty entity 48822 can be a party that requests theprocurement of goods or services. The RequestorParty entity 48822 is oftype GDT: BusinessTransactionDocumentParty. Although, in someimplementations, the RequestorParty entity 48822 may include theStandardID and InternalID elements, as well as the Address andContactPerson entities, the ContactPerson may include the InternalIDelement and the Address entity. If a ShipToLocation andProductRecipientParty may not be explicitly specified in the requisitionprocess, the RequestorParty 48822 address can be used as the ship-toaddress. In the purchasing process, the RequestorParty (requestor 48702)carries out different follow-up actions. For this reason, it isspecified explicitly (and not just as the Contact). In a SelfServiceprocess, the RequestorParty 48822 could enter and approve a goodsreceipt and invoice, for example.

(e) Product Recipient Party

A ProductRecipientParty entity 48824 may be a party to which goods aredelivered or for whom services are provided. The ProductRecipientPartyentity 48824 is of type GDT: BusinessTransactionDocumentParty. Although,in some implementations, the ProductRecipientParty entity 48824 mayinclude the StandardID and InternalID elements, as well as the Addressand ContactPerson entities, the ContactPerson may include the InternalIDelement and the Address entity. If a ShipToLocation is not specifiedexplicitly in a requisition process, the address of theProductRecipientParty 48824 is used as the delivery address. If theProductRecipientParty 48824 (goods recipient) is not specified at itemor header level, the RequestorParty is also used as theProductRecipientParty. For a direct material item, theProductRecipientParty is optional. The ShipToLocation, however, ismandatory. In the third-party process, the ProductRecipientParty 48824is the customer. The ProductRecipientParty 48824 is not synonymous withthe ShipToLocation and is to be used when the ProductRecipientParty48824 (company or person) is actually different from the BuyerParty48816.

(f) Manufacturer Party

A ManufacturerParty entity 48826 is a party that manufactures goods. TheManufacturerParty entity 48826 is of type GDT:BusinessTransactionDocumentParty. Although, in some implementations, theManufacturerParty entity 48826 includes the StandardID and InternalIDelements, as well as the Address and ContactPerson entities. TheContactPerson includes the InternalID element and the Address entity.The ManufacturerParty entity 48826 may be used for Material items. Insome implementations, the ManufacturerParty 48826 is not used except forMaterial items.

(ii) Purchase Request Location Package

The Location package 48810 can group together the locations that arerelevant for the requisition. The Location package 48810 includes aShipToLocation entity 48828 and a ShipFromLocation entity 48830.

Similar to the party package entities for this Interface, either the IDor the address, or both may be transferred for each location entity48828 and 48830. If the ID and address can be transferred, the IDidentifies the location and the address may be deemed to be a documentaddress that is different from the master data address. The receivingapplication (e.g., buyer 48704) implements a suitable optimizationstrategy to prevent many identical document addresses from beingcreated.

(a) Ship To Location

A ShipToLocation entity 48828 can be the location to which goods are tobe delivered or where services are to be provided. The ShipToLocationentity 48828 is of type GDT: BusinessTransactionDocumentLocation. Insome implementations, the ShipToLocation entity 48828 may only includethe StandardID and InternalID elements, as well as the Address entity.

(b) Ship From Location

A ShipFromLocation entity 48830 can be the location from where goods areto be shipped. The ShipFromLocation entity 48830 is of type GDT:BusinessTransactionDocumentLocation. In some implementations, theShipToLocation entity 48828 may only include the StandardID andInternalID elements, as well as the Address entity. In someimplementations, the ShipFromLocation is used for material items and notfor other types of items.

(iii) Purchase Request Item Package

A PurchaseRequestItem package 48812 includes a ProductInformationpackage 48832, a PriceInformation package 48834, a Party package 48836,a Location package 48838, a BusinessDocumentObjectReference package48840, an ItemAccounting (or AccountingObjectSetAssignment) package48842, an Attachment package 48844, a Description package 48846, aScheduleLine package 48848, and a PurchaseRequestItem (or Item) entity48850. There is a 1:n relationship between the PurchaseRequest entity48814 and the Item entity 48850. PurchaseRequestItem entities 48850 arearranged hierarchically using a HierarchyRelationship 48852. TheHierarchyRelationship 48852 is the relationship between a sub-item and ahigher-level parent item in an item hierarchy. There is a 1:cnrelationship between the Item entity 48850 and its subordinate entities.There is a 1:c relationship between the Item entity 48850 and itssuperordinate entities.

(a) Purchase Request Item

A PurchaseRequestItem entity 48850 can specify a product requested bythe PurchaseRequest 48814 or provides additional information about sucha product. The PurchaseRequestItem entity 48850 may include detailedinformation about a particular product (see ProductInformation package48832) and its price (see PriceInformation package 48834). The quantityof the product and (delivery) dates/times can be specified in theschedule line (see ScheduleLine package 48848). For thePurchaseRequestItem entity 48850 (compared to the information of thePurchaseRequest entity 48814), deviating parties or locations can bedefined (see Party package 48836 and Location package 48838). ThePurchaseRequestItem entity 48850 can contain references to otherbusiness documents that are relevant for the item (seeBusinessDocumentObjectReference package 48840). Notes or references toattachments can also be specified for the item (see Description package48846 and Attachment package 48844). A PurchaseRequestItem entity 48850can be subordinate to another PurchaseRequestItem entity 48850 within ahierarchy to represent a business relationship between the two items.This could be information about a substitute product for an orderedproduct, for example. This relationship can also be used to grouptogether PurchaseRequest items 48814, that is, a PurchaseRequestItem48850 can group together other PurchaseRequestItems 48850. ThePurchaseRequestItem entity 48850 is of type GDT: PurchaseRequestItem.

The PurchaseRequestItem entity 48850 includes aBaseBusinessTransactionDocumentItemID, a ThirdPartyDealIndicator, and aDirectMaterialIndicator. The BaseBusinessTransactionDocumentItemID canbe an identifier (unique within the object or entity 48806) assigned bythe requirement system for an item 48850 within the object on which therequirement is based. The BaseBusinessTransactionDocumentItemID is oftype GDT: BusinessTransactionDocumentItemID. The ThirdPartyDealIndicatorspecifies that the purchase requisition item is used as part of athird-party process. The ThirdPartyDealIndicator may be of type GDT:BusinessTransactionDocumentItemThirdPartyDealIndicator. TheDirectMaterialIndicator specifies whether the material in the purchaserequisition item is used as part of a direct material process. TheDirectMaterialIndicator is of type GDT: DirectMaterialIndicator.

From a semantic point of view, items 48850 may contain other items48850. Item hierarchies are mapped in this way using the respectiveentity HierarchyRelationship 48852. There are various item categories,which are governed by a variety of constraints. An item 48850 may haveseveral constraint types. In this implementation, the item satisfies theconstraints of its constraint types. Which constraint types can becombined with one another and how, is specified in the description ofthe constraint types. The constraint types may include the following:

(1) Standard items are the items to which no lower-level items have beenassigned in the hierarchy. An item that is not referenced by theParentItemID of another item is a standard item.

(2) Hierarchy items are items to which at least one other lower-levelitem has been assigned in the hierarchy. An item that is referenced bythe ParentItemID of at least one other item is a hierarchy item. Itemsare either standard or hierarchy items.

(3) Subitems are items that are assigned below a hierarchy item and notdirectly assigned to the requisition header. Subitems can be bothstandard items and hierarchy items. Each item that references anotheritem by the ParentItemID is a subitem.

(4) Material items are items whose product is a material. Items whoseProductTypeCode is “1” (or correspond to a Material) are Material items.

(5) DirectMaterial items are material items that are used as part of adirect material process (see DirectMaterialIndicator).

(6) Service items are items whose product is a service. Items whoseProductTypeCode is “2” (or correspond to a service) are service items.

(7) Limit items are items with a cost limit. Limit items are used asplaceholders in a requisition if the exact requirements are unknown atthe time the requisition is issued. This can be the case for repairs,where the time and spare parts required are not known until the repairhas been made.

(8) Grouping hierarchy items are hierarchy items that logically grouptogether other items. Multilevel grouping hierarchies are permitted,that is, a grouping hierarchy item can contain subitems that are alsogrouping hierarchy items. Hierarchy items whose subitems haveHierarchyRelationshipTypeCode “002” (or identify a group) are groupinghierarchy items; subitems with a different HierarchyRelationshipTypeCodeare not permitted. In some implementations, Grouping hierarchy items arenot permitted as subitems of other types of hierarchy items.

(9) BOM hierarchy items are hierarchy items that group together otheritems in a bill of materials (BOM). Multilevel BOM hierarchies arepermitted. Hierarchy items with at least one subitem withHierarchyRelationshipTypeCode “001” (or identifying a bill of materials)are BOM hierarchy items; additional subitems are permitted with theHierarchyRelationshipTypeCode “003” (corresponding to a discount inkind).

(10) Discount in kind hierarchy items are hierarchy items for which agoods discount is granted in the form of an inclusive or exclusive bonusquantity. In some implementations, multilevel discount in kindhierarchies are not permitted, that is, no discount in kind can begranted for discount in kind. The goods discount is described in theform of one or more subitems in the discount in kind hierarchy item.Hierarchy items with at least one subitem withHierarchyRelationshipTypeCode “003” (discount in kind) are discount inkind hierarchy items; additional subitems are permitted with theHierarchyRelationshipTypeCode “001” (bill of material). Hierarchy itemsare grouping, BOM, or discount in kind hierarchy items. A hierarchy itemcan be both BOM and a discount in kind hierarchy item, if a discount inkind has been granted for a BOM.

(b) Hierarchy Relationship

A HierarchyRelationship 48852 is the relationship between a subitem (afirst Item entity 48850) and a higher-level parent item (a second Itementity 48850) in an item hierarchy. The HierarchyRelationship mayinclude a ParentItemID and a TypeCode. The ParentItemID can be areference to a parent item. The ParentItemID can be of type GDT:BusinessTransactionDocumentItemID. The TypeCode represents thehierarchical relationship between the subitem and its higher-levelparent item. The TypeCode is of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode.

In some implementations, neither the ParentItemID nor the TypeCode canbe changed once the corresponding item has been created.

(c) Purchase Request Item Product Information Package

A ProductInformation package 48832 groups together the information foridentifying, describing, and classifying a product in a purchaserequisition item. The ProductInformation package 48832 includes aProduct entity 48854 and a ProductCategory entity 48856. In someimplementations, the ProductInformation package 48832 is not used ingrouping hierarchy items.

(i) Product

A Product entity 48854 may include the details about a product asgenerally understood from a commercial point of view in businessdocuments. These can be the details for identifying a product andproduct type, and the description of the product. The Product entity48854 may be of type GDT: BusinessTransactionDocumentProduct, in someimplementations, although Product entity 48854 only includes theStandardID, InternalID, TypeCode, and Note elements.

In some implementations for limit items, the description (note) may beused in the Product entity 48854 and the product number andProductTypeCode may be not used. In this implementation, either aproduct number or a description along with the ProductTypeCode (materialor service) is specified for each item 48850 other than limit items. TheProductTypeCode may be not changed once a corresponding item has beencreated. If both the product number and description are specified, thedescription can be merely additional information in the message 48806and can be ignored by the recipient. In substitution product subitems,the ProductTypeCode does not differ from the parent itemProductTypeCode.

(ii) Product Category

A ProductCategory entity 48856 may include the details about a productcategory as generally understood from a commercial point of view inbusiness transaction documents. The ProductCategory entity 48856 mayinclude details for identifying the product category using an internalID, a standard ID, and IDs assigned by the involved parties. TheProductCategory entity 48856 is of type GDT:BusinessTransactionDocumentProductCategory. In some implementations, theProductCategory entity 48856 only may include the StandardID andInternalID elements. The product category 48856 may be derived directlyfrom the product 48854 if a product number is specified for the product48854.

(d) Purchase Request Item Price Information Package

A PriceInformation package 48834 can group together price-relevantinformation. The PriceInformation package 48834 includes a Price entity48858 and a ProcurementCostUpperLimit entity 48860. In someimplementations, the Price package 48834 for a purchase requisition itemmay include prices but does not include any information about how theprices are calculated (e.g., pricing scales).

(i) Price

A Price entity 48858 can be the purchase order price specified by therequester or buyer. The Price entity 48858 includes a NetUnitPrice,which can be a net price (without tax or cash discount) specified by thebuyer for the base quantity of the service or material. The NetUnitPriceis of type GDT: Price.

In BOM hierarchies, the following rules can apply for the Price entity48858: (1) if the price is specified for the item at the top of the BOMhierarchy and not the subitems, the price identified by this Priceentity 48858 applies; (2) if the price is specified for standard items(e.g., end nodes in the BOM hierarchy tree) in the BOM hierarchy, theseprices apply. The price of the entire BOM is the total of the individualprices; and (3) if a price is specified at different levels in the BOMhierarchy, the price that appears above the others in the tree alwaysapplies. Differences between the total of the individual prices and theprice at the next highest hierarchy level are permissible. Thedifferences may be caused by discounts for the entire BOM.

(ii) Procurement Cost Upper Limit

A ProcurementCostUpperLimit entity 48860 can be the cost upper limit fordifferent types of procurement costs. The ProcurementCostUpperLimitentity 48860 may be of type GDT: ProcurementCostUpperLimit. If aProcurementCostUpperLimit entity 48860 is specified, this implies thatthe purchase requisition item may be a limit item; in other words, therequisition item can indicate a requirement for a certain quantity of aparticular product or service within a certain period. Limit items areused as placeholders in a requisition if the exact requirements may beunknown at the time the requisition is issued. For example, this may bethe case for repairs, where the time and spare parts required are notknown until the repair has been made.

(e) Purchase Request Item Party Package

The ItemParty package 48834 may be similar to the Party package 48808 inthe PurchaseRequest package 48804. The ItemParty package 48852 alsoincludes a BuyerParty entity 48862, a SellerParty entity 48864, aProposedSellerParty entity 48866, a RequestorParty entity 48868, aProductRecipientParty entity 48870, and a ManufacturerParty entity48872. Each of the entities in the ItemParty package 48852 is similar tothe similarly named entities in the PurchaseRequestParty package 48808described above.

(f) Purchase Request Item Location Package

The ItemLocation package 48838 may be similar to the Location package48810 in the PurchaseRequest package 48804. The ItemLocation package48854 also includes a ShipToLocation entity 48874 and a ShipFromLocationentity 48876 as described above.

(g) Purchase Request Item Business Document Object Reference Package

A BusinessDocumentObjectReference package 48840 groups togetherreferences to business documents that are relevant for thePurchaseRequestItem 48850 and have a business relationship with theitem. The BusinessDocumentObjectReference package 48840 includes aPurchasingContractReference entity 48878, anOriginPurchaseOrderReference entity 48880, a ProjectReference entity48882, and a ProjectElementAssignment entity 48884. In someimplementations, none of the entities in theBusinessDocumentObjectReference package 48840 are used in groupinghierarchy items.

(i) Purchase Contract Reference

A PurchasingContractReference entity 48878 may be a reference to apurchase contract or item in a purchase contract. ThePurchasingContractReference entity 48878 may be of type GDT:BusinessTransactionDocumentReference.

In some implementations, a PurchasingContractReference entity 48878 maybe not used in limit items 48850, which are defined by theProcurementCostUpperLimit entity 48860. A PurchasingContractReferenceentity 48878 may include one ItemID to reference one item.

(ii) Origin Purchase Order Reference

The OriginPurchaseOrderReference entity 48880 can be a reference to theorigin purchase order or to an item within the origin purchase order ina third-party process. The OriginPurchaseOrderReference entity 48880 maybe of type GDT: BusinessTransactionDocumentReference.

The OriginPurchaseOrderReference entity 48880 may include one ItemID toreference one item. The OriginPurchaseOrderReference entity 48880 ispassed on to the purchase orders in a third-party deal, so that theseller can reference the original purchase order of the ShipToParty withthe OriginPurchaseOrderReference.

(h) Project Reference

A ProjectReference 48882 is a reference to a project or an elementwithin a project from which the requirement arose. The ProjectReference48882 may be of type GDT: ProjectReference. The ProjectReference 48882includes a ProjectElementTypeCode corresponding to a Task or a Role.

A ProjectElementAssignment 48884 can be the assignment between twoelements of a project from which the requirement arose. TheProjectElementAssignment in a purchasing process is passed right throughto goods receipt, service entry and the invoice so that a project systemcan always be informed of the status of the requirement. TheProjectElementAssignment is of type GDT: ProjectElementAssignment. Insome implementations, only one assignment 48884 of a role (e.g.,ProjectElementTypeCode corresponds to a “role”) to a task(ProjectElementTypeCode corresponds to a “task”) can be allowed.

In addition, in some implementations, either one ProjectReference 48882or one ProjectElementAssignment 48884 can be specified for the item48850.

(i) Accounting Object Set Assignment

The AccountingObjectSetAssignment package 48842 can group all accountassignment information for a requirement item. TheAccountingObjectSetAssignment package 48842 includes anAccountingObjectSetAssignment entity 48886, which is the assignment ofthe amount or a percentage, value portion, or quantity subamount of anitem in the requirement to a quantity of account assignment objects. TheAccountingObjectSetAssignment is of type GDT:AccountingObjectSetAssignment. There is a 1:cn relationship between theItem entity 48850 and the AccountingObjectSetAssignment entity 48886.

(j) Purchase Request Item Attachment Package

The Attachment Package 48842 can group together the relevant attachmentswith reference to the purchase requisition item. The Attachment Package48842 includes an AttachmentWebAddress entity 48888. There is a 1:cnrelationship between the Item entity 48850 and the AttachmentWebAddressentity 48888.

The AttachmentWebAddress entity 48888 is a Web address for a document ofany type that is related to the transmitted message or a part of themessage, but is not itself transferred as part of the message. TheAttachmentWebAddress entity 48888 is of type GDT: AttachmentWebAddress.

(k) Purchase Request Item Description Package

A Description package 48846 can group together the texts relating to thepurchase requisition item. The Description package 48846 includes aDescription entity 48890 and an InternalDescription entity 48892.

The Description entity 48890 can be a natural-language text regardingthe purchase requisition item, which is visible to the parties. TheDescription entity 48890 is of type GDT: Description. The Descriptionentity 48890 may be used for the textual information about thetransferred requisition and not just the current message. An example ofthis would be information that the responsible Purchasing employee is onvacation as of a specific date, and indicating the name and telephonenumber of a substitute as of this date.

An InternalDescription entity 48892 is a natural-language text regardingthe purchase requisition item, which is visible to the parties withinthe company. The InternalDescription entity 48892 is of type GDT:Description. The InternalDescription entity 48892 may be used for thetextual information about the transferred requisition and not just thecurrent message. An example of this is a note indicating that therequisition is required for a particular internal purpose. Unlike theDescription entity 48890, the InternalDescription 48892 is not includedin a message that would be sent to the vendor.

(l) Purchase Request Item Schedule Line Package

A ScheduleLine package 48848 groups the quantity and date informationabout a PurchaseRequestItem entity 48850. The ScheduleLine package 48848includes a ScheduleLine entity 48894. There is a 1:1 relationshipbetween the Item entity 48850 and the ScheduleLine entity 48894.

A ScheduleLine entity 48894 is a line containing the quantity and datesof the performance period requested in a requisition. The ScheduleLineentity 48894 includes a DeliveryPeriod 48896 and a Quantity 48898. TheDeliveryPeriod 48896 can be the period in which the requester expects aproduct to be delivered or service provided. The DeliveryPeriod may beof type GDT: DateTimePeriod. The Quantity 48898 is the requiredquantity. The Quantity 48898 may be of type GDT: Quantity. The quantityis specified, unless the item in question is a limit item, in which caseit may be left empty. In some implementations, exactly one ScheduleLine48894 can be provided in the PurchaseRequestItem 48850.

(4) Message Data Type Purchase Request Confirmation Message

FIG. 489 depicts an exemplary data model for thePurchaseRequestConfirmation 48710. The message data typePurchaseRequestConfirmationMessage includes aPurchaseRequestConfirmationMessage package 48800 that groups thebusiness information relevant for sending a business document in amessage and the PurchaseRequestConfirmation object or entity containedin the business document. The PurchaseRequestConfirmationMessage package48800 includes a MessageHeader package 48902, a PurchaseRequest package48904, and a PurchaseRequestConfirmationMessage entity 48906.

The MessageHeader package 48902 can group together the business from theperspective of the sending application. In the implementation shown inFIG. 489, the MessageHeader package 48802 may be omitted from or remainempty in the structure of the PurchaseRequestConfirmation message.

(a) PurchaseRequest Package

The PurchaseRequestPackage 48902 includes a PurchaseRequestItemPackage48908 and a PurchaseRequest entity 48910.

The PurchaseRequest entity 48910 included in or associated with thePurchaseRequestConfirmationMessage entity 48906 includes a purchaser'sconfirmation of a requester's requirement with respect to the externalprocurement of products (materials, services). There is a 1:1relationship between the PurchaseRequestConfirmationMessage 48906 andthe PurchaseRequest entity 48910. The PurchaseRequest 48910 issubdivided into PurchaseRequestItems 48914 that can include informationon the extent of fulfillment of the requirement (see PurchaseRequestItempackage 48908). The PurchaseRequest 48910 is of type: GDTPurchaseRequestConfirmation. The PurchaseRequest 48910 includes aBaseBusinessTransactionDocumentID. The BaseBusinessTransactionDocumentIDis a unique identifier assigned by the requirement system for the objecton which the requirement is based. The BaseBusinessTransactionDocumentIDmay be of type GDT: BusinessTransactionDocumentID.

(i) PurchaseRequest Item Package

The PurchaseRequestItem package 48908 includes aFulfillingPurchaseOrderPackage 48912 and a PurchaseRequestItem entity48914.

The PurchaseRequestItem entity 48914 can specify a product required bymeans of the PurchaseRequest 48910 or additional information on such aproduct. The PurchaseRequestItem entity 48914 may include information onthe extent of fulfillment of a requirement. The PurchaseRequestItementity 48914 is of type: GDT PurchaseRequestConfirmationItem. There canbe a 1:n relationship between the PurchaseRequest 48910 and thePurchaseRequestItem entity 48914. The PurchaseRequestItem entity 48914may include a BaseBusinessTransactionDocumentItemID element, anOpenQuantityCancelledIndicator element, a TotalRequestedQuantityelement, and a TotalOrderedQuantity element. TheBaseBusinessTransactionDocumentItemID can be the identifier assigned bythe requirement system for an item within the object on which therequirement is based. The BaseBusinessTransactionDocumentItemID may beof type GDT: BusinessTransactionDocumentItemID. TheOpenQuantityCancelledIndicator may be an indicator of whether furthersources of supply are to be determined for remaining quantities or ifthe remaining quantities are to be regarded as cancelled. TheOpenQuantityCancelledIndicator may be of type GDT: CancelledIndicator.The TotalRequestedQuantity is the total requested quantity for arequirement item. The TotalRequestedQuantity may be of type GDT:Quantity. The TotalOrderedQuantity may be the total ordered quantity fora requirement item. The TotalOrderedQuantity is of type GDT: Quantity.

(a) Purchase Request Item Fulfilling Purchase Order Package

The FulfillingPurchaseOrder package 48912 can group information on theextent of fulfillment of a requirement by a purchase order. TheFulfillingPurchaseOrder package 48912 includes aFulfillingPurchaseOrderItem package 48916 and a FulfullingPurchaseOrderentity 48918.

The FulfillingPurchaseOrder entity 48918 can be a view of aPurchaseOrder that shows the extent of fulfillment of a requirementitem. The FulfillingPurchaseOrder entity 48918 may be of type: GDT:PurchaseRequestConfirmationItemFulfillingPurchaseOrder. There may be a1:cn relationship between the PurchaseRequestItem entity 48914 and theFulfillingPurchaseOrder entity 48918. The FulfillingPurchaseOrder entity48918 may include an ID element of type GDT:BusinessTransactionDocumentID and an OrderedIndicator element of typeGDT: PurchaseOrderOrderedIndicator. The ID can correspond to thepurchase order number. The OrderedIndicator identifies the purchaseorder has already been sent to the vendor.

(i) Purchase Request Item Fulfilling Purchase Order Item Package

The FulfillingPurchaseOrderItem package 48916 can group information onthe extent of fulfillment of a requirement by a purchase order item. TheFulfillingPurchaseOrderItem package 48916 includes aFulfillingPurchaseOrderItem entity 48920. There is a 1:n relationshipbetween the FulfillingPurchaseOrder entity 48918 and theFulfillingPurchaseOrderItem entity 48920.

The FulfillingPurchaseOrderItem entity 48920 can be a view of aPurchaseOrderItem that shows the extent of fulfillment of a requirementitem. The FulfillingPurchaseOrderItem entity 48920 is of type GDT:PurchaseRequestItemFulfillingPurchaseOrderItem. TheFulfillingPurchaseOrderItem entity 48920 may include an ID element and aQuantity element. The ID corresponds to the purchase order item number.The ID is of type GDT: BusinessTransactionDocumentItemID. The Quantityelement can identify the Quantity ordered and is of type GDT: Quantity.

(5) Message Data Type Element Structure

(a) PurchaseRequestRequest

The message data type element structure for the PurchaseRequestRequestmessage is depicted in FIG. 490A-J. The element structure is similar tothe data model, but provides additional information regarding thedetails of the interface. The element structure identifies the differentpackages 49000 in the interface, and represents the entities at variouslevels within the interface. As depicted in FIG. 490A, the interface forPurchaseRequest Message includes five levels 49002, 49004, 49006, 49008,and 49010. The outermost package of this interface is aPurchaseRequestMessage package 49018, which includes a Purchase RequestMessage entity 49020 at the first level 49002. The Purchase RequestMessage entity 49020 is of a data type MDT 49022“PurchaseRequestMessage” 49024.

The PurchaseRequestMessage package 49028 includes a PurchaseRequestpackage 49030, a location package 49092A, and an Item package 49044B.The PurchaseRequest package 49028 includes a PurchaseRequest entity49030 at the second level 49004. The PurchaseRequest entity 49030 is ofa data type “Purchase Request” 49036, and there is one 49032PurchaseRequest entity 49026 for each PurchaseRequestpackage 49028.

The PurchaseRequest entity 49030 includes a Base Business TransactionDocument ID 49040, a CreationDateTime 49050, and a Note 49060. The BaseBusiness Transaction Document ID 49040 is of a type GDT 49044“BusinessTransactionDocumentID” 49046, and there is one or two 49042Base Business Transaction Document ID 49040 for a PurchaseRequest entity49030. The CreationDateTime 49050 is of a type GDT 49054 “DateTime”49056, and there is one 49052 CreationDateTime 49050 for aPurchaseRequest entity 49030. The Note 49060 is of a type GDT 49064“Note” 49066, and there is zero or one 49062 Note 49060 for aPurchaseRequest entity 49028.

The PurchaseRequest package 49028 includes a Party package 49070. TheParty package 49070 includes a BuyerParty entity 49072, a Seller Party49042A, a ProposedSellerParty 49052A, a RequestorParty 49062A, aShipToParty 49072A, a ManufacturerParty 49082A at the third level. TheBuyerParty 49072 is of a type GDT 49076“BusinessTransactionDocumentParty” 49078, and there is either zero orone 49074 BuyerParty entity 49072 for each Party package 49070.

The BuyerParty entity 49072 includes a Standard ID 49082, an Internal ID49092, an Address 49002A, and a Contact Person 49012A at the fourthlevel. The Standard ID 49082 is of type GDT 49086 “PartyStandardID”49088, and there is any number of Standard ID 49082 for a BuyerPartyentity 49072. The Internal ID 49092 is of type GDT 49096“PartyInternalID” 49098, and there is either zero or one 49094 InternalID 49092 for a BuyerParty entity 49072. The Address 49002A is of typeGDT 49006A “Address” 49008A, and there is either zero or one 49004AAddress 49002A for a BuyerParty entity 49072. The Contact Person 49012Ais of type GDT 49016A “Address” 49018A, and there is either zero or one49014A Contact Person 49012A for a BuyerParty entity 49072.

The Contact Person 49012A includes an Internal ID 49022A and an Address49032A. The Internal ID 49012A is of type GDT 49026A“ContactPersonInternalID” 49028A, and there is any number of 49024AInternal ID 49022A for a Contact Person 49012A. The Address 49032A is oftype GDT 49006A “Address” 49038A, and there is either zero or one 49034AAddress 49032A for a BuyerParty entity 49012A.

The SellerParty 49042A is of a type GDT 49046A“BusinessTransactionDocumentParty” 49048A, and there is either zero orone 49044A SellerParty entity 49042A for each Party package 49070. TheProposedSellerParty 49052A is of a type GDT 49056A“BusinessTransactionDocumentParty” 49058A, and there is either zero orone 49054A ProposedSellerParty entity 49052A for each Party package49070. The RequestorParty 49062A is of a type GDT 49066A“BusinessTransactionDocumentParty” 49068A, and there is either zero orone 49064A RequestorParty entity 49062A for each Party package 49070.The ShipToParty 49072A is of a type GDT 49076A“BusinessTransactionDocumentParty” 49078A, and there is either zero orone 49074A ShipToParty entity 49072A for each Party package 49070. TheManufacturerParty 49082A is of a type GDT 49086A“BusinessTransactionDocumentParty” 49088A, and there is either zero orone 49084A ManufacturerParty entity 49082A for each Party package 49070.

The location package 49092A includes a ShipToLocation entity 49094A anda ShipFromLocation entity 49034B at the third level. The ShipToLocationentity 49094A includes a Standard ID 49004B, an Internal ID 49014B, andan Address 49024B at the fourth level. The ShipToLocation entity is aGDT 49098A “BusinessTransactionBodumentLocation” 49000B, and there iseither zero or one 49096A ShipToLocation 49094A for each Locationpackage 49092A. The Standard ID 49004B is of type GDT 49008B“LocationStandardID” 49010B, and there is any number of Standard ID49004B for a ShipToLocation entity 49092A. The Internal ID 49014B is oftype GDT 49018B “LocationInternalID” 49020B, and there is either zero orone 49016B Internal ID 49014B for a Location package 49092A. The Address49024B is of type GDT 49028A “Address” 49030B, and there is either zeroor one 49036B Address 49034B for a Location package 49092A. TheShipFromLocation is a GDT 49038B “BusinessTransactionBodumentLocation”49040B, and there is either zero or one 49026A ShipToLocation 49094A foreach Location package 49092A.

The Item package includes a Product Information package 49012C, a PriceInformation package 49094C, a Party package 49022D, a Location package49084D, a Business Document Object Reference package 49004E, anAccounting package 49066E, an Attachment package 49024F, a Descriptionpackage 49036F, and a Schedule Line package 49058F. The Item packagealso includes an Item entity 49046B at the third level. The Item entityis a “PurchaseRequestItem” 49052B and there can be any number of Itementity 49046B for each Item package 49044B. The Item entity 49046Bincludes a Base Business Transaction Document Item ID 49056B, a ThirdParty Deal Indicator 49066B, a Direct Material Indicator 49076B, and aHierarchy Relationship 49086B. The Base Business Transaction DocumentItem ID 49056B is a GDT 49060B “BusinessTransactionDocumentItemID”49062B, and there is either one or two Base Business TransactionDocument Item ID 49056B for an Item entity 49046B. The Third Party DealIndicator 49066B is a GDT 49070B“BusinessTransactionDocumentThirdPartyDealIndicator” 49072B, and thereis either zero or one Base Business Transaction Document Item ID 49076Bfor an Item entity 49046B. The Direct Material Indicator 49076B is a GDT49080B “DirectMaterialIndicator” 49082B, and there is either zero or one49078B Direct Material Indicator 49076B for an Item entity 49046B. Thereis either zero or one 49088B Hierarchy Relationship 49086B for an Itementity 49046B.

The Hierarchy Relationship 49086B includes a Parent Item ID 49092B and aType Code 49002C at the fifth level. The Parent Item ID 49092B is a GDT49096B “BusinessTransactionDocumentItemID” 49098B, and there is one49094B Parent Item ID 49092B for a Hierarchy Relationship 49086B. TheType Code 49002C is a GDT 49006C“BusinessTransactionDocumentItemHierarchyRelationshipTypeCode” 49008C,and there is one 49094B Type Code 49002C for a Hierarchy Relationship49086B.

The Product Information package includes a Product entity 49014C, aProduct Category entity 49064C, a Price entity 49096C, a Price entity49096C, and a ProcurementCostUpperLimit entity 49012D at the fourthlevel. The Product entity is a GDT 49018C“BusinessTransactionDocumentProduct” 49020C, and there is either zero orone 49016C Product entity 49014C for each Product Information 49012C.The Product entity 49014C includes a StandardID 49024C, an InternalID49034C, a Type Code 49044C, and a Note 49054C at the fifth level. TheStandardID 49024C is of type GDT 49028C “ProductStandardID” 49030C, andthere is any number of StandardID 49024C for a Product entity 49014C.The InternalID 49034C is of type GDT 49038C “ProductInternalID” 49040C,and there is either zero or one 49036C InternalID 49034C for a Productentity 49014C. The Type Code 49044C is a GDT 49048C “ProductTypeCode”49050C, and there is either zero or one 49046C Type Code 49002C for aProduct entity 49014C. The Note 49054C is of a type GDT 49058C “Note”49060C, and there is zero or one 49056C Note 49054C for a Product entity49014C.

The Product Category entity 49064C is a GDT 49068C“BusinessTransactionDocumentProductCategory” 49070C, and there is eitherzero or one 49066C Product Category 49064C for each Product Informationpackage 49012C. The Product Category entity 49064C includes a StandardID49074C and an Internal ID 49084C at the fifth level. The StandardID49074C is of type GDT 49078C “ProductCategoryStandardID” 49030C, andthere is any number of StandardID 49024C for a Product Category entity49064C. The InternalID 49084C is of type GDT 49088C“ProductCategoryInternalID” 49090C, and there can be any number 49086Cof InternalID 49084C for a Product Category entity 49064C.

There is either zero or one 49098C Price entity 49096Cis a GDT 49068Cfor each Product Information package 49012C. The Price entity 49096Cincludes a NetUnitPrice 49002D at the fifth level. The NetUnitPrice49002D is of type GDT 49006D “Price” 49008D, and there is either zero orone 49004D of NetUnitPrice 49002D for a Price entity 49096C.

The ProcurementCostUpperLimit entity 49012D is of type GDT 49016D“ProcurementCostUpperLimit” 49018D, and there is either zero or one49014D of ProcurementCostUpperLimit entity 49012D for a Price entity49096C.

The Party package 49022D includes a BuyerParty entity 49024D, a SellerParty 49034D, a ProposedSellerParty 49044D, a RequestorParty 49054D, aShipToParty 49064D, a ManufacturerParty 49074D at the fourth level. TheBuyerParty 49024D is of a type GDT 49028D“BusinessTransactionDocumentParty” 49030D, and there is either zero orone 49026D BuyerParty entity 49024D for each Party package 49022D. TheSellerParty 49034D is of a type GDT 49038D“BusinessTransactionDocumentParty” 49040D, and there is either zero orone 49036D SellerParty entity 49034D for each Party package 49022D. TheProposedSellerParty 49044D is of a type GDT 49048D“BusinessTransactionDocumentParty” 49050D, and there is either zero orone 49046D ProposedSellerParty entity 49044D for each Party package49022D. The RequestorParty 49054D is of a type GDT 49058D“BusinessTransactionDocumentParty” 49060D, and there is either zero orone 49056D RequestorParty entity 49054D for each Party package 49022D.The ShipToParty 49064D is of a type GDT 49068D“BusinessTransactionDocumentParty” 49070D, and there is either zero orone 49066D ShipToParty entity 49064D for each Party package 49022D. TheManufacturerParty 49074D is of a type GDT 49078D“BusinessTransactionDocumentParty” 49080D, and there is either zero orone 49076D ManufacturerParty entity 49074D for each Party package49022D.

The Location package 49084D includes a ShipToLocation entity 49094D anda ShipFromLocation entity 49086D at the fourth level. TheShipFromLocation entity 49086D is a GDT 49090D“BusinessTransactionBodumentLocation” 49092D, and there is either zeroor one 49088D ShipToLocation 49094D for each Location package 49084D.The ShipToLocation entity 49094D is a GDT 49098D“BusinessTransactionBodumentLocation” 49000E, and there is either zeroor one 49096D ShipToLocation 49094D for each Location package 49084D.

The BusinessDocumentObjectReference package 49004E includes a PurchasingContract Reference 49006E, an Origin Purchase Order Reference 49016E, aProject Reference 49026E, and a Project Element Assignment 49036E at thefourth level. The Purchasing Contract Reference 49006E is a GDT 49010E“BusinessTransactionDocumentReference” 49012E, and there is either zeroor one 49008E Purchasing Contract Reference 49006E for eachBusinessDocumentObjectReference package 49004E. The Origin PurchaseOrder Reference 49016E is a GDT 49020E“BusinessTransactionDocumentReference” 49022E, and there is either zeroor one 49018E Origin Purchase Order Reference 49016E for eachBusinessDocumentObjectReference package 49004E. The Project Reference49026E is a GDT 49030E “ProjectReference” 49032E, and there is eitherzero or one 49028E Project Reference 49026E for eachBusinessDocumentObjectReference package 49004E. The Project ElementAssignment 49036E is a GDT 49040E “ProjectElementAssignment” 49042E, andthere is either zero or one 49038E Project Element Assignment 49036E foreach BusinessDocumentObjectReference package 49004E.

The ProjectElementAssignment 49036E includes a FromProjectReference49046E and a ToProjectReference 49056E at the fifth level. TheFromProjectReference 49046E is a GDT 49050E “ProjectReference” 49052E,and there is one 49050E FromProjectReference 49046E for aProjectElementAssignment 49036E. The ToProjectReference 49056E is a GDT49060E “ProjectReference” 49062E, and there is one 49058EToProjectReference 49056E for a ProjectElementAssignment 49036E.

The Accounting package 49066E includes an AccountingObjectSetAssignmententity 49068E in the fourth level. The AccountingObjectSetAssignmententity 49068E is a GDT 49072E “AccountingObjectSetAssignment” 49074E,and there is zero to any number of AccountingObjectSetAssignmententities 49068E for each Accounting package 49066E. TheAccountingObjectSetAssignment entity 49068E includes a Percent 49078E,an Amount 49088E, a Quantity 49004F, and an AccountingObjectSet 49014F.The Percent 49078E is a GDT 49082E “Percent” 49084E, and there is eitherzero or one 49080E Percent 49078E for an AccountingObjectSetAssignment49068E. The Amount 49088E is a GDT 49092E “Amount” 49000E, and there iseither zero or one 49090E Amount 49088E for anAccountingObjectSetAssignment 49068E. The Quantity 49004F is a GDT49008F “Quantity” 49010F, and there is either zero or one 49006FQuantity 49004F for an AccountingObjectSetAssignment 49068E. TheAccountingObjectSet 49014F is a GDT 49018F “AccountingObject” 49020F,and there is either zero or one 49016F AccountingObjectSet 49014F for anAccountingObjectSetAssignment 49068E.

The Attachment package 49024F includes an AttachmentWebAddress entity49026F in the fourth level. The AttachmentWebAddress entity 49026F is aGDT 49030F “AttachmentWebAddress” 49032F, and there is either zero orone 49028F AttachmentWebAddress entity 49026F for each Attachmentpackage 49024F.

The Description package 49036F includes a Description entity 49038F andan InternalDescription 49048F in the fourth level. The Descriptionentity 49038F is a GDT 49042F “Description” 49044F, and there is eitherzero or one 49040F Description entity 49038F for each Descriptionpackage 49036F. The InternalDescription 49048F is a GDT 49042F“Description” 49044F, and there is either zero or one 49040FInternalDescription 49048F for each Description package 49036F.

The ScheduleLine package 49058F includes an ScheduleLine entity 49060Fin the fourth level. The ScheduleLine entity 49060F is a“PurchaseRequestItemScheduleLine” 49066F, and there is one 49062FScheduleLine entity 49060F for each ScheduleLine package 49058F. TheScheduleLine entity 49060F includes a DeliveryPeriod 49070F and aQuantity 49080F. The DeliveryPeriod 49070F is a GDT 49074F“DateTimePeriod” 49076F, and there is one 49072F DeliveryPeriod 49070Ffor a ScheduleLine 49060F. The Quantity 49080F is a GDT 49084F“Quantity” 49086F, and there is either zero or one 490 82F Quantity49080F for a ScheduleLine 49060F.

(b) PurchaseRequestConfirmation

The message data type element structure for thePurchaseRequestConfirmation message is depicted in FIG. 491A-B. Theelement structure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 49101 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 491A, the interface for PurchaseRequestConfirmationMessage includes five levels 49102, 49103, 49104, 49105, 49106. Theoutermost package of this interface is aPurchaseRequestConfirmationMessage package 49109, which includes aPurchaseRequestConfirmation Message entity 49110 at the first level49102. The Purchase Request Message entity 49110 is of a data type MDT49111 “PurchaseRequestConfirmationMessage” 49112.

The PurchaseRequestConfirmationMessage package 49109 includes a PurchaseRequest package 49113. The Purchase Request package 49113 includes aPurchase Request entity 49114 at the second level. The Purchase Requestentity 49114 is a “PurchaseRequestConfirmation” 49116, and there is one49115 Purchase Request entity 49114 for each Purchase Request package49113. The Purchase Request entity 49114 includes aBaseBusinessTransactionDocuentID 49117 at the third level. TheBaseBusinessTransactionDocuentID 49117 is a GDT 49119“BusinessTransactionDocumentID” 49120, and there is either one or two49118 BaseBusinessTransactionDocuentID 49117 for a Purchase Requestentity 49114.

The Purchase Request package 49113 also includes an Item package 49121.The Item package 49121 includes an Item entity 49122 at the third level.The Item entity 49122 is a “PurchaseRequestConfimmation” 49124, andthere is from one to any number 49123 of Item entity 49122 for each Itempackage 49121. The Item entity 49122 includes aBsseBusinessTransactionDocumentItemID 49125, anOpenQuantityCancelledIndicator 49129, a TotalRequestedQuantity 49133,and a TotalOrderedQuantity 49137. TheBsseBusinessTransactionDocumentItemID 49125 is a GDT 49127“BusinessTransactionDocumentID” 49128, and there is either one or two49126 BsseBusinessTransactionDocumentItemID 49125 for an Item entity49122. The OpenQuantityCancelledIndicator 49129 is a GDT 49131“Cancelled Indicator” 49132, and there is either zero or one 49130OpenQuantityCancelledIndicator 49129 for an Item entity 49122. TheTotalRequestedQuantity 49133 is a GDT 49135 “Quantity” 49136, and thereis one 49134 TotalRequestedQuantity 49133 for an Item entity 49122. TheTotalOrderedQuantity 49137 is a GDT 49139 “Quantity” 49140, and there isone 49138 TotalOrderedQuantity 49137 for an Item entity 49122.

The Item package 49121 includes a Fulfilling Purchase Order package49141. The Fulfilling Purchase Order package 49141 includes a FulfillingPurchase Order entity 49142 at the fourth level. The Fulfilling PurchaseOrder entity 49142 is a “Purchase Request Confirmation Item FulfillingPurchase Order” 49144, and there is from zero to any number ofFulfilling Purchase Order entities 49142 for each Fulfilling PurchaseOrder 49141. The Fulfilling Purchase Order entity 49142 includes an ID49145 and an OrderedIndicator 49149. The ID 49145 is a GDT 49147“BusinessTransactionDocumentID” 49148, and there is one 49146 ID 49145for a Fulfilling Purchase Order entity 49142. The OrderedIndicator 49149is a GDT 49151 “Purchase Order OrderedIndicator” 49152, and there iseither zero or one 49150 OrderedIndicator 49149 for a FulfillingPurchase Order entity 49142.

The Fulfilling Purchase Order package 49141 includes a FulfillingPurchase Order Item package 49153. The a Fulfilling Purchase Order Itempackage 49153 includes an Item entity 49154 in the fourth level. TheItem entity 49154 is a“PurchaseRequestConfirmationItemFufillingpurchaseOrderItem” 49156, andthere is from one to any number of Item entity 49154 for each FulfillingPurchase Order Item package 49153. The Item entity 49154 includes an ID49157 and a Quantity 49161 at the fifth level. The ID 49157 is a GDT49159 “BusinessTransactionDocumentID” 49160, and there is one 49158 ID49157 for an Item entity 49153. The Quantity 49161 is a GDT 49163“Quantity” 49164, and there is either zero or one 49162 Quantity 49161for an Item entity 49154.

mm) ReturnDeliveryInstructionNotification

A ReturnDeliveryInstructionNotification informs the vendor about thedetails of the return delivery, in particular about the ship-tolocation, the products being returned, the arrival times, and thecarrier who is going to perform the shipment. This instruction isimportant since a return delivery can be necessary due to repairs,damage, disposal or scrapping, or regular return deliveries of unsoldproducts.

The motivating business scenario for theReturnDeliveryInstructionNotification message is found undercircumstances of “Returns Processing” business scenario. Thestarting-point of the scenario is the Web-based request from a businesspartner for authorization to return goods, remaining materials, and soon. This request might not be made if there are regular returns. Inthese cases, the scenario starts as with the automatic sending of theReturnDeliveryInstructionNotification. The product recipient (forthird-party deals, also the original buyer or ordering party), using theReturnDeliveryInstructionNotification, gives the vendor logisticalinstructions that help the vendor perform the return delivery. Thevendor then informs the product recipient of the return delivery using aDespatchedDeliveryNotification. The product recipient can then use aReceivedDeliveryNotification to confirm receipt of the return deliveryto the vendor.

The vendor and product recipient parties have a rolls that are speciallydefined in the context of returns processing. A vendor is defined as aparty who delivers goods or who performs a service. A product recipientis defined as a party to whom goods are delivered or for whom a serviceis performed (see GDT BusinessTransactionDocumentParty).

A message type ReturnDeliveryInstructionNotification is a message to avendor containing logistical instructions for one of the returndeliveries that he or she has to perform. The message typeReturnDeliveryInstructionNotification is specified by the message datatype ReturnDeliveryInstructionNotificationMessage. TheReturnDeliveryInstructionNotification is sent from a product recipientto a vendor. The message transmission is always complete (“completetransmission”). The functionality of theReturnDeliveryInstructionNotification is covered in the message standard“EDIFACT” by the message type RETINS (Instruction for Returns). InRosettaNet, this corresponds to the ReturnProductConfirmation message inthe PIP 3C1 (return product). The ReturnDeliveryInstructionNotification,with its logistical instructions, goes beyond theReturnProductConfirmation message.

Methods and systems consistent with the subject matter described hereinuse the package template for a BusinessTransactionDocument for an SCMMaster Data depicted in FIG. 270B to derive the DeliveryInformationinterface.

(a) PurchasingContract Interfaces

PurchasingContract interfaces are interfaces between contract managementand purchasing. They are used throughout the life-cycle of purchasingcontracts to exchange messages relating to these contracts. In thefollowing, the term purchasing contract is referred to as contract, forsimplicity.

The purchasing contract is a superordinate term that covers outlineagreements and operational contracts. An outline agreement is theinformation for a contract in procurement systems involved in contractdistribution. The operational contract contains contract informationrelevant for the procurement systems. In the following, the termpurchasing contract is used for simplicity.

The aim of contract management is to provide contractual outlineagreements for vendor relationships in a standard format in the company.This includes the life-cycle, from contract creation, throughdistribution to the respective purchasing organization, to checkingwhether the purchasing department actually observes the terms of thecontract.

Implementing a standard company-wide contract management can helpachieve cost-savings in purchasing. The company-wide bundling andconsolidated contractual firming of similar requirements results in astronger negotiating position that brings with it improved procurementprices. A more uniform maintenance of vendor relationships on the basisof more transparent global agreements raises the efficiency of thepurchasing organization in day-to-day activities. With the monitoringthat is provided, it is possible to react quickly and in targetedfashion to problematic and exceptional situations. By establishingsupply contracts in company-wide fashion and then controlling whetherthey are being kept to, it is possible to avoid value losses that occurwhen individual units cover smaller requirements on an ad hoc basis,placing them with vendors that would not otherwise be favoured, atprices that are not the best.

The value contribution of contract management is therefore only reallyappreciable when as many units as possible within the company areincorporated. This means that, in a system landscape that is often veryheterogeneous, involved systems must be supplied with the relevantinformation. Traditional procedures involve high process costs due tomanual multiple entries, are prone to errors, and take longer. Thesedisadvantages do not apply to electronic communication between thedifferent systems involved in the contract life-cycle.

In the following, the term purchasing is used to describe the businessrole of the systems involved in purchasing.

Document management (this is actually the builder application but wewill continue to refer to it as document management) generates thecontract management document with the relevant clauses from the businessdata framework of the contract before sending it back to contractmanagement as an attachment.

Contract management manages the information that is always valid for theconnected operational purchasing. It triggers the creation of the legalcontract text by document management. Contract management transfers thestandard contract parts to all connected operational purchasing systemsand receives information on contract usage caused by contract releases.

Operational purchasing receives the standard contract parts fromcontract management. Contract releases are communicated back to contractmanagement.

As well as acting as a simple interface structure, thePurchasingContract interfaces define the fundamental business meaningand do away with the need to exchange proprietary information in simplecontract scenarios. An integration of applications that implement thecontract interfaces is possible without extensive project work.

In contract scenarios with complex price conditions, a standardcodification is difficult because of the confusing array of conceivablecondition models. One possibility would be to ensure a standard means ofcalculation of the price conditions in all affected systems. This meansthat a standard Customizing is maintained.

(2) Message Types

Five messages are used to represent a contract scenario in the currentimplementation: PurchasingContractLegalDocumentRequest,PurchasingContractLegalDocumentNotification,PurchasingContractUseRequest, PurchasingContractUseConfirmation, andPurchasingContractReleaseNotification.

The structures of the message types are defined by the three messagedata types. The message data type PurchasingContractLegalDocumentMessageis used for the message types PurchasingContractLegalDocumentRequest andPurchasingContractLegalDocumentNotification, the message data typePurchasingContractUseMessage is used for the message typesPurchasingContractUseRequest and PurchasingContractUseConfirmation, andthe message data type PurchasingContractReleaseMessage is used for themessage type PurchasingContractReleaseNotification.

The messages that are described by the message data typesPurchasingContractLegalDocumentMessage and PurchasingContractUseMessageuse the object PurchasingContract in the PurchasingContractInformationview.

The PurchasingContractInformation view contains all contract datarequired for A2A contract scenarios. This is why it is used for both thePurchasingContractLegalDocumentMessage and PurchasingContractUseMessagemessages. In both scenarios, a comprehensive transmission of contractinformation is required.

(a) PurchasingContractLegalDocumentRequest

A PurchasingContractLegalDocumentRequest is a request from contractmanagement to document management to create a legal contract text fromthe purchasing contract. The structure of the message typePurchasingContractLegalDocumentRequest is prescribed by the message datatype PurchasingContractLegalDocumentMessage that contains the objectPurchasingContract in the PurchasingContractInformation view. Structuralrestrictions and integration requirements of thePurchasingContractLegalDocumentRequest in regard of the message datatype PurchasingContractLegalDocument message are detailed below. APurchasingContractLegalDocumentRequest message provides documentmanagement with a purchasing contract. In document management,enhancements are carried out and these are then added in the form ofattachments. The structure of the purchasing contract business objectremains unchanged. The process ownership remains with contractmanagement.

(b) PurchasingContractLegalDocumentNotification

A PurchasingContractLegalDocumentNotification is a message from documentmanagement to a contract management with the legal contract document.The structure of the message typePurchasingContractLegalDocumentNotification is prescribed by the messagedata type PurchasingContractLegalDocumentMessage that contains theobject PurchasingContract in the PurchasingContractInformation view.Structural restrictions and integration requirements of thePurchasingContractLegalDocumentNotification in regard of the messagedata type PurchasingContractLegalDocument message are detailed below.The created contract document is transmitted as structural componentLegalDocumentAttachment. The remaining structural components of the MDTPurchaseOrderLegalDocumentMessage are not used.

(c) PurchasingContractUseRequest

A PurchasingContractUseRequest is a request from contract management topurchasing to use the transmitted outline agreement and to take changesin the outline agreement into consideration. The structure of themessage type PurchasingContractUseRequest is prescribed by the messagedata type PurchasingContractUseMessage that contains the objectPurchasingContract in the PurchasingContractInformation view. Structuralrestrictions or integration conditions of thePurchasingContractUseRequest in regard of the message data typePurchasingContractUse message are detailed below. ThePurchasingContractUseRequest message starts a new contract distributioncycle or, where there are changes to the outline agreement in a contractdistribution cycle that has already started, notifies purchasing of thecurrent status.

The outline agreement communicates repeatedly in regard of changes, andimparts the current status of the outline agreement. Changes to headerdata and existing items could have been made, new items might have beenadded, while deleted items might no longer be included. If an itemtransferred at an earlier date is no longer contained in the outlineagreement after a new distribution, this means that the item is deletedfrom the outline agreement.

A legal document created in document management can be contained in thePurchasingContractUseRequest message and sent as an attachment.

The PurchasingContractUseRequest can be sent an unlimited number oftimes—at any time—after the organizational unit responsible for theoutline agreement is been established.

(d) PurchasingContractUseConfirmation

A PurchasingContractUseConfirmation is a confirmation from purchasing tothe contract management concerning the use or change of use of anoutline agreement that has been distributed for use. The structure ofthe message type PurchasingContractUseConfirmation is prescribed by themessage data type PurchasingContractUseMessage that contains the objectPurchasingContract in the PurchasingContractInformation view. Structuralrestrictions or integration conditions of thePurchasingContractUseConfirmation in regard of the message data typePurchasingContractUse Message are detailed below. ThePurchasingContractUseConfirmation message confirms the successfulcreation or change of items in an operational contract by sending theIDs for item and contract with reference to the relevant IDs in theoutline agreement.

Errors when creating or changing local contracts or contract items forthe outline agreement are dealt with by the messaging infrastructure.

The PurchasingContractUseConfirmation contains information on thecreated objects (ID and item ID) for a transmitted outline agreement (IDand item ID). No internal information is communicated in regard of theoperational contract. In particular, no changes to internal parts of acontract are transmitted.

(e) PurchasingContractReleaseNotification

A PurchasingContractReleaseNotification is a notification frompurchasing to contract management concerning a contract release. Anotification concerning a release can be generated from a purchaseorder, goods receipt, service entry, or invoice with reference to atransmitted outline agreement. The structure of the message typePurchasingContractReleaseNotification is prescribed by the message datatype PurchasingContractReleaseMessage. Following aPurchasingContractUseConfirmation, an unlimited number ofPurchasingContractReleaseNotification messages can be sent.

The PurchasingContractReleaseNotification can be triggered by thefollowing objects: a purchase order with contract reference (concreterelease quantity or concrete release value known); a goods receipt inthe case of a limit purchase order (the release amount is determined atthe time of the goods receipt); a service entry in the case of a limitpurchase order (the release amount is determined at the time of theservice entry); and an invoice (for example travel expenses: Hotelinvoice without purchase order in the scope of an outline agreement witha hotel chain).

If the triggering documents are changed, the most currentPurchasingContractReleaseNotification overwrites all messages previouslysent for the respective document.

Deletion of an item of a triggering document is represented in the formof an ActionCode in the PurchasingContractReleaseNotification message.

The PurchasingContractRequest and PurchasingContractConfirmationmessages would support the negotiation process for a purchasingcontract; however both messages will not be implemented in the nearfuture.

(3)

(4) Message Choreography

The following message choreography describes the possible logicalsequence of the messages that can be used to realize the scenariobetween a Document Builder server 49200, a Purchasing ContractManagement server 49202, a Purchasing server 49204, and a Sales server49206.

In the following, the interaction between the representedPurchasingContract interfaces in a contract process is described indetail. There are two distinct scenarios that deal with a particularpart of the contract life-cycle and use specific messages. The firstscenario is the creation of the legal contract document with the twomessages PurchasingContractLegalDocumentRequest 49208 andPurchasingContractLegalDocumentNotification 49210. This occurs withinthe scope of creation of a new purchasing contract or a purchasingcontract that requires renegotiation. The second scenario is thedistribution of an outline agreement that has already been created withthe PurchasingContractUse messages and the monitoring of releases withthe PurchasingContractReleaseNotification. The legal contract documentcreated prior to this can be included in distribution in the form of anattachment.

The purchaser takes the initiative and creates the legal contractdocument. Typically, the contract is in an early stage of the contractlife-cycle, for example the negotiation and creation stage. The creationof the structured document with the business-related data in contractmanagement can occur in the form of a bid invitation or can be createdby the purchaser directly using delivery negotiations as the basis, forexample. Traditionally, the legal department is involved in the creationof the legal text based on the business data framework. After the legalform of words has been agreed upon, it is then signed and istraditionally stored as an unstructured text document on a file server.This manual process of agreement between structured document in contractmanagement and legal text document is transmitted to a system-integratedprocess by the PurchasingContractLegalDocumentRequest message 49208 andthe PurchasingContractLegalDocumentNotification message 49210.

In the scope of contract negotiations, contract management can send thecurrent status of the structured business document to documentmanagement using the PurchasingContractLegalDocumentRequest message49208 at certain times. The conditions that lead to the document beingsent are defined by the user of the external application. This systemcreates the legal text document from the structured data framework. Inthis way, document management can use predefined legal clauses and textmodules in order to organize the internal process of the legaldepartment more efficiently. The legal text document that has beencreated is then sent back to contract management in the form of anattachment with the PurchasingContractLegalDocumentNotification message49210. The structure of the purchasing contract business document doesnot change.

Contract distribution is based on a completed outline agreement that canbe supplemented by an attached legal text document. Settings in thecontract management system determine to which operational purchasingsystems an outline agreement can be distributed for use. Purchasingorganizations can also enter themselves for an outline agreement byassigning themselves to its distribution list.

The outline agreement provides the purchasing organization with theframework for operational purchasing contracts. In addition to the datathat is passed on, operational purchasing contracts can also containelements like additional country-specific information. ThePurchasingContractUseRequest message 49212 andPurchasingContractUseConfirmation 49214 messages on contract managementside are always only requests that outline agreements be used.Purchasing can display the transfer on item-basis using thePurchasingContractUseConfirmation 49214. An internal control process (toestablish which contract data has been changed in which system, forexample) does not occur. Such an alignment process is not workable dueto the potentially high number of affected local purchasing systems.

After changes have been made to the outline agreement, the currentstatus is communicated to all affected systems. Purchasing can thendisplay the transfer of the changed outline agreement on item basis. Acontextual adjustment of transferred changes does not occur here either.

A central monitoring of the contract usage is facilitated by thePurchasingContractReleaseNotification message 49216. ThePurchasingContractReleaseNotification message 49216 transmits tocontract management information on releases for an operational contractthat resulted from an outline agreement. Releases can result frompurchase orders with reference to operational contracts, from serviceentries in the case of limit purchase orders with contract reference, orfrom invoices with contract reference that are created without precedingpurchase order (for example, hotel invoices in the scope of travelexpenses).

The Purchasing server 49204 can send a PurchaseOrderRequest message49218 to the Sales server 49206. Upon successful completion of therequest, the Sales server 49206 can send a PurchaseOrderConfirmationmessage 49220 to the Purchasing server 49204.

As an example of how this choreography may play out, in centralpurchasing, a new outline agreement can be negotiated. The businessdetails of that agreement can be transferred to a document managementsystem for creation of the legal text document. The legal document canbe sent back to central purchasing as an attachment. Before the finalconclusion of a contract, two changes might be necessary to both thebusiness document in the contract management system and to the legaldocument in the external application. The global outline agreement canbe finally signed and transmitted to five affected purchasing systems.Two purchasing organizations can confirm the creation of local contractitems for all transferred items of the outline agreement. The threeother purchasing organizations only notify the transfer of individualitems of the outline agreement to an operational purchasing contract andneed to carry out some content changes and some country-specificchanges. A field control in the systems can be used to prevent certainfields from being changed and guidelines for possible changes andenhancements are defined on an organizational level. In the scope ofoperational daily business, central purchasing is notified of thecurrent status of contract usage due to the transfer of local contractreleases.

To serialize the messages, the messages within a contract process aretransferred exactly once in order (EOIO) and are serialized usingmessage queues. There should be one message queue per contract process(and not just one queue for all contract processes). This helps preventone erroneous message from blocking all other contract messagesthroughout the whole system.

To handle errors, business errors have to be sorted out in the correctorder. A receiving system should accept every formal contract messagethat is received correctly. In contract management, business errors haveto be resolved via a PurchasingContractUseRequest message or aPurchasingContractLegalDocumentRequest message. In the purchasingsystem, the errors have to be resolved by aPurchasingContractUseConfirmation message, and in the documentmanagement system, by a PurchasingContractLegalDocumentNotificationmessage. The receiving system differentiates between technical andbusiness errors. Borderline cases also exist. These are, for example,erroneous ISO codes for currency, language, and so on. Where a corruptcontract process has to be restarted as a result of an erroneousmessage, the contract management system has to provide a way to transmitthe current status of the outline agreement with aPurchasingContractUseRequest message orPurchasingContractLegalDocumentRequest including all data, at all times.To restart a process after an erroneous PurchasingContractUseRequest orPurchasingContractLegalDocumentRequest message, the purchasing systemshould always be in a position to start a contract process again with aPurchasingContractUseRequest or PurchasingContractLegalDocumentRequestmessage. The contract management system uses the error to decide whetherone, several, or all affected systems are to be considered in therelease process.

(5) Message Interfaces

The PurchasingContractLegalDocument messages are implemented by twomessage interfaces on the side of the contract management system. Oncontract management side, these are:PurchasingContractLegalDocumentRequest_Out andPurchasingContractLegalDocumentNotification_In. The messages in thecontract distribution process are implemented by the following messageinterfaces on contract management system side and purchasing systemside. On contract management side, these are:PurchasingContractUseRequest_Out, PurchasingContractUseConfirmation_In,and PurchasingContractReleaseNotification_In. On purchasing system side,these are: PurchasingContractUseRequest_In,PurchasingContractUseConfirmation_Out, andPurchasingContractReleaseNotification_Out.

(6) Message Data Type PurchasingContractUseMessage

FIGS. 493A-D depict a data model of the message data typePurchasingContractUseMessage. The message data typePurchasingContractUseMessage groups the business information that isrelevant for the sending of a business document in a message and thePurchasingContract object in the business document in the view that isrequired by PurchasingContractUse. A PurchasingContractUseMessagepackage 49301 contains packages: MessageHeader package BB02 andPurchasingContract package 49303. The PurchasingContractUseMessagepackage 49301 also contains a PurchasingContractUseMessage entity 49304.

The following rules can govern the use of elements and entities withinthe message data type PurchasingContractMessage in regard of theirchangeability within a contract process:

If it has been specified that the element or the entity cannot bechanged, changes are not permitted after creation. The element or theentity can be assigned a new value during creation of a contract or whena new item is created within a contract. This value cannot be changed insubsequent messages.

When referring to changes, the description of this interface isreferring to those changes that are actually real changes and notanother representation of the same data (For example, the same productcan be referenced by a proprietary ID or a standard ID. Both options arejust different representations of the same data and can be usedinterchangeably and do not constitute changes). This same content isdeemed to be a different ID for the same object and a different order inthe case of elements that occur more than once. Other same content isdescribed explicitly for the relevant element or entity.

If certain elements or entities of the PurchasingContractUseMessagemessage data types are not used in all message types that are based onthe PurchasingContractUseMessage message data types, this can bespecified as “Integration Conditions.”

The message data type PurchasingContractUseMessage provides thestructure for the message types PurchasingContractUseRequest,PurchasingContractUseConfirmation, and the interfaces that are based onthem.

(a) MessageHeader Package

A MessageHeader package 49302 groups the business information that isnecessary to send a business document in a message. The MessageHeaderpackage 49302 contains a MessageHeader entity 49305.

The MessageHeader entity 49305 is the quantity of non-technicaladministrative information in the PurchasingContractUse message. ASenderParty entity 49306 and a RecipientParty entity 49307 exist for theMessageHeader entity 49305. There is a 1:1 relationship between thePurchasingContractUseMessage entity 49304 and the MessageHeader entity49305. There is a 1:cn relationship between the MessageHeader entity49305 and the RecipientParty entity 49307. Where a relationship isidentified between entitites in FIGS. 493A-D for this Interface, therespective relationship is a 1:c relationship unless otherwise notedherein or indicated in FIGS. 493A-D.

The MessageHeader contains the elements: MessageID, ReferencedMessageID,and CreationDateTime. The MessageID is the unique identification of theBusinessDocument. MessageID is of the type GDT: MessageID. TheReferencedMessageID is the unique reference to a precedingBusinessDocument. ReferencedMessageID is of the type GDT: MessageID.CreationDateTime is the time when the BusinessDocument was created.CreationDateTime is of type GDT: DateTime.

The SenderParty entity 49306 is a party that is the business sender of amessage. The SenderParty entity 49306 is of the type GDT:BusinessTransactionDocumentParty. The SenderParty entity 49306 can befilled by the sending application to specify a contact person shouldthere be problems with the message. The SenderParty entity 49306 is onlyintended as an aid during message transmission and can be ignored by thereceiving application.

The RecipientParty entity 49307 is a party that is a business recipientof a message. The RecipientParty entity 49307 is of the type GDT:BusinessTransactionDocumentParty.

(b) PurchasingContract Package

A PurchasingContract package 49303 groups a PurchasingContract with itspackages. The PurchasingContract package 49303 contains the packages:Party package 49308, Location package 49309, DeliveryInformation package49310, PaymentInformation package 49311, PriceInformation package 49312,Attachment package 49314, Description package 49315, and Item package49316. The PurchasingContract package 49303 also contains aPurchasingContract entity 49317.

A PurchasingContract entity 49317 is an outline agreement to orderproducts (including performance of services) within a certain period oftime that is binding for all parties. Total quantities or total valuesand also conditions that are to be released are defined in a contract. APurchasingContract entity 49317 can contain company-internalinformation, such as details on affected organizational units. ThePurchasingContract is subdivided into PurchasingContractItems thatcontain data on product or additional information for such a product(see PurchasingContractItem package). The price agreements for a productare listed. (See the PriceInformation package).

As well as the purchasing party and the seller, further parties can alsobe involved with the PurchasingContract (see Party package). Locationscan be defined for the delivery of the PurchasingContract (see Locationpackage). Delivery and payment details are also agreed (seeDeliveryInformation package or PaymentInformation package). It ispossible to add notes to the PurchasingContract or to specify links toattachments (see Description package or Attachment package). It is alsopossible to define the types of follow-on documents are expected for thePurchasingContract package (see BusinessTransactionDocumentReferencepackage).

The PurchasingContract entity 49317 is of the typePurchasingContractInformation. There is a 1:1 relationship between thePurchasingContractUseMessage entity 49304 and the PurchasingContractentity 49317. The PurchasingContract entity 49317 contains the elements:ID, CreationDateTime, LastChangeDateTime, CompletedIndicator,BlockedIndicator, ValidityPeriod, Note, and TargetAmount. The ID is theunique identifier assigned by the purchaser for the purchasing contract.The CreationDateTime is the creation time of the PurchasingContractdocument. The CreationDateTime is of the type GDT: DateTime. TheLastChangeDateTime is the time of the last change of the purchasingcontract by the purchaser. The LastChangeDateTime is of the type GDT:DateTime. The CompletedIndicator specifies whether or not the purchasingcontract has been completed by releases with contract reference. TheCompletedIndicator is of the type GDT:BusinessTransactionCompletedIndicator. The BlockedIndicator specifieswhether or not a purchasing contract is locked for releases. A validityperiod is not defined when the indicator is set. The BlockedIndicator isof the type GDT: BusinessTransactionBlockedIndicator. the ValidityPeriodis the validity period of the PurchasingContract document. TheValidityPeriod is of the type GDT: DateTimePeriod. The Note is a shortdescription or title of the PurchasingContract document. It is generallyused to provide the user with a simple way to search for a certainPurchasingContract document. The note is of type GDT: Note. TheTargetAmount describes the target value of a purchasing contract. TheTargetAmount is of type GDT: Amount.

Within a purchasing contract, monetary amounts and prices can bemaintained in the same currency. The ID is not changed after creation ofthe purchasing contract. The CreationDateTime is not changed aftercreation of the purchasing contract. The BlockedIndicator in thedocument header, if set to “true”, overrides the ActiveIndicator at itemlevel. The CompletedIndicator, if set to “true” in the document header,overrides the ActiveIndicator at item level.

A purchasing contract is a business object that contains the subtypesoutline agreement and operational purchasing contract. Unlike withoutline agreements, releases can occur from an operational contract.

(i) PurchasingContractParty Package

The Party package 49308 groups business parties that can feature in oneof the PurchasingContractUse messages. The Party package 49308 containsthe entities: BuyerParty entity 49319, SellerParty entity 49321,ProductRecipientParty entity 49322, and ContractReleaseAuthorisedPartyentity 49323. Either the ID, or address and ID can be transmitted foreach party. If the ID is transmitted, the address for the ID stored inthe master data is relevant. If ID and address are transmitted, the IDidentifies the party and the address is the document address thatdiffers from the address stored in the master data. If possible, both IDand address can be sent to prevent misunderstandings. The receivingapplication can implement a suitable optimization strategy to preventlots of identical document addresses.

For parties, default logic applies from the header to the items, andwithin item hierarchies. Parties that are specified in the header applyfor items for which no relevant party is explicitly transferred andwhich are directly on the header. Parties that are transferred on itemlevel apply for subitems that are under the relevant item in the itemhierarchy. The default logic applies for the party including contactperson as a whole. On item level, no parts of a party on header level orin a hierarchy can be specified more precisely. The default logic is asimplification of the message that is transferred. From a logicalstandpoint, parties on the header and hierarchy items behave as if theywere explicitly transferred. This also means that when not all, but justchanged items are transferred, the parties only apply for thetransferred items. If a party is changed, then all items that are validfor this party are also changed.

The BuyerParty entity 49319 is a party that purchases a product orservice in accordance with an outline agreement. The BuyerParty entity49319 is of the type GDT: BusinessTransactionDocumentParty. TheBuyerParty entity 49319 contains the responsible purchaser. InPurchasingContract messages, the BuyerParty entity 49319 can bespecified on a header level. In some implementations, the BuyerPartyentity 49319 must be specified.

The SellerParty entity 49321 is a party that sells goods/services inaccordance with an outline agreement. The SellerParty entity 49321 is ofthe type GDT: BusinessTransactionDocumentParty. In PurchasingContractmessages, the SellerParty entity 49321 can be specified on a headerlevel (e.g., restricted to only being specified on a header level).

In a contract scenario, a ProductRecipientParty entity 49322 is a partythat receives goods or services. The ProductRecipientParty entity 49322is of the type GDT: BusinessTransactionDocumentParty. TheProductRecipientParty entity 49322 is not used as a synonym for theShipToLocation. It should only be used if the ProductRecipientPartyentity 49322 really does differ from the BuyerParty entity 49319 ascompany or person.

The ContractReleaseAuthorisedParty entity 49323 is a party that isauthorized to effect releases from a purchasing contract. TheContractReleaseAuthorisedParty entity 49323 is of the type GDT:BusinessTransactionDocumentParty. There is a 1:cn relationship betweenthe PurchasingContract entity 49317 and theContractReleaseAuthorizedParty entity 49323. In the PurchasingContractmessages, the ContractReleaseParty entity 49323 can be specified on aheader level. The release-authorized purchasing organization isauthorized to effect releases from a contract. The releases occur frompurchase orders, and from goods receipts/service entries and invoices inthe case of limit purchase orders. If the releases occur from purchaseorders, the ContractReleaseAuthorisedParty entity 49323 is theBuyerParty entity 49319 in the following order process.

(ii) PurchasingContractLocation Package

The Location package 49309 groups locations that are relevant for apurchasing contract. The Location package 49309 contains aShipToLocation entity 49328. Default logic applies for the location,analogous to the default logic for parties. Either the ID, or theaddress, or both can be transmitted for each location. If the ID istransmitted, the address for the ID stored in the master data isrelevant. If the address is transmitted, this address applies (it mightbe necessary to assign a location at the recipient address). If both IDand address are transmitted, the ID identifies the location and theaddress is the document address that differs from the address stored inthe master data. Both ID and address can be sent to preventmisunderstandings. The receiving application can implement a suitableoptimization strategy to prevent lots of identical document addresses.

The ShipToLocation entity 49328 is the location where goods are to bedelivered/services are to be performed. The ShipToLocation entity 49328is of the type GDT: BusinessTransactionDocumentLocation.

(iii) PurchasingContractDeliveryInfommation Package

The DeliveryInformation package 49310 groups information for a deliveryrequested in a purchasing contract. The DeliveryInformation package49310 contains a DeliveryTerms entity 49329. Default logic applies forthe DeliveryTerms entity 49329. This default logic is analogous to thedefault logic for Parties.

The DeliveryTerms entity 49329 is the conditions and agreements thatapply to the delivery and transport of ordered goods and to thenecessary services and activities. The DeliveryTerms entity 49329 is ofthe type GDT: DeliveryTerms. The DeliveryTerms entity 49329 contains theentities: Incoterms entity 49330 and QualityTolerance entity 49331. TheIncoterms entity 49330 is used for material items. The default logictakes the Incoterms entity 49330 and transport into account in the caseof material items. The Incoterms entity 49330 and transport are ignoredfor other items.

(iv) PurchasingContractPaymentInformation Package

The PaymentInformation package 49311 contains the entities:CashDiscountTerms entity 49332 and PaymentForm.

The CashDiscountTerms entity 49332 is the payment conditions in an orderprocess. The CashDiscountTerms entity 49332 is of type GDT:CashDiscountTerms. The CashDiscountTerms entity 49332 contains theentities: MaximumDiscount entity 49333 and NormaIDiscount entity 49334.

The PaymentForm entity is the payment method with the necessary data forthe payment method. The PaymentForm entity contains a PaymentFormCodeelement. The PaymentFormCode is the coded representation of the paymentmethod. The PaymentFormCode is of the type GDT: PaymentFormCode. ThePaymentForm contains a PaymentCard entity The PaymentCard entity is acredit card or a customer card. The PaymentCard entity is of the typeGDT: PaymentCard. The PaymentCard entity can be used for the paymentmethod PaymentCard (PaymentFormCode “02”).

(v) PriceInformation Package

The PriceInformation package 49312 is the grouping of price informationwith reference to the purchasing contract. The PriceInformation package49312 contains a PriceSpecificationElement entity 49335. ThePurchasingContract entity 49317 has a 1:cn relationship withPriceSpecificationElement entity 49335.

The PriceSpecificationElement entity 49335 is the definition of a price,a discount or a surcharge that is dependent on a combination ofproperties and that is valid for a certain period of time. ThePriceSpecificationElement entity 49335 is of type GDT:PriceSpecificationElement.

(vi) PurchasingContractAttachment Package

The Attachment package 49314 is the grouping of attachment informationwith reference to the purchasing contract. The Attachment package 49314contains the entities: AttachmentWebAddress entity 49336,InternalAttachmentWebAddress entity 49337, and LegalDocumentAttachmententity 49338. The PurchasingContract entity 49317 has a 1:cnrelationship with AttachmentWebAddress entity 49336,InternalAttachmentWebAddress entity 49337, and LegalDocumentAttachmententity 49338 The AttachmentWebAddress entity 49336 is a WebAddress for adocument that refers to a PurchasingContract. The AttachmentWebAddressentity 49336 is of the type GDT: WebAddress.

An InternalAttachment entity 49337 is a WebAddress for a document (forinternal use) that refers to a PurchasingContract. TheInternalAttachmentWebAddress entity 49337 is of type GDT: WebAddress.

A LegalDocumentAttachment entity 49338 is an attachment that containsthe legal contract text of the PurchasingContract. The Attachment entity49338 is of the type GDT: Attachment.

(vii) PurchasingContractDescription Package

The Description package 49315 is the grouping of texts with reference tothe purchasing contract. The Description package 49315 contains theentities: Description entity 49340 and InternalDescription entity 49341.

The Description entity 49340 is a more visible, more explanatory textfor the business partner, with reference to the purchasing contract. TheDescription entity 49340 is of the type GDT: Description. TheDescription entity 49340 can be used for types of textual informationthat refer to the transmitted purchasing contract and not just to thecurrent message. An example of this could be a note that details thatthe responsible employee in purchasing is on holiday from a certaindate, and that provides the name and telephone number of a substitutefor this period.

The InternalDescription entity 49341 is a descriptive text withreference to the purchasing contract that is not visible to the businesspartner. The description entity 49341 is of the type GDT: Description.

(viii) PurchasingContractItem Package

The PurchasingContractItem package 49316 groups thePurchasingContractItem with its packages. The PurchasingContractItempackage 49316 contains the following packages: ProductInformationpackage 49342, PriceInformation package 49343, Party package 49344,Location package 49345, DeliveryInformation package 49347,BusinessDocumentObjectReference package 49348, Attachment package 49350,and Description package 49351. The PurchasingContractItem package 49316also contains a PurchasingContractItem entity 49352.

The PurchasingContractItem entity 49352 specifies a certain product in apurchasing contract or additional information for such a product. ThePurchasingContractItem entity 49352 contains detailed data for a product(see Product package) and its price (see Price package). The priceconditions that contain the price depending on order quantity belong tothe Price package.

It is possible to define differing parties and delivery methods (thanthose in the PurchasingContractDocument) for the PurchasingContractItem(see Party Package, DeliveryInformation Package). ThePurchasingContractItem can contain references to other businessdocuments that are relevant for the item (seeBusinessTransactionDocumentReference package). Furthermore, it ispossible to create notes or links to attachments for the item (seeDescription package or Attachment package).

A PurchasingContractItem entity 49352 can be hierarchically assigned ata lower level to another PurchasingContractItem entity 49352 in order torepresent a business connection between the two items. This could takethe form of a discount in kind or substitute product for an orderedproduct.

This assignment can also lead to a grouping of the items of a purchasingcontract, meaning that a PurchasingContractItem entity 49352 can groupfurther PurchasingContractItems entity 49352.

The PurchasingContractItem entity 49352 is of the typePurchasingContractDocumentItem. The PurchasingContractItem entity 49352contains the following elements: ID, AcitveIndicator, TypeCode,TargetQuantity, TargetAmount, MinimumOrderQuantity, andMinimumOrderAmount. The ID is a contract item identifier assigned by thepurchaser that is unique within a purchasing contract. The ID is of typeGDT: BusinessTransactionDocumentItemID. The AcitveIndicator specifieswhether or not a purchasing contract may be used. The ActiveIndicator isof type GDT: ActiveIndicator. The TypeCode is a coded representation ofthe type of an item of a purchasing contract. The TypeCode is of typeGDT: BusinessTransactionDocumentItemTypeCode. The TargetQuantity is anenvisaged total quantity for the product that is to be purchased withinthe scope of a purchasing contract. The TargetQuantity is of the typeGDT: Quantity. The TargetAmount is an envisaged total value for theproduct that is to be purchased within the scope of a purchasingcontract. The TargetAmount is of type GDT: Amount. TheMinimumOrderQuantity is a minimum order quantity for the product that isto be purchased within the scope of a purchasing contract. TheMinimumOrderQuantity is of type GDT: Quantity. The MinimumOrderAmount isa minimum order value for the product that is to be purchased within thescope of a purchasing contract. The MinimumOrderAmount is of type GDT:Amount.

The ID is not changed after an item has been created. Dependencies ofelements or entities of item type are described below.

(a) PurchasingContractItemProductInformation Package

The ProductInformation package 49342 is the grouping of information foridentification, description, and classification of a product that can beprocured using a purchasing contract item. The ProductInformationpackage 49342 contains the entities: Product entity 49354 andProductCategory entity 49355. A product or a product category can bespecified.

The Product entity 49354 is the identification, description, andclassification of a product or service. The Product entity 49354 is oftype GDT: BusinessTransactionDocumentProduct. In some implementations,only the InternalID is used.

The ProductCategory entity 49355 is the product category of a product orservice. The ProductCategory entity 49355 is of type GDT:BusinessTransactionDocumentProductCategory. In some implementations,only the InternalID is used.

(b) PurchasingContractItemPriceInformation Package

The PurchasingContractitemPriceInformation package 49343 contains aPriceSpecificationElement entity 49356. ThePurchasingContractItemPriceInformation package 49343 is analogous toPurchasingContractPriceInformation package 49312 in the header.

(c) PurchasingContractItemParty Package

The Party package 49344 groups relevant parties for a purchasingcontract item. The Party package 49344 contains a ProductRecipientPartyentity 49361.

The ProductRecipientParty entity 49361 is a party to which goods aredelivered or for which services are performed. The ProductRecipientPartyentity 49361 is of the type GDT: BusinessTransactionDocumentParty. If noShipToLocation is explicitly specified in an order process, the addressof the ShipToParty is taken as the delivery address.

The ProductRecipientParty entity 49361 is not be used as a synonym forthe ShipToLocation and can be used if the ProductRecipientParty entity49361 differs from the BuyerParty as company or person.

In the contract distribution scenario, the ProductRecipientParty entity49361 can be specified for a certain item that differs from theProductRecipientParty entity 49361 on header level according to thedefault logic.

(d) PurchasingContractItemLocation Package

The Location package 49345 groups relevant locations for a purchasingcontract item. The Location package 49345 contains a ShipToLocationentity 49365.

The ShipToLocation entity 49365 is the location to which goods are to bedelivered or at which a service is to be performed. The ShipToLocationentity 49365 is of the type GDT: BusinessTransactionDocumentLocation. Inthe contract distribution scenario, a certain ShipToLocation entity49365 can be specified for a certain item that differs from theShipToLocation on header level according to the default logic.

(e) PurchasingContractItemDeliveryItemOInformation Package

The PurchasingContractItemDeliveryInformation package 49347 contains aDeliveryTerms entity 49367. The DeliveryTerms entity 49367 contains theentities: Incoterms entity 49368 and QuantityTolerance entity 49369. ThePurchasingContractItemDeliveryInformation package 49347 is analogous tothe PurchasingContractDeliveryInformation package 49310 in the headerarea.

(f) PurchasingContractItemBusinessDocumentObjectReference Package

The BusinessDocumentObjectReference package 49348 is the grouping ofreferences to business documents that are relevant for thePurchasingContractDocumentItem and are connected to the item in abusiness sense. The BusinessDocumentObjectReference package 49348contains the entities: QuoteReference entity 49370,OperationalPurchasingContractReference entity 49371, andBuyerProductCatalogueReference entity 49372.

The QuoteReference entity 49370 is the reference to a bid of thepurchaser or to an item within a bid. The QuoteReference entity 49370 isof type GDT: BusinessTransactionDocumentReference.

The OperationalPurchasingContractReference entity 49371 is the referenceto an operational purchasing contract or to an item within anoperational purchasing contract. TheOperationalPurchasingContractReference entity 49371 is of type GDT:BusinessTransactionDocumentReference.

The BuyerProductCatalogueReference entity 49372 is the reference to aproduct catalog of the purchaser or to an item within such a catalog.The BuyerProductCatalogueReference entity 49372 is of type GDT:CatalogueReference. A BuyerProductCatalogueReference entity 49372 canreference one item. This means that a maximum of one ItemID ispermitted. The BuyerProductCatalogueReference entity 49372 can be filledif a contract item refers to a catalog whose number and item numbershave been assigned by the purchaser.

(g) PurchasingContractItemAttachment Package

The Attachment package 49350 is the grouping of attachments informationwith reference to a purchasing contract item. The Attachment package49350 contains the entities: Attachment entity 49380 andInternalAttachment entity 49381.

The Attachment entity 49380 is a WebAddress for a document that refersto a PurchasingContractItem. The Attachment entity 49380 is of type GDT:WebAddress.

The InternalAttachment entity 49381 is a WebAddress for a document thatrefers to a PurchasingContractItem and that is only intended forinternal use. The InternalAttachmentWebAddress entity 49381 is of typeGDT: WebAddress.

(h) PurchasingContractItemDescription Package

The PurchasingContractItemDescription package 49351 contains theentities: Description entity 49382 and InternalDescription entity 49383.The PurchasingContractItemDescription package 49351 is analogous to theDescription package 49315 on the header level.

(7) Message Data Type PurchasingContractReleaseMessage

FIGS. 494A-D depict a data model of the message data typePurchasingContractReleaseMessage. The message data typePurchasingContractReleaseMessage contains the business information thatis relevant for sending of a business document in a message and thePurchasingContractRelease object contained in the business document. ThePurchasingContractReleaseMessage package 49402 contains the packages:MessageHeader package 49404 and PurchasingContractRelease package 49406.The PurchasingContractReleaseMessage package 49402 also contains aPurchasingContractReleaseMessage entity 49408.

The following rules govern the use of elements and entities within themessage data type PurchasingContractMessage in regard of theirchangeability within a contract process:

If it has been specified that the element or the entity cannot bechanged, changes are not permitted after creation. The element or theentity can only be assigned a new value during creation of a contract orwhen a new item is created within a contract. This value cannot bechanged in all subsequent messages.

When referring to changes, the description in this interface isreferring to those changes that are actually real changes and notanother representation of the same data (For example, the same productcan be referenced by a proprietary ID or a standard ID. Both options arejust different representations of the same data and can be usedinterchangeably and do not constitute changes). This same content isdeemed to be a different ID for the same object and a different order inthe case of elements that occur more than once. Other same content isdescribed explicitly under “Notes” for the relevant element or entity.

If certain elements or entities of the PurchasingContractUseMessagemessage data types are not used in all message types that are based onthe PurchasingContractUseMessage message data types, this is specifiedbelow.

The message data type PurchasingContractReleaseMessage provides thestructure for the message types PurchasingContractReleaseRequest and theinterfaces that are based on them.

(a) MessageHeader Package

The MessageHeader package 49404 groups the business information that isnecessary to send a business document in a message. The MessageHeaderpackage 49404 contains a MessageHeader entity 49410. There is a 1:1relationship between the PurchasingContractReleaseMessage entity 49408and the MessageHeader entity 49410. Where a relationship is identifiedbetween entitites in FIGS. 494A-D for this Interface, the respectiverelationship is a 1:c relationship unless otherwise noted herein orindicated in FIGS. 494A-D.

The MessageHeader entity 49410 is the quantity of non-technicaladministrative information in the PurchasingContractRelease message. ASenderParty entity 49412 exists for the MessageHeader entity 49410 aswell as a RecipientParty entity 49414. The MessageHeader entity 49410contains the elements: MessageID, ReferencedMessageID, andCreationDateTime. The MessageID is the unique identification of theBusinessDocument. The MessageID is of type GDT: MessageID. TheReferencedMessageID is the unique reference to a precedingBusinessDocument. The ReferencedMessageID is of the type GDT: MessageID.The CreationDateTime is the time at which the BusinessDocument wascreated. The CreationDateTime is of type GDT: DateTime.

The SenderParty entity 49412 is a party that is the sender of a messagein a business sense. The SenderParty entity 49412 is of type GDT:BusinessTransactionDocumentParty. The SenderParty entity 49412 can befilled by the sending application to specify a contact person shouldthere be problems with the message. The SenderParty entity 49412 is onlyintended as an aid during message transmission and can be ignored by thereceiving application.

The RecipientParty entity 49414 is a party that is a business recipientof a message. The RecipientParty entity 49414 is of the type GDT:BusinessTransactionDocumentParty. There is a 1:cn relationship betweenthe MessageHeader entity 49410 and the RecipientParty entity 49414.

(b) PurchasingContractRelease Package

The PurchasingContractRelease package 49406 groups a PurchasingContractwith its packages. The PurchasingContractRelease package 49406 containsthe packages: Party package 49416, Location package 49418 and Itempackage 49420. The PurchasingContractRelease package 49406 also containsa PurchasingContractRelease entity 49422. There is a 1:1 relationshipbetween the PurchasingContractReleaseMessage entity 49408 and thePurchasingContractRelease entity 49422.

The PurchasingContractRelease entity 49422 (purchasing contract release)is a notification from purchasing to contract management regarding aperformed release with reference to a purchasing contract. A purchasingcontract release can be generated from a purchase order, goods receipt,service entry, or invoice with reference to a contract that has beendistributed for use. The buying party is involved (see Party package).Locations for the delivery of the PurchasingContractRelease can bespecified (see Location package).

The PurchasingContract is subdivided into PurchasingContractItems thatcontain data on the location (see PurchasingContractItem-LocationPackage). In addition, it is possible to include a reference to theoriginal purchasing contract (see BusinessTransactionDocumentReferencepackage).

The PurchasingContractRelease entity 49422 is of the typePurchasingContractRelease. The PurchasingContractRelease entity 49422contains the elements: BaseBusinessTransactionDocumentID,BaseBusinessTransactionDocumentTypeCode, andBaseBusinessTransactionDocumentDateTime. TheBaseBusinessTransactionDocumentID is a unique identifier for a businessdocument on which the PurchasingContractRelease is based and is of typeGDT: BusinessTransactionDocumentID. TheBaseBusinessTransactionDocumentTypeCode is a coded representation of thebusiness document type on which the PurchasingContractRelease is based.The types currently relevant for message type PurchasingContractReleaseare purchase order, invoice, goods receipt and service entry. TheBaseBusinessTransactionDocumentTypeCode is of type GDT:BusinessTransactionDocumentTypeCode. TheBaseBusinessTransactionDocumentDateTime is a document date of a businessdocument on which the PurchasingContractRelease is based and is of typeGDT: DateTime.

The PurchasingContractRelease entity 49422 can be triggered by thefollowing objects: a purchase order with contract reference (concreterelease quantity or concrete release value), a goods receipt in the caseof a limit purchase order (the release amount is set at the time ofgoods receipt), a service entry in the case of a limit purchase order(the release amount is set at the time of service entry), and an invoice(for example travel expenses: Hotel invoice without purchase order usingan outline agreement with a hotel chain).

In the case of a change to the triggering documents, the currentPurchasingContractRelease entity 49422 overwrites information fromPurchasingContractRelease entity 49422 messages sent prior to this.

(i) PurchasingContractReleaseParty Package

The Party package 49416 groups business parties that could occur in oneof the PurchasingContractUse messages. The Party package 49416 containsa BuyerParty entity 49424. Either the ID, or address and ID can betransmitted for each party. If the ID is transmitted, the address forthe ID stored in the master data is relevant. If ID and address aretransmitted, the ID identifies the party and the address is the documentaddress that differs from the address stored in the master data. Both IDand address can be sent to prevent misunderstandings. The receivingapplication can implement a suitable optimization strategy to preventlots of identical document addresses.

For parties, default logic applies from the header to the items, andwithin item hierarchies. Parties that are specified in the header applyfor items for which no relevant party is explicitly transferred andwhich are directly on the header. Parties that are transferred on itemlevel apply for subitems that are under the relevant item in the itemhierarchy. The default logic applies for the party including contactperson as a whole. On item level, no parts of a party on header level orin a hierarchy can be specified more precisely. The default logic isonly a simplification of the message that is transferred. From a logicalstandpoint, parties on the header and hierarchy items behave as if theywere explicitly transferred. This also means that when not all, but justchanged items are transferred, the parties only apply for thetransferred items. If a party is changed, then all items that are validfor this party are also changed.

The BuyerParty entity 49424 is a party that purchases goods or services.The BuyerParty entity 49424 is of type GDT:BusinessTransactionDocumentParty. In some implementations, theBuyerParty must be specified. The ContactPerson specified in theBuyerParty entity 49424 describes the person responsible on thepurchaser-side. The ContactPerson contains the elements BuyerID,SellerID, and entity address.

(ii) PurchasingContractReleaseLocation Package

The Location package 49418 groups relevant locations for a purchasingcontract release. The Location package 49418 contains a ShipToLocationentity 49426.

The ShipToLocation entity 49426 is the location to where goods aredelivered or where a service is to be performed. The ShipToLocationentity 49426 is of type GDT: BusinessTransactionDocumentLocation.

(iii) PurchasingContractReleaseItem Package

The PurchasingContractReleaseItem package 49420 groups thePurchasingContractItem with its packages. ThePurchasingContractReleaseItem package 49420 contains the followingpackages: Location package 49428 and BusinessDocumentObjectReferencepackage 49430. The PurchasingContractReleaseItem package 49420 alsocontains a PurchasingContractReleaseItem entity 49432. There is a 1:cnrelationship between the PurchasingContractRelease entity 49422 and thePurchasingContractReleaseItem entity 49432.

The PurchasingContractReleaseItem entity 49432 specifies a certain itemin a PurchasingContractRelease item or provides additional informationon such an item. This includes information on release quantities andrelease amounts. The PurchasingContractReleaseItem entity 49432 containsdetails on party and location. Differing parties and locations can bedefined for the PurchasingContractReleaseItem (see Party package,Location package). The PurchasingContractReleaseItem can containreferences to other business documents that are relevant for the item(see BusinessDocumentObjectReference package). ThePurchasingContractReleaseItem entity 49432 is of the typePurchasingContractReleaseItem. The PurchasingContractReleaseItem entity49432 contains the elements: BaseBusinessTransactionDocumentItemID,BaseBusinessTransactionDocumentItemTypeCode, ReleaseQuantity, andRelaseAmount. The BaseBusinessTransactionDocumentItemID is a uniqueidentifier of item type in a business document on which thePurchasingContractReleaseItem is based and is of type GDT:BusinessTransactionDocumentItemID. TheBaseBusinessTransactionDocumentItemTypeCode is a coded representation ofitem type of a business document on which thePurchasingContractReleaseItem is based and is of type GDT:BusinessTransactionDocumentItemTypeCode. The ReleaseQuantity describesthe quantity released from a purchasing contract and is of type GDT:Quantity. The ReleaseAmount describes the value released from apurchasing contract and is of type GDT: Amount.

The PurchasingContractReleaseItem contains the elements:BaseBusinessTransactionDocumentID,BaseBusinessTransactionDocumentTypeCode, andBaseBusinessTransactionDocumentDateTime, ReleaseQuantity, andReleaseAmount. The BaseBusinessTransactionDocumentID is a uniqueidentifier for a business document based on the originalPurchasingContractRelease and is of type GDT:BaseBusinessTransactionDocumentID. TheBaseBusinessTransactionDocumentTypeCode is a coded representation of thebusiness document type based on the original PurchasingContractRelease.Currently, the types purchase order, invoice, goods receipt, and serviceconfirmation are relevant for the message typePurchasingContractRelease. The BaseBusinessTransactionDocumentTypeCodeis of type GDT: BaseBusinessTransactionDocumentTypeCode. TheBaseBusinessTransactionDocumentDateTime is a document date of a businessdocument that is based on the original PurchasingContractRelease and isof type GDT: DateTime. The ReleaseQuantity describes the releasedquantity from a purchasing contract and is of type GDT: Quantity. TheReleaseAmount describes the released value from a purchasing contractand is of type GDT: Amount.

In some implementations, the ID must not be changed after an item hasbeen created. Dependencies of elements or entities of item type aredescribed below.

(a) PurchasingContractReleaseItemLocation Package

The Location package 49428 groups relevant locations for a contractrelease item. The Location package 49428 contains a ShipToLocationentity 49434.

The ShipToLocation entity 49434 is the location where goods are to bedelivered/services are to be performed. The ShipToLocation entity 49434is of the type GDT: BusinessTransactionDocumentLocation.

(b) PurchasingContractReleaseItemBusinessDocumentObjectReference Package

The BusinessDocumentObjectReference package 49430 is the grouping ofreferences to business documents that are relevant for thePurchasingContractDocumentItem and have a business connection to theitem. The BusinessTransactionDocumentReference package 49430 contains aPurchasingContractReference entity 49436. There is a 1:1 relationshipbetween the Item entity 49432 and the PurchasingContractReference entity49436.

The PurchasingContractReference entity 49436 is the reference to aPurchasingContract of the purchaser or to an item within such aPurchasingContract. The PurchasingContractReference entity 49436 is ofthe type GDT: BusinessTransactionDocumentReference. ThePurchasingContractReference entity 49436 has the cardinality 1. ThePurchasingContractReference entity 49436 contains the reference to theoperational purchasing contract.

(8) Message Data Type PurchasingContractLegalDocument Message

The message data type PurchaseOrderLegalDocumentMessage contains thebusiness information that is required to send a business document in amessage and the object PurchasingContract contained in the businessdocument in the view required by the PurchaseOrderLegalDocument. ThePurchaseOrderLegalDocumentMessage package contains the packages:MessageHeader package and PurchasingContract package.

The message data type PurchasingContractLegalDocumentMessage providesthe structure for the message typesPurchasingContractLegalDocumentRequest andPurchasingContractLegalDocumentNotification and the interfaces that arebased on them.

(a) MessageHeader Package

This is analogous to the MessageHeader package 49302 in thePurchasingContractMessage.

(b) PurchasingContract Package

This is analogous to the PurchasingContractRelease package 49303.

Differing integration conditions regarding the message typesPurchasingContractLegalDocumentRequest andPurchasingContractLegalDocumentNotification are listed as follows:within the Party package, the BuyerParty entity is optional; within thePurchasingContractAttachment package the InternalAttachmentWebAddressentity is not available for transmission to document management and maynot be used for this reason; within the PurchasingContractDescriptionpackage the InternalDescription entity is not available for transmissionto document management and may not be used for this reason; and withinthe PurchasingContractItemAttachment package theInternalAttachmentWebAddress is not available for transmission todocument management.

(9) PurchasingContractRelease Element Structure

The message data type element structure for the Invoice message isdepicted in FIG. 495A-D. The element structure is similar to the datamodel, but provides additional information regarding the details of theinterface. The element structure identifies the different packages 49500in the interface, and represents the entities at various levels withinthe interface. As depicted in FIG. 495A, the interface for PurchasingContract Release Message includes five levels 49502, 49504, 49506,49508, and 49510. The outermost package of this interface is aPurchasing Contract Release Message 49518, which includes a PurchasingContract Release Message entity 49520 at the first level 49502. TheInvoice entity 49520 is of a data type MDT 49522“PurchasingContractReleaseMessage” 49524.

The Purchasing Contract Release Message package 49518 includes aPurchasing Contract Release package 49526. The Purchasing ContractRelease package 49526 includes a PurchasingContractRelease entity 49528.The PurchasingContractRelease entity 49528 is a“PurchasingContractRelease” 49532, and there is one“PurchasingContractRelease” 49532 for each Purchasing Contract Releasepackage 49526.

The PurchasingContractRelease entity 49528 includes aBaseBusinessTransactionDocumentID 49534, aBaseBusinessTransactionDocumentTypeCode 49544, aBaseBusinessTransactionDocumentDateTime 49554. TheBaseBusinessTransactionDocumentID 49534 is a GDT 49538“BusinessTransactionDocumentID” 49540, and there is one 49536BaseBusinessTransactionDocumentID 49534 for a PurchasingContractReleaseentity 49528. The BaseBusinessTransactionDocumentTypeCode 49544 is a GDT49548 “BusinessTransactionDocumentID” 49550, and there is one 49546BaseBusinessTransactionDocumentTypeCode 49544 for aPurchasingContractRelease entity 49528. TheBaseBusinessTransactionDocumentDateTime 49554 is a GDT 49558 “DateTime”49560, and there is either zero or one 49556BaseBusinessTransactionDocumentDateTime 49554 for aPurchasingContractRelease entity 49528.

The Purchasing Contract Release package 49526 also includes a Partypackage 49562, a Location package 49502A, and an Item package 49512A.The Party package includes a BuyerParty entity 49562. The BuyerPartyentity 49564 GDT 49568 “BusinessTransactionDocumentParty” 49570, andthere is either zero or one 49566 BuyerParty entity 49562 for each Partypackage 49562.

The BuyerParty entity 49562 includes an InternalID 49574, a StandardID49584, and a ContactPerson 49594. The InternalID 49574 is a GDT 49578“PartyInternalID” 49580, and there is either zero or one 49576InternalID 49574 for a BuyerParty entity 49562. The StandardID 49584 isa GDT 49588 “PartyStandardID” 49590, and there is from zero to anynumber 49586 StandardID 49584 for a BuyerParty entity 49562. TheContactPerson 49594 is a GDT 49598 “ContactPerson” 49500A, and there iseither zero or one 49596 ContactPerson 49594 for a BuyerParty entity49562.

The Location package 49502A includes a ShipToLocation entity 49504A. TheShipToLocation entity 49504A is GDT 49508A“BusinessTransactionDocumentShipToParty” 49510A, and there is eitherzero or one 49506A ShipToLocation entity 49504A for each Locationpackage 49502A.

The Item package 49512A includes an Item entity 49514A. The Item entity49514A is a “PurchaseContractReleaseItem” 49518A, and there is from oneto any number 49516A Item entity 49514A for each Item package 49512A.The Item entity 49514A includes a BaseBusinessTransactionDocumentItemID49524A, a BaseBusinessTransactionDocumentItemTypeCode 49534A, aReleaseQuantity 49544A, and a ReleaseAmount 49554A. TheBaseBusinessTransactionDocumentItemID 49524 is a GDT 49528A“BusinessTransactionDocumentItemID” 49530A, and there is one 49526ABaseBusinessTransactionDocumentItemID for an Item entity 49514A. TheBaseBusinessTransactionDocumentItemTypeCode 49534A is a GDT 49538A“BusinessTransactionDocumentItemTypeCode” 49540A, and there is one49536A BaseBusinessTransactionDocumentItemTypeCode 49534A for an Itementity 49514A. The ReleaseQuantity 49544A is a GDT 49548A “Quantity”49550A, and there is either zero or one 49546A ReleaseQuantity 49544Afor an Item entity 49514A. The ReleaseAmount 49554A is a GDT 49558A“Amount” 49560A, and there is either zero or one 49556A ReleaseAmount49554A for an Item entity 49514A.

The Item package 49512A also includes a Location package 49562A and aBusinessDocumentObjectReference package 49572A. The Location package49562A includes a ShipToLocation entity 49564A. The ShipToLocationentity 49564A is GDT 49568A “BusinessTransactionDocumentShipToParty”49570A, and there is either zero or one 49566A ShipToLocation entity49564A for each Location package 49562A.

The BusinessDocumentObjectReference package 49572A includes aBusinessContractReference entity 49574A. The BusinessContractReferenceentity 49574A is a GDT 49578A “BusinessTransactionDocumentReference”49580A, and there is one 49576A BusinessContractReference entity foreach BusinessDocumentObjectReference package 49572A. TheBusinessContractReference entity 49574A includes an ID 49584A and anItemID 49594A. The ID 49584A is a GDT 49588A“BusinessTransactionDocumentID” 49590A, and there is one 49586A ID49594A for a BusinessContractReference entity 49574A. The ItemID 49594Ais a GDT 49598A “BusinessTransactionDocumentItemID” 49599A, and there isfrom zero to any number 49596A ItemID 49594A for aBusinessContractReference entity 49574A.

(10) PurchasingContract Element Structure

The message data type element structure for the Purchasing Contractmessage is depicted in FIGS. 496A-K. The element structure is similar tothe data model, but provides additional information regarding thedetails of the interface. The element structure identifies the differentpackages 49600 in the interface, and represents the entities at variouslevels within the interface. As depicted in FIG. 496A, the interface forPurchasing Contract Message includes five levels 49601, 49602, 49603,49604 and 49605. The outermost package of this interface is aPurchasingContractMessage package 49608, which includes a PurchasingContract Message entity 49609 at the first level 49601. The PurchasingContract Message entity 49609 is of data type MDT 49607“PurchasingContractInformationMessage” 49610.

The PurchasingContractMessage package 49608 includes aPurchasingContract package 49611. The PurchasingContract package 49611includes a PurchasingContract entity 49612 at the second level 49602.The PurchasingContract entity 49612 is a “PurchasingContractInformation”49614, and there is one 49613 PurchasingContract entity 49612 for aPurchasingContractMessage package 49608.

The PurchasingContract entity 49612 includes an ID 49615, aCreationDateTime 49618, a LastChangeDateTime 49621, a CompletedIndicator49624, a BlockedIndicator 49627, a Note 49630, a ValidityPeriod 49633,and a TargetAmount 49636. The ID 49615 is a“BusinessTransactionDocumentID” 49617, and there is one 49616 ID 49615for a PurchasingContract entity 49612. The CreationDateTime 49618 is a“DateTime” 49620, and there is either zero or one 49619 CreationDateTime49618 for a PurchasingContract entity 49612. The LastChangeDateTime49621 is a “DateTime” 49623, and there is either zero or one 49622LastChangeDateTime 49621 for a PurchasingContract entity 49612. TheCompletedIndicator 49624 is a “BusinessTransactionCompletedIndicator”49626, and there is either zero or one 49625 CompletedIndicator 49624for a PurchasingContract entity 49612. The BlockedIndicator 49627 is a“BusinessTransactionBlockedIndicator” 49629, and there is either zero orone 49628 BlockedIndicator 49627 for a PurchasingContract entity 49612.The Note 49630 is a “Note” 49632, and there is either zero or one 49631Note 49630 for a PurchasingContract entity 49612. The ValidityPeriod49633 is a “DateTimePeriod” 49635, and there is either zero or one 49634ValidityPeriod 49633 for a PurchasingContract entity 49612. TheTargetAmount 49636 is an “Amount” 49638, and there is either zero or one49637 TargetAmount 49636 for a PurchasingContract entity 49612.

The PurchasingContract package 49611 also includes a Party package49639. The Party package 49639 includes a BuyerParty entity 49640 at thethird level 49603. The BuyerParty entity 49640 is a“BusinessTransactionDocumentParty” 49642, and there is either zero orone 49641 BuyerParty entity 49640 for a Party package 49639.

The PurchasingContract entity 49612 includes an InternalID 49643, aStandardID 49646, an Address entity 49649 and a ContactPerson entity49652. The InternalID 49643 is a “PartyInternalID” 49645, and there iseither zero or one 49644 InternalID 49643 for a PurchasingContractentity 49612. The StandardID 49646 is a “PartyStandardID” 49648, andthere is from zero to any number 49647 StandardID 49646 for aPurchasingContract entity 49612. The Address entity 49649 is an“Address” 49651, and there is either zero or one 49650 Address entity49649 for a PurchasingContract entity 49612. The ContactPerson entity49652 is a “ContactPerson” 49654, and there is either zero or one 49653ContactPerson entity 49652 for a PurchasingContract entity 49612.

The ContactPerson entity 49652 includes an InternalID 49655 and anAddress entity 49658. The InternalID 49655 is a “ContactPersonID” 49657,and there is either zero or one 49656 InternalID 49655 for aContactPerson entity 49652. The Address entity 49658 is an “Address”49660, and there is either zero or one 49659 Address entity 49658 for aContactPerson entity 49652.

The Party package 49639 also includes a SellerParty entity 49661, aProductRecipientParty entity 49664 and aPurchasingContractReleaseAuthorizedParty entity 49667. The SellerPartyentity 49661 is a “BusinessTransactionDocumentParty” 49663, and there iseither zero or one 49662 SellerParty entity 49661 for a Party package49639. The ProductRecipientParty entity 49664 is a“BusinessTransactionDocumentParty” 49666, and there is either zero orone 49665 ProductRecipientParty entity 49664 for a Party package 49639.The PurchasingContractReleaseAuthorizedParty entity 49667 is a“BusinessTransactionDocumentParty” 49666, and there is from zero to anynumber 49668 PurchasingContractReleaseAuthorizedParty entity 49667 for aParty package 49639.

The PurchasingContract package 49611 also includes a Location package49670. The Location package 49670 includes a ShipToLocation entity 49671at the third level 49603. The ShipToLocation entity 49671 is a“BusinessTransactionDocumentLocation” 49673, and there is either zero orone 49672 ShipToLocation entity 49671 for a Location package 49670.

The PurchasingContract package 49611 also includes a DeliveryInformationpackage 49674. The DeliveryInformation package 49674 includes aDeliveryTerms entity 49675 at the third level 49603. The DeliveryTermsentity 49675 is a “DeliveryTerms” 49677, and there is either zero or one49676 DeliveryTerms entity 49675 for a DeliveryInformation package49674.

The DeliveryTerms entity 49675 includes an Incoterms entity 49678, aQuantityTolerance entity 49681, and a MaximumLeadTimeDuration 49684 atthe fourth level 49604. The Incoterms entity 49678 is an “Incoterms”49680, and there is either zero or one 49679 Incoterms entity 49678 fora DeliveryTerms entity 49675. The QuantityTolerance entity 49681 is a“QuantityTolerance” 49683, and there is either zero or one 49682QuantityTolerance entity 49681 for a DeliveryTerms entity 49675. TheMaximumLeadTimeDuration 49684 is a “Duration” 49686, and there is eitherzero or one 49685 MaximumLeadTimeDuration 49684 for a DeliveryTermsentity 49675.

The PurchasingContract package 49611 also includes a PaymentInformationpackage 49687. The PaymentInformation package 49687 includes aCashDiscountTerms entity 49688 at the third level 49603. TheCashDiscountTerms entity 49688 is a “CashDiscount-Terms” 49690, andthere is either zero or one 49689 CashDiscountTerms entity 49688 for aPaymentInformation package 49687.

The CashDiscountTerms entity 49688 includes a MaximumCashDiscount entity49691, a NormalCashDiscount entity 49694 and a FullPaymentDueDaysValue49697 at the fourth level 49604. The MaximumCashDiscount entity 49691 isa “CashDiscount” 49693, and there is either zero or one 49692MaximumCashDiscount entity 49691 for a CashDiscountTerms entity 49688.The NormalCashDiscount entity 49694 is a “CashDiscount” 49696, and thereis either zero or one 49695 NormalCashDiscount entity 49694 for aCashDiscountTerms entity 49688. There is either zero or one 49698FullPaymentDueDaysValue 49697 for a CashDiscountTerms entity 49688.

The PurchasingContract package 49611 also includes a PriceInformationpackage 49699. The PriceInformation package 49699 includes aPriceSpecificationElement entity 49600A at the third level 49603. ThePriceSpecificationElement entity 49600A is a “PriceSpecificationElement”49602A, and there is from zero to any number 49601APriceSpecificationElement entity 49600A for a PriceInformation package49699.

The PriceSpecificationElement entity 49600A includes a TypeCode 49603A,a ValidityPeriod entity 49606A, a PropertyValuation entity 49609A, aPrice 49612A, a Percent 49615A, a FixedAmount 49618A and aPriceSpecificationElementScaleLine entity 49621A at the fourth level49604. The TypeCode 49603A is a “PriceSpecificationElementTypeCode”49605A, and there is one 49604A TypeCode 49603A for aPriceSpecificationElement entity 49600A. The ValidityPeriod entity49606A is a “DateTimePeriod” 49608A, and there is one 49607AValidityPeriod entity 49606A for a PriceSpecificationElement entity49600A. The PropertyValuation entity 49609A is a“PriceSpecificationElementPropertyValuation” 49611A, and there is fromone to any number 49610A PropertyValuation entity 49609A for aPriceSpecificationElement entity 49600A. The Price 49612A is a “Price”49614A, and there is either zero or one 49613A Price 49612A for aPriceSpecificationElement entity 49600A. The Percent 49615A is a“Percent” 49617A, and there is either zero or one 49616A Percent 49615Afor a PriceSpecificationElement entity 49600A. The FixedAmount 49618A isan “Amount” 49620A, and there is either zero or one 49619A FixedAmount49618A for a PriceSpecificationElement entity 49600A. ThePriceSpecificationElementScaleLine entity 49621A is a“PriceSpecificationElementScaleLine” 49623A, and there is from zero toany number 49622A PriceSpecificationElementScaleLine entity 49621A for aPriceSpecificationElement entity 49600A.

The PurchasingContract package 49611 also includes an Attachment package49624A. The Attachment package 49624A includes an AttachmentWebAddressentity 49625A, an InternalAttachmentWebAddress entity 49628A and aLegalDocumentAttachment entity 49631 A at the third level 49603. TheAttachmentWebAddress entity 49625A is a “WebAddress” 49627A, and thereis from zero to any number 49626A AttachmentWebAddress entity 49625A foran Attachment package 49624A. The InternalAttachmentWebAddress entity49628A is a “WebAddress” 49630A, and there is from zero to any number49629A InternalAttachmentWebAddress entity 49628A for an Attachmentpackage 49624A. The LegalDocumentAttachment entity 4963 1A is an“Attachment” 49633A, and there is from zero to any number 49632ALegalDocumentAttachment entity 49631 A for an Attachment package 49624A.

The PurchasingContract package 49611 also includes a Description package49634A. The Description package 49634A includes an InternalDescriptionentity 49635A and a Description entity 49638A at the third level 49603.The InternalDescription entity 49635A is a “Description” 49637A, andthere is either zero or one 49636A InternalDescription entity 49635A fora Description package 49634A. The Description entity 49638A is a“Description” 49640A, and there is either zero or one 49639A Descriptionentity 49638A for a Description package 49634A.

The PurchasingContract package 49611 also includes an Item package49641A. The Item package 49641A includes an Item entity 49642A at thethird level 49603. The Item entity 49642A is a“PurchasingContractInformationItem” 49644A, and there is from zero toany number 49643A Item entity 49642A for an Item package 49641A.

The Item entity 49642A includes an ID 49645A, an ActiveIndicator 49648A,a TypeCode 49651A, a TargetQuantity 49654A, a TargetAmount 49657A, aMinimumOrderQuantity 49660A and a MinimumOrderAmount 49663A at thefourth level 49604. The ID 49645A is a“BusinessTransactionDocumentItemID” 49647A, and there is one 49646A ID49645A for an Item entity 49642A. The ActiveIndicator 49648A is an“ActiveIndicator” 49650A, and there is either zero or one 49649AActiveIndicator 49648A for an Item entity 49642A. The TypeCode 49651A isa “BusinessTransactionDocumentItemTypeCode” 49653A, and there is eitherzero or one 49652A TypeCode 49651A for an Item entity 49642A. TheTargetQuantity 49654A is a “Quantity” 49656A, and there is either zeroor one 49655A TargetQuantity 49654A for an Item entity 49642A. TheTargetAmount 49657A is an “Amount” 49659A, and there is either zero orone 49658A TargetAmount 49657A for an Item entity 49642A. TheMinimumOrderQuantity 49660A is a “Quantity” 49662A, and there is eitherzero or one 49661A MinimumOrderQuantity 49660A for an Item entity49642A. The MinimumOrderAmount 49663A is an “Amount” 49665A, and thereis either zero or one 49664A MinimumOrderAmount 49663A for an Itementity 49642A.

The Item entity 49642A also includes a ProductInformation package49666A. The ProductInformation package 49666A includes a Product entity49667A at the fourth level 49604. The Product entity 49667A is a“BusinessTransactionDocumentProduct” 49669A, and there is either zero orone 49668A Product entity 49667A for a ProductInformation package49666A.

The Product entity 49667A includes an InternalID 49670A, a StandardID49673A, a ManufacturerID 49676A, a SellerID 49679A, a TypeCode 49682Aand a Note 49685A at the fifth level 49605. The InternalID 49670A is a“ProdcutInternalID” 49672A, and there is either zero or one 49671AInternalID 49670A for a Product entity 49667A. The StandardID 49673A isa “ProductStandardID” 49675A, and there is from zero to any number49674A StandardID 49673A for a Product entity 49667A. The ManufacturerID49676A is a “ProductPartyID” 49678A, and there is either zero or one49677A ManufacturerID 49676A for a Product entity 49667A. The SellerID49679A is a “ProductPartyID” 49681A, and there is either zero or one49680A SellerID 49679A for a Product entity 49667A. The TypeCode 49682Ais a “ProductTypeCode” 49684A, and there is either zero or one 49683ATypeCode 49682A for a Product entity 49667A. The Note 49685A is a “Note”49687A, and there is either zero or one 49686A Note 49685A for a Productentity 49667A.

The ProductInformation package 49666A also includes a ProductCategoryentity 49688A at the fourth level 49604. The ProductCategory entity49688A is a “BusinessTransactionDocumentProductCategory” 49690A, andthere is either zero or one 49689A ProductCategory entity 49688A for aProductInformation package 49666A.

The ProductCategory entity 49688A includes an InternalID 49691A and aStandardID 49694A at the fifth level 49605. The InternalID 49691A is a“ProductCategoryInternalID” 49693A, and there is either zero or one49692A InternalID 49691A for a ProductCategory entity 49688A. TheStandardID 49694A is a “ProductCategoryStandardID” 49696A, and there isfrom zero to any number 49695A StandardID 49694A for a ProductCategoryentity 49688A.

The Item package 49641A also includes a PriceInformation entity 49697A.The PriceInformation entity 49697A includes a PriceSpecificationElemententity 49698A at the fourth level 49604. The PriceSpecificationElemententity 49698A is a “PriceSpecificationElement” 49600B, and there is fromzero to any number 49699A PriceSpecificationElement entity 49698A for aPriceInformation entity 49697A.

The Item package 49641A also includes Party package 49601B. The Partypackage 49601B includes a ProductRecipientParty entity 49602B at thefourth level 49604. The ProductRecipientParty entity 49602B is a“BusinessTransactionDocumentParty” 49604B, and there is from zero to anynumber 49603B ProductRecipientParty entity 49602B for a Party package49601B.

The Item package 49641A also includes a Location package 49605B. TheLocation package 49605B includes a ShipToLocation entity 49606B at thefourth level 49604. The ShipToLocation entity 49606B is a“BusinessTransactionDocumentShipToLocation” 49608B, and there is fromzero to any number 49607B ShipToLocation entity 49606B for a Locationpackage 49605B.

The Item package 49641A also includes a DeliveryInformation package49609B. The DeliveryInformation package 49609B includes a DeliveryTermsentity 49610B at the fourth level 49604. The DeliveryTerms entity 49610Bis a “DeliveryTerms” 49612B, and there is either zero or one 49611BDeliveryTerms entity 49610B for a DeliveryInformation package 49609B.

The Item package 49641A also includes a BusinessDocumentObjectReferencepackage 49613B. The BusinessDocumentObjectReference package 49613Bincludes a QuoteReference entity 49614B at the fourth level 49604. TheQuoteReference entity 49614B is a “BusinessTransactionDocumentReference”49616B, and there is either zero or one 49615B QuoteReference entity49614B for a BusinessDocumentObjectReference package 49613B.

The QuoteReference entity 49614B includes an ID 49617B and an ItemID49620B at the fifth level 49605. The ID 49617B is a“BusinessTransactionDocumentID” 49619B, and there is one 49618B ID49617B for a QuoteReference entity 49614B. The ItemID 49620B is a“BusinessTransactionDocumentItemID” 49622B, and there is from zero toany number 49621B ItemID 49620B for a QuoteReference entity 49614B.

The BusinessDocumentObjectReference package 49613B also includes anOperationalPurchasingContractReference entity 49623B at the fourth level49604. The OperationalPurchasingContractReference entity 49623B is a“BusinessTransactionDocumentReference” 49625B, and there is either zeroor one 49624B OperationalPurchasingContractReference entity 49623B for aBusinessDocumentObjectReference package 49613B.

The OperationalPurchasingContractReference entity 49623B includes an ID49626B and an ItemID 49629B at the fifth level 49605. The ID 49626B is a“BusinessTransactionDocumentID” 49628B, and there is one 49627B ID49626B for an OperationalPurchasingContractReference entity 49623B. TheItemID 49629B is a “BusinessTransactionDocumentItemID” 49631B, and thereis from zero to any number 49630B ItemID 49629B for anOperationalPurchasingContractReference entity 49623B. TheBusinessDocumentObjectReference package 49613B also includes aBuyerProductCatalogueReference entity 49632B at the fourth level 49604.The BuyerProductCatalogueReference entity 49632B is a“CatalogueReference” 49634B, and there is either zero or one 49633BBuyerProductCatalogueReference entity 49632B for aBusinessDocumentObjetReference package 49613B.

The BuyerProductCatalogueReference entity 49632B includes an ID 49635Band an ItemID 49638B at the fifth level 49605. The ID 49635B is a“BusinessTransaction-DocumentID” 49637B, and there is one 49636B ID49635B for an OperationalPurchasing-ContractReference entity 49623B. TheItemID 49638B is a “BusinessTransactionDocumentItemID” 49640B, and thereis from zero to any number 49639B ItemID 49638B for aBuyerProductCatalogueReference entity 49632B.

The Item package 49641A also includes an Attachment package 49641B. TheAttachment package 49641 B includes an AttachmentWebAddress 49642B andan InternalAttachmentWebAddress 49645B at the fourth level 49604. TheAttachmentWebAddress 49642B is a “WebAddress” 49644B, and there is fromzero to any number 49643B AttachmentWebAddress 49642B for an Attachmentpackage 49641B. The InternalAttachmentWebAddress 49645B is a“WebAddress” 49647B, and there is from zero to any number 49646BInternalAttachmentWebAddress 49645B for an Attachment package 49641B.

The Item package 49641A also includes a Description package 49648B. TheDescription package 49648B includes a Description 49649B and anInternalDescription 49652B. The Description 49649B is a “Description”49651B, and there is either zero or one 49650B Description 49649B for aDescription package 49648B. The InternalDescription 49652B is a“Description” 49654B, and there is either zero or one 49653BInternalDescription 49652B for a Description package 49648B.

nn) ReplenishmentOrderProposal Interfaces

In the “Forecasting and Replenishment” business scenario, theReplenishmentOrderProposalRequest andReplenishmentOrderProposalConfirmation messages are exchanged betweenthe back end system (ERP system) and the planning system. As part ofthis scenario, order proposals are created during the replenishmentprocess (replenishment planning), released automatically, andtransferred to the connected ERP system with theReplenishmentOrderProposalRequest message. Depending on the businessscenario, purchase orders or other follow-on documents are created therefrom these order proposals.

The aim of the replenishment run is to release 100% of the orderproposals that occur automatically and export them from the planningsystem.

If order proposals that are relevant for the planning system are createdin the ERP system (for example, manually), they are transferred with thePurchaseOrderInformation to the planning system. If order proposalscreated by the planning system are modified in the ERP system (forexample, purchasing system), these changes are also transferred to theplanning system with the ReplenishmentOrderProposalConfirmation.

(1) Message Types

(a) ReplenishmentOrderProposalRequest

A ReplenishmentOrderProposalRequest is a detailed proposal from arequester to a buyer to order products for replenishment purposes. TheReplenishmentOrderProposalRequest message type is based on the messagedata type ReplenishmentOrderProposalRequestMessage. Depending on thesource of supply, this is an order proposal with a vendor (externalprocurement), or a stock transport order proposal if the source ofsupply is a distribution center or another store (internal procurement).A purchase order may be created in the purchasing system on the basis ofthe order proposal, but it is still possible for changes to be made tothe order proposal in the purchasing system. It is, however, alsopossible that the purchasing system might reject the order proposal. Inboth cases, the purchasing system uses theReplenishmentOrderProposalConfirmation to inform the planning system.

(b) ReplenishmentOrderProposalConfirmation

A ReplenishmentOrderProposalConfirmation is a confirmation from a buyerto a requester that details the level to which the request can be met.The ReplenishmentOrderProposalConfirmation message type is based on themessage data type ReplenishmentOrderProposalConfirmationMessage. TheConfirmation is also used to inform the planning system about changes toexisting order proposals it contains. These are planning-relevantchanges for a replenishment order proposal.

(2) Message Choreography

FIG. 497 shows the interaction between the represented ReplenishmentOrder Proposal interfaces in a contract process is described in detail.

The following message choreography describes the possible logicalsequence of the messages that are necessary to realize the scenariobetween a Planning server 49700 and a Purchasing server 49702.

The Planning 49700 server can send a ReplenishmentOrderProposalRequestmessage 49704 to the Purchasing server 49702. In response, thePurchasing server 49702 can send aReplenishmentOrderProposalConfirmation message 49706 to the Planning49700.

The ReplenishmentOrderProposalRequest message 49704 is used to createthe order proposal in the purchasing system. If the order proposal iscreated or rejected, the planning system receives theReplenishmentOrderProposalConfirmation message 49706.

(3) Message Data Type ReplenishmentOrderProposalMessage

FIGS. 498A-C depict a data model of the message data typeReplenishmentOrderProposalMessage. The message data typeReplenishmentOrderProposalMessage groups together business informationrequired when a business document is sent in a message and theReplenishmentOrderProposal object contained in the business document.The template message data type ReplenishmentOrderProposalMessagerepresents the maximum structure for the message data typesReplenishmentOrderProposalRequestMessage,ReplenishmentOrderProposalConfirmationMessage, and the message types andinterfaces based on them.

The ReplenishmentOrderProposalRequestMessage and theReplenishmentOrderProposalConfirmationMessage are derived from theReplenishmentOrderProposalMessage as structural views.

Restrictions and differences between theReplenishmentOrderProposalRequestMessage orReplenishmentOrderProposalConfirmationMessage and theReplenishmentOrderProposalMessage are described below.

The ReplenishmentOrderProposalMessage package 49802 contains thepackages: MessageHeader package 49804 and the ReplenishmentOrderProposalpackage 49806. The ReplenishmentOrderProposalMessage package 49802 alsocontains a ReplenishmentOrderProposalMessage entity 49808.

(a) MessageHeader Package

See general data type (GDT) BusinessDocumentMessageHeader. TheMessageHeader package 49802 contains a MessageHeader entity 49810. Thereis a 1:1 relationship between the ReplenishmentOrderProposalMessageentity 49808 and the MessageHeader entity 49810. Where a relationship isidentified between entitites in FIGS. 498A-C for this Interface, therespective relationship is a 1:c relationship unless otherwise notedherein or indicated in FIG. 498. The following elements of the GDT areused: ID and CreationDateTime.

(b) ReplenishmentOrderProposal Package

The ReplenishmentOrderProposal package 49806 groups together theReplenishmentOrderProposal and its packages. TheReplenishmentOrderProposal package 49806 contains the followingpackages: Party package 49812, Location package 49814,BusinessObjectDocumentReference package 49816, and Item package 49818.The ReplenishmentOrderProposal package 49806 also contains aReplenishmentOrderProposal entity 49820. There is a 1:1 relationshipbetween the ReplenishmentOrderProposalMessage entity 49808 and theReplenishmentOrderProposal entity 49820.

The ReplenishmentOrderProposal entity 49820 is a proposal for a sourcelocation (for example, a vendor) to deliver certain quantities ofproducts to a target location (goods recipient, for example,distribution center) at a specific time, for replenishment purposes. TheReplenishmentOrderProposal entity 49820 usually consists of severalitems (order proposal items) that contain information about the sourceand target location, product and quantities, dates and referencedocuments. The ReplenishmentOrderProposal contains the followingelements: actionCode, completeTransmissionIndicator, ID,PurchasingGroupID, TransshipmentMethodCode, ConsignmentIndicator,QuantityRoundingAllowedIndicator, OrderPeriod, and DeliveryPeriod. The@actionCode is a coded display of actions that control how the recipientof the message creates, changes, and deletes the document and is of typeGDT ActionCode. The @completeTransmissionIndicator indicates that thecomplete order proposal is transferred and is of type GDTCompleteTransmissionIndicator. The ID is an identifier for theReplenishmentOrderProposal—order proposal number and is of type GDTBusinessTransactionDocumentID. The PurchasingGroupID is a Purchasinggroup and is of type GDT: PurchasingGroupID. The TransshipmentMethodCodeis a processing method that describes how the products are to be handledin the warehouse (for example, cross-docking, put away) and is of typeGDT: TransshipmentMethodCode. The ConsignmentIndicator indicates thatthe business form consignment is used and is of type GDT:ConsignmentIndicator. The QuantityRoundingAllowedIndicator indicatesthat quantities of the order proposal items may be rounded and is oftype GDT AllowedIndicator. If the quantities in the planning system havealready been rounded (for example, to logistics units of measure), thesemay not be rounded again when the follow-on document (for example,purchase order) is created in the purchasing system. The OrderPeriod isa period in which the products planned for replenishment must be orderedfrom the source of supply (for example, vendor or distribution center)and is of type GDT DateTimePeriod. The DeliveryPeriod is a period inwhich the products planned in the order proposal are available in thetarget location and is of type GDT DateTimePeriod. The followingelements are supported for the element @actionCode: Create (Code 01,attribute for initial data transfer), Change (Code 02), And Delete (Code03). The following attributes of the CompleteTransmissionIndicator aresupported. When an order proposal is created (@actionCode: Create′ (Code01)), the CompleteTransmissionIndicator has the attribute “true”,otherwise it is “false”. Therefore only order proposal changes aretransferred. An unchanged order proposal is not transferred. In someimplementations, the QuantityRoundingAllowedIndicator element is notused in the ReplenishmentOrderProposalConfirmationMessage.

(i) ReplenishmentOrderProposalParty Package

The Party package 49812 groups together parties that are involved inorder proposal processing. The Party package 49812 contains thefollowing entities: BuyerParty entity 49822, VendorParty entity, andProductRecipientParty entity.

The BuyerParty entity 49822 is the company, organization, group orperson that does the buying. The BuyerParty entity 49822 type is GDT:BusinessTransactionDocumentParty. At present, the internal ID is a formof identification supported. In some implementations, only the internalID may be transferred.

The VendorParty entity is the company or person that is to deliver theproducts to be ordered. The VendorParty entity type is GDT:BusinessTransactionDocumentParty, for which the InternalID and theStandardID are used.

The ProductRecipientParty entity is the company or person to whichproducts are delivered. The ProductRecipientParty entity type is GDT:BusinessTransactionDocumentParty, for which the InternalID and theStandardID are used.

(ii) ReplenishmentOrderProposalLocation Package

The Location package 49814 groups together locations of relevance forthe ReplenishmentOrderProposal messages. The Location package 49814contains the entities: ShipFromLocation entity 49824 and ShipToLocationentity 49826. There is a 1:1 relationship between theReplenishmentOrderProposal entity 49820 and both the ShipFromLocationentity 49824 and the ShipToLocation entity 49826. A default logicapplies from the header to the items for locations. Locations that arespecified in the header apply to items for which no correspondinglocation is transferred explicitly. This default logic is used tosimplify the message. From a logical perspective, locations in theheader behave as if they were being transferred explicitly for the itemsin a message.

The ShipFromLocation entity 49824 (source of supply) is the locationthat is to supply the product to be ordered. The ShipFromLocation entity49824 type is GDT BusinessTransactionDocumentShipFromLocation. TheInternalID and the StandardID are supported as identification. In someimplementations, the source of supply must always be specified.

The ShipToLocation entity 49826 (target location) is the location towhich the product to be ordered is to be delivered. The ShipToLocationentity 49826 type is GDT BusinessTransactionDocumentShipToLocation. TheInternalID and the StandardID are supported as identification.

(iii) ReplenishmentOrderProposalBusinessDocumentObjectReference Package

The BusinessDocumentObjectReference package 49816 groups references tobusiness documents that are related to the ReplenishmentOrderProposal inbusiness terms. The BusinessDocumentObjectReference package 49816contains a PurchaseOrderReference entity 49828.

The PurchaseOrderReference entity 49828 is the reference to a purchaseorder in the purchasing system (ERP system) that was created on thebasis of the order proposal. The PurchaseOrderReference entity 49828type is GDT BusinessTransactionDocumentReference, for which only the IDelement is used. The ID is an identifier for the purchaseorder—follow-on document that was created in the ERP system (purchasingsystem) from the order proposal and is of type GDTBusinessTransactionDocumentID.

The order proposals created in the planning system are transferred tothe purchasing system with the ReplenishmentOrderProposalRequestMessage.It is possible that different order proposals (or purchase orders) withdifferent (order proposal or purchase order) numbers are created fromthis order proposal in the purchasing system. These reference numbers(header and item level) are transferred to the planning system in theReplenishmentOrderProposalConfirmationMessage.

This information is required in the planning system to show thereplenishment planner which purchase order item in the ERP system(purchasing system) is behind the order proposal item.

In some implementations, the package is not filled in theReplenishmentOrderProposalRequestMessage. Only the ID is transferred.

(iv) ReplenishmentOrderProposalItem Package

The ReplenishmentOrderProposalItem package 49818 groups theReplenishmentOrderProposalItem with its packages. TheReplenishmentOrderProposalItem package 49818 contains the followingpackages: ProductInformation package 49830, PriceInformation package49832, Party package 49834, Location package 49836,BusinessDocumentObjectReference package 49838, and ScheduleLine package49840. The ReplenishmentOrderProposalItem package 49818 also contains aReplenishmentOrderProposalItem entity 49841.

The ReplenishmentOrderProposalItem entity 49841 groups information, thetype, quantity and dates for the products proposed for the replenishmentpurchase order. The ReplenishmentOrderProposalItem entity 49841 containsdetailed information about a product (see ProductInformation Package)and its price (see PriceInformation Package), source of supply andtarget location (see Location Package), and details about the quantityof a product and the (delivery) dates (see ScheduleLine Package). TheReplenishmentOrderProposalItem entity 49841 can contain references toother business documents of relevance for the item (seeBusinessDocumentObjectReference Package). TheReplenishmentOrderProposalItem entity 49841 contains the elements:actionCode, completeTransmissionIndicator, ID, PurchasingGroupID,TransshipmentMethodCode, ConsignmentIndicator, ReturnsIndicator,PlanningRelevanceIndicator, CompletedIndicator, ReceivedQuantity, andOrderPeriod. The @actionCode is a coded display of actions that controlhow the item is created, changed, and deleted by the recipient of themessage and is of type GDT ActionCode. The ActionCode for the item andthe ReplenishmentOrderProposals can be different. For example, it ispossible that several items of a purchase order are to be changed anddeleted. In this case, the ActionCode displays a change atReplenishmentOrderProposal level, and the ActionCode at item leveldisplays the action to be performed for the item in question. The@completeTransmissionIndicator indicates that the complete orderproposal item is transferred and is of type GDTCompleteTransmissionIndicator. The ID is an identifier for the item ofan order proposal and is of type GDT BusinessTransactionDocumentItemID.The PurchasingGroupID is a purchasing group and is of type GDT:PurchasingGroupID. The TransshipmentMethodCode is a processing methodthat describes how goods are to be distributed (for example,cross-docking, putaway) and is of type GDT TransshipmentMethodCode. TheConsignmentIndicator indicates that the business form consignment isused and is of type GDT: ConsignmentIndicator. The ReturnsIndicatorindicates that the order proposal item is a return and is of type GDTReturnsIndicator. As part of replenishment planning for distributioncenters, goods receipts can be posted by both vendors and the suppliedstores. This is a case of store returns to the distribution center. ThePlanningRelevanceIndicator displays whether or not the item is takeninto account in the planning run and is of type GDTPlanningRelevanceIndicator. The CompletedIndicator indicates that theitem is complete. As such, no more partial deliveries are expected forthis order item. The CompletedIndicator is of type GDTBusinessTransactionCompletedIndicator. The ReceivedQuantity is acumulated goods receipt quantity that is updated in the purchasingsystem and is of type GDT Quantity. The OrderPeriod is a period in whichthe products planned for replenishment must be ordered from the sourceof supply (for example, vendor, distribution center) and is of type GDTDateTimePeriod.Integrity

In some implementations, the BusinessDocumentObjectReference package isonly used for the ReplenishmentOrderProposalConfirmationMessage. It isnot used for the ReplenishmentOrderProposalRequestMessage. The followingattributes of the @actionCode element are supported: Create (Code 01),Change (Code 02), And Delete (Code 03). When aReplenishmentOrderProposalItem (@actionCode, Create′ (Code 01)) iscreated, the CompleteTransmissionIndicator has the attribute “true”. Thefollowing elements are not filled for theReplenishmentOrderProposalRequestMessage: ReturnsIndicator,PlanningRelevanceIndicator, CompletedIndicator, and ReceivedQuantity.The ReceivedQuantity element can only be filled in the case of aReplenishmentOrderProposalConfirmationMessage with @actionCode Change(Code 02).

(a) ReplenishmentOrderProposalItemProductInformation Package

The ProductInformation package 49830 groups together information used toidentify, describe, and classify a product. The ProductInformationpackage 49830 contains the entities: Product entity 49842,ProductCategory entity 49844, and VendorProductCategory entity 49844.

The Product entity 49842 is the identification used for the product tobe ordered. The Product entity 49842 type is GDTBusinessTransactionDocumentProduct. There is a 1:1 relationship betweenthe Item entity 49841 and the Product entity 49842. The InternalID andthe StandardID are supported as identification.

The ProductCategory entity 49844 specifies the category of the productto be ordered from the retailer's perspective. The ProductCategoryentity 49844 type is GDT BusinessTransactionDocumentProductCategory. Insome implementations, the only identification supported is theInternalID. This means that only the InternalID may be transferred. Thisfield is optional, as this information is company-specific and is notalways defined.

The VendorProductCategory entity 49846 is a company-specific orvendor-specific schedule line for a vendor's entire range of products(vendor subrange). The VendorProductCategory entity 49846 provides thevendor view. The VendorProductCategory entity 49846 type is GDTBusinessTransactionDocumentProductCategory. In some implementations, theonly identification supported is the InternalID. This means that onlythe InternalID can be transferred. The InternalID is optional, as thisinformation is company-specific. For example, frozen goods offered by avendor can be defined as a vendor subrange.

(b) ReplenishmentOrderProposalParty Package

The Party package 49834 groups together information relating to businesspartners involved in a replenishment process. The Party package 49834contains the entities: BuyerParty entity 49850, VendorParty entity, andProductRecipientParty entity.

The BuyerParty entity 49850 groups together information relating to thecompany, organization, group or person doing the buying. The BuyerPartyentity 49850 contains detailed information about the purchasing partyand contains the InternalID element. The InternalID is a purchasingorganization and is of type GDT:BusinessTranscationDocumentPartyInternalID. In some implementations, theonly identification supported is the InternalID. This means that onlythe InternalID may be transferred.

The VendorParty is the company or person that is to deliver the productsto be ordered. The VendorParty type is GDT:BusinessTransactionDocumentParty, for which the InternalID and theStandardID are used.

The ProductRecipientParty is the company or person to which products aredelivered. The ProductRecipientParty type is GDT:BusinessTransactionDocumentParty, for which the InternalID and theStandardID are used.

(c) ReplenishmentOrderProposalItemPriceInformation Package

The PriceInformation package 49832 groups together the relevant priceinformation. The PriceInformation package 49832 contains aNetPurchasePrice entity 49848.

The price refers to the net purchase price specified by the requester orthe buyer (relating to the quantity ordered) for the product or service.This price forms the basis for order optimizing in the planning system.The NetPurchasePrice entity 49848 type is GDT: Price. TheNetPurchasePrice entity 49848 is optional and is only filled in theReplenishmentOrderProposalRequestMessage.

(d) ReplenishmentOrderProposalItemLocation Package

The Location package 49836 groups together locations of relevance forthe ReplenishmentOrderProposalMessage. The Location package 49836contains the following entities: ShipFromLocation entity 49852 andShipToLocation entity 49854. The data transfer of locations from headerto item level is supported. This means that the item contains only thelocations that differ from the header.

The ShipFromLocation entity 49852 (source of supply) is the locationfrom which the product to be ordered is to be delivered. TheShipFromLocation entity 49852 type is GDTBusinessTransactionDocumentShipFromLocation. The InternalID and theStandardID are supported as identification.

The ShipToLocation entity 49854 (target location) is the location towhich the product to be ordered is to be delivered. The ShipToLocationentity 49854 type is GDT BusinessTransactionDocumentShipToLocation. TheInternalID and the StandardID are supported as identification.

(e) ReplenishmentOrderProposalItemBusinessDocumentObjectReferencePackage

The BusinessTransactionDocumentReference package 49838 groups togetherreferences to business documents that are related to theReplenishmentOrderProposalItem in business terms. TheBusinessTransactionDocumentReference package 49838 contains aPurchaseOrderReference entity 49856.

The PurchaseOrderReference entity 49856 is a reference to a purchaseorder in the purchasing system (ERP system) that was created as a resultof the order proposal. The PurchaseOrderReference entity 49856 containsthe elements: ID and ItemID. The ID is an identifier for the referencedocument in the purchasing system (ERP system). For example, this can bea purchase order, an order proposal or a stock transport order. This isdependent on the sending system. The ItemID is an identifier for thereference document item in the purchasing system (ERP system) and is oftype GDT BusinessTransactionDocumentItemID. This information is neededin the planning system to enable the replenishment planner to see whichdocument number and which order item is behind the order proposal itemin the purchasing system (ERP system). In some implementations, an itemonly ever refers to one item in the ERP system. The package is notfilled in the ReplenishmentOrderProposalRequestMessage. If severalfollow-on documents are created in the purchasing system (ERP) from anorder proposal, the references at header and item level can bedifferent.

A purchase order is created in the purchasing system (ERP) from theorder proposal created in the planning system (SCP). Usually this ordernumber differs from the number of the order proposal.

If a planning-relevant change is made to this purchase order in ERP (forexample, a date change to an order item), this information must betransferred to the SCP with theReplenishmentOrderProposalConfirmationMessage. The original orderproposal number and the number of the item must be forwarded to the SCPso the SCP knows which order proposal this message refers to. With thesereferences, the relevant changes can be made to the order proposal inthe SCP.

If a partial delivery is made to the ERP system, this information mustbe forwarded to the planning system. In this case, theBusinessTransactionDocumentReference Package must be filled with theorder proposal number and the corresponding reference item number.

If the ERP system works with schedule lines, the corresponding scheduleline numbers can also be transferred (optional). The order proposals inthe planning system (SCP) consist of header and item data. The planningsystem does not work with schedule lines.

(f) ReplenishmentOrderProposalItemScheduleLine Package

A ScheduleLine package 49840 groups together the quantity and dateinformation for a ReplenishmentOrderProposalItem. The ScheduleLinepackage 49840 contains the entities: ScheduleLine entity 49858 andConfirmedScheduleLine 49860.

The ScheduleLine entity 49858 is a schedule line with quantities anddates for the schedule created by the planning system for areplenishment delivery of products. The ScheduleLine entity 49858contains the elements: DeliveryPeriod and Quantity. The DeliveryPeriodis a period in which the requested products are available in the targetlocation and is of type GDT DateTimePeriod. The Quantity is a productquantity of a replenishment order proposal that can be converted to thebase unit of measure and is of type GDT Quantity. The ScheduleLinePackage is not filled in theReplenishmentOrderProposalConfirmationMessage.

The ConfirmedScheduleLine entity 49860 is a schedule line withquantities and dates for the schedule confirmed by a purchasing systemfor a replenishment delivery of products. The ConfirmedScheduleLineentity 49860 contains the elements:PurchaseOrderItemScheduleLineReferenceID, DeliveryPeriod, and Quantity.The PurchaseOrderItemScheduleLineReferenceID is an identifier for theschedule line number for the order item in the purchasing system and isof type GDT BusinessTransactionDocumentItemScheduleLineID. TheDeliveryPeriod is a period in which the requested products are availablein the target location and is of type GDT DateTimePeriod. The Quantityis a product quantity that can be converted to the base unit of measureand is of type GDT Quantity. The ConfirmedScheduleLine Package is notfilled in the ReplenishmentOrderProposalRequestMessage.

(4) Message Data Type Element Structure

(a) ReplenishmentOrderProposalRequest

The message data type element structure for theReplenishmentOrderProposalRequest message is depicted in FIG. 499A-I.The element structure is similar to the data model, but providesadditional information regarding the details of the interface. Theelement structure identifies the different packages 49900 in theinterface, and represents the entities at various levels within theinterface. As depicted in FIG. 499A, the interface forReplenishmentOrderProposalRequest Message includes five levels 49901,49902, 49903, 49904, and 49905.

The outermost package of this interface is aReplenishmentOrderProposalRequestMessage package 49910, which includes aReplenishmentOrderProposal Message entity 49911 at the first level49901. The ReplenishmentOrderProposal Message entity 49911 is of a datatype MDT 49917 “ReplenishmentOrderProposalMessage” 49918. TheReplenishmentOrderProposalRequestMessage package 49910 includes aMessageHeader package 49920 and a ReplenishmentOrderProposal package49950.

The MessageHeader package 49920 includes a MessageHeader entity 49922 atthe second level. There is one 49926 MessageHeader entity 49922 for eachReplenishmentOrderProposalRequest Message entity 49911, and theMessageHeader entity 49922 is of type GDT 49927 Business DocumentMessage Header 49928. The MessageHeader entity 49922 includes an ID49933 and a CreationDate Time 49943. There is one 49936 ID 49933 foreach MessageHeader entity 49922, and the ID 49933 is of type GDT 49937Business Document MessageID 49938. There is one 499×6 CreationDate Time49943 for each MessageHeader entity 49922, and the CreationDate Time49943 is of type GDT 49947 DateTime 49948.

The ReplenishmentOrderProposal package 49950 includes aReplenishmentOrderProposal entity 49952. There is one 49956ReplenishmentOrderProposal entity 49952 for eachReplenishmentOrderProposal package 49950. The Replenishment OrderProposal 49952 is of type ReplenishmentOrder Proposal 49958. TheReplenishmentOrderProposal entity 49952 includes elements: @actionCode49963, @complete Transmission Indicator 49973, ID 49983, PurchasingGroupID 49993, TransshipmentMethodCode 49903A, Consignment Indicator49913A, Quantity Rounding Allowed Indicator 49923A, OrderPeriod 49933A,and Delivery Period 49943A.

There is one 49966 @actionCode 49963 for each Replenishment OrderProposal 49952. The @actionCode 49963 is of type GDT 49967 ActionCode49968.

There is one 49976 @complete Transmission Indicator 49973 for eachReplenishment Order Proposal 49952. The @complete Transmission Indicator49973 is of type GDT 49977 Complete Transmission Indicator 49978.

There is one 49986 ID 49983 for each Replenishment Order Proposal 49952.The ID 49983 is of type GDT 49987 Business Transaction DocumentID 49988.

There is zero or one 49996 Purchasing GroupID 49993 for eachReplenishment Order Proposal 49952. The Purchasing GroupID 49993 is oftype GDT 49997 Purchasing GroupID 49998.

There is zero or one 49906A TransshipmentMethodCode 49903A for eachReplenishment Order Proposal 49952. The TransshipmentMethodCode 49903Ais of type GDT 49907A TransshipmentMethodCode 49908A.

There is zero or one 49916A Consignment Indicator 49913A for eachReplenishment Order Proposal 49952. The Consignment Indicator 49913A isof type GDT 49917A Consignment Indicator 49918A.

There is zero or one 49926A Quantity Rounding Allowed Indicator 49923Afor each Replenishment Order Proposal 49952. The Quantity RoundingAllowed Indicator 49923A is of type GDT 49927A Allowed Indicator 49928A.

There is zero or one 49936A OrderPeriod 49933A for each ReplenishmentOrder Proposal 49952. The OrderPeriod 49933A is of type GDT 49937ADateTime Period 49938A.

There is zero or one 49946A Delivery Period 49943A for eachReplenishment Order Proposal 49952. The Delivery Period 49943A is oftype GDT 49947A DateTime Period 49948A.

The ReplenishmentOrderProposal package 49950 includes packages: Partypackage 49950A, Location package 49930B, BusinessDocumentObjectReferencepackage 49990B, and Item package 49910C. The Party package 49950Aincludes entities: BuyerParty 49953A, VendorParty 49973A, and ProductRecipient 49903B.

There is zero or one 49956A BuyerParty 49953A for each Party 49950A. TheBuyerParty 49953A includes an InternalID 49964A element.

There is zero or one 49966A InternalID 49964A for each BuyerParty49953A. The InternalID 49964A is of type GDT 49967A Business TransactionDocument Party InternalID 49968A.

There is zero or one 49976A VendorParty 49973A for each Party 49950A.The VendorParty 49973A includes elements: InternalID 49984A andStandardID 49994A.

There is zero or one 49986A InternalID 49984A for each VendorParty49973A. The InternalID 49984A is of type GDT 49987A Business TransactionDocument Party InternalID 49988A.

There is zero or one 49996A StandardID 49994A for each VendorParty49973A. The StandardID 49994A is of type GDT 49997A Business TransactionDocument Party StandardID 49998A.

There is zero or one 49906B Product Recipient 49903B for each Party49950A. The VendorParty 49973A includes elements: InternalID 49914B andStandardID 49924B.

There is zero or one 49916B InternalID 49914B for each Product Recipient49903B. The InternalID 49914B is of type GDT 49917B Business TransactionDocument Party InternalID 49918B.

There is zero or one 49926B StandardID 49924B for each Product Recipient49903B. The StandardID 49924B is of type GDT 49927B Business TransactionDocument Party StandardID 49928B.

The Location package 49930B includes entities: ShipFrom Location 49933Band ShipTo Location 49963B.

There is one 49936B ShipFrom Location 49933B for each Location 49930B.The ShipFrom Location 49933B is of type GDT 49937B Business TransactionDocument ShipFrom Location 49938B. The ShipFrom Location 49933B includeselements: InternalID 49944B and StandardID 49954B.

There is zero or one 49946B InternalID 49944B for each ShipFrom Location49933B. The InternalID 49944B is of type GDT 49947B Location InternalID49948B.

There is zero or one 49956B StandardID 49954B for each ShipFrom Location49933B. The StandardID 49954B is of type GDT 49957B Location StandardID49958B.

There is one 49966B ShipTo Location 49963B for each Location 49930B. TheShipTo Location 49963B is of type GDT 49967B Business TransactionDocument ShipTo Location 49968B. The ShipTo Location 49963B includeselements: InternalID 49974B and StandardID 49984B.

There is zero or one 49976B InternalID 49974B for each ShipTo Location49963B. The InternalID 49974B is of type GDT 49977B Location InternalID49978B.

There is zero or one 49986B StandardID 49984B for each ShipTo Location49963B. The StandardID 49984B is of type GDT 49987B Location StandardID49988B.

The Business Document Object Reference package 49990B includes aPurchase Order Reference entity 49993B.

There is zero or one 49996B Purchase Order Reference 49993B for eachBusiness Document Object Reference 49990B. The Purchase Order Reference49993B is of type GDT 49997B Business Transaction Document Reference49998B. The Purchase Order Reference 49993B includes an ID 49904Celement.

There is one 49906C ID 49904C for each Purchase Order Reference 49993B.The ID 49904C is of type GDT 49907C Business Transaction Document ItemID49908C.

The Item package 49910C includes an Item entity 49913C and packages:ProductInformation 49990C, PriceInformation 49960D, Party 49970D,Location 49950E, and ScheduleLine 49910F.

There may be any number 49916C of Item 49913C for each Item 49910C. TheItem 49913C is of type ReplenishmentOrder ProposalItem 49918C. The Item49913C includes elements: @actionCode 49924C, @completeTransmissionIndicator 49934C, ID 49944C, Purchasing GroupID 49954C,TransshipmentMethodCode 49964C, ConsignmentIndicator 49974C, andOrderPeriod 49984C.

There is one 49926C @actionCode 49924C for each Item 49913C. The@actionCode 49924C is of type GDT 49927C ActionCode 49928C.

There is one 49936C @complete TransmissionIndicator 49934C for each Item49913C. The @complete TransmissionIndicator 49934C is of type GDT 49937CComplete Transmission Indicator 49938C.

There is one 49946C ID 49944C for each Item 49913C. The ID 49944C is oftype GDT 49947C Business Transaction Document ItemID 49948C.

There is zero or one 49956C Purchasing GroupID 49954C for each Item49913C. The Purchasing GroupID 49954C is of type GDT 49957C PurchasingGroupID 49958C.

There is zero or one 49966C TransshipmentMethodCode 49964C for each Item49913C. The TransshipmentMethodCode 49964C is of type GDT 49967CTransshipment MethodCode 49968C.

There is zero or one 49976C ConsignmentIndicator 49974C for each Item49913C. The ConsignmentIndicator 49974C is of type GDT 49977CConsignment Indicator 49978C.

There is zero or one 49986C OrderPeriod 49984C for each Item 49913C. TheOrderPeriod 49984C is of type GDT 49987C DateTime Period 49988C.

The Product Information package 49990C includes packages: Product49994C, Product Category 49924D, and Vendor Product Category 49944D.

There is one 49996C Product 49994C for each Product Information 49990C.The Product 49994C is of type GDT 49997C Business Transaction DocumentProduct 49998C. The Product 49994C includes elements: Internal ID 49905Dand StandardID 49915D.

There is one 49906D Internal ID 49905D for each Product 49994C. TheInternal ID 49905D is of type GDT 49907D Product InternalID 49908D.

There is one 49916D StandardID 49915D for each Product 49994C. TheStandardID 49915D is of type GDT 49917D Product StandardID 49918D.

There is zero or one 49926D Product Category 49924D for each ProductInformation 49990C. The Product Category 49924D is of type GDT 49927DBusiness Transaction Document Product Category 49928D. The ProductCategory 49924D includes an element Internal ID 49935D.

There is one 49936D Internal ID 49935D for each Product Category 49924D.The Internal ID 49935D is of type GDT 49937D Product Category InternalID49938D.

There is zero or one 49946D Vendor Product Category 49944D for eachProduct Information 49990C. The Vendor Product Category 49944D is oftype GDT 49947D Business Transaction Document Product Category 49948D.The Vendor Product Category 49944D includes an element Internal ID49955D.

There is one 49956D Internal ID 49955D for each Vendor Product Category49944D. The Internal ID 49955D is of type GDT 49957D Product CategoryInternalID 49958D.

The Price Information 49960D includes an entity NetPurchasePrice 49964D.

There is zero or one 49966D NetPurchasePrice 49964D for each PriceInformation 49960D. The NetPurchasePrice 49964D is of type GDT 49967DPrice 49968D.

The Party package 49970D includes entities: BuyerParty 49974D,VendorParty 49994D, and Product Recipient Party 49924E.

There is zero or one 49976D BuyerParty 49974D for each Party 49970D. TheBuyerParty 49974D includes an element Internal ID 49985D.

There is zero or one 49986D Internal ID 49985D for each BuyerParty49974D. The Internal ID 49985D is of type GDT 49987D BusinessTransaction Document Party InternalID 49988D.

There is zero or one 49996D VendorParty 49994D for each Party 49970D.The VendorParty 49994D includes elements: Internal ID 49905E andStandard ID 4991 SE.

There is zero or one 49906E Internal ID 49905E for each VendorParty49994D. The Internal ID 49905E is of type GDT 49907E BusinessTransaction Document Party InternalID 49908E.

There is zero or one 49916E Standard ID 49915E for each VendorParty49994D. The Standard ID 4991 SE is of type GDT 49917E BusinessTransaction Document Party StandardID 49918E.

There is zero or one 49926E Product Recipient Party 49924E for eachParty 49970D. The Product Recipient Party 49924E includes elements:Internal ID 49935E and Standard ID 49945E.

There is zero or one 49936E Internal ID 49935E for each ProductRecipient Party 49924E. The Internal ID 49935E is of type GDT 49937EBusiness Transaction Document Party InternalID 49938E.

There is zero or one 49946E StandardID 49945E for each Product RecipientParty 49924E. The StandardID 49945E is of type GDT 49947E BusinessTransaction Document Party StandardID 49948E.

The Location package 49950E includes entities: ShipFrom Location 49954Eand ShipTo Location 49984E.

There is zero or one 49956E ShipFrom Location 49954E for each Location49950E. The ShipFrom Location 49954E is of type GDT 49957E BusinessTransaction Document ShipFrom Location 49958E. The ShipFrom Location49954E includes elements: Internal ID 49965E and Standard ID 49975E.

There is zero or one 49966E Internal ID 49965E for each ShipFromLocation 49954E. The Internal ID 49965E is of type GDT 49967E LocationInternalID 49968E.

There is zero or one 49976E StandardID 49975E for each ShipFrom Location49954E. The StandardID 49975E is of type GDT 49977E Location StandardID49978E.

There is zero or one 49986E ShipTo Location 49984E for each Location49950E. The ShipTo Location 49984E is of type GDT 49987EBusinessTransactionDocumentShipToLocation 49988E. The ShipTo Location49984E includes elements: Internal ID 49995E and Standard ID 49905F.

There is zero or one 49996E Internal ID 49995E for each ShipTo Location49984E. The Internal ID 49995E is of type GDT 49997E Location InternalID49998E.

There is zero or one 49906F StandardID 49905F for each ShipTo Location49984E. The StandardID 49905F is of type GDT 49907F Location StandardID49908F.

The Schedule Line package 49910F includes an entity ScheduleLine 49914F.

There is one 49916F ScheduleLine 49914F for each Schedule Line 49910F.The ScheduleLine 49914F includes elements: Delivery Period 49925F andQuantity 49935F.

There is one 49926F Delivery Period 49925F for each ScheduleLine 49914F.The Delivery Period 49925F is of type GDT 49927F DateTime Period 49928F.

There is one 49936F Quantity 49935F for each ScheduleLine 49914F. TheQuantity 49935F is of type GDT 49937F Quantity 49938F.

(b) Replenishment Order Proposal Confirmation Message

The message data type element structure for Replenishment Order ProposalConfirmation Message is depicted in FIG. 499AA-L. The element structureis similar to the data model, but provides additional informationregarding the details of the interface. The element structure identifiesthe different packages 499A00 in the interface, and represents theentities at various levels within the interface. As depicted in FIG.499AA, the interface for Replenishment Order Proposal ConfirmationMessage includes five levels 499A02, 499A04, 499A06, 499A08, and 499A10.The outermost package of this interface is aReplenishmentOrderProposalConfirmationMessage 499A16, which includes aReplenishmentOrderProposalMessage 499A18 at the first level 499A02. TheReplenishmentOrderProposalMessage 499A18 is of a data type MDT 499A20and the name is ReplenishmentOrderProposalMessage 499A22.

The ReplenishmentOrderProposalConfirmationMessage 499A16 includes aMessageHeader 499A24. The MessageHeader 499A24 includes a MessageHeaderentity 499A26 with a cardinality of one 499A28, the type is GDT 499A30and the name is BusinessDocumentMessageHeader 499A32. The MessageHeaderentity 499A26 includes an ID 499A34 and a CreationDateTime 499A42. TheID 499A34 has a cardinality of one 499A36, the type is GDT 499A38 andthe name is BusinessDocumentMessageID 499A40. The CreationDateTime499A42 has a cardinality of one 499A44, the type is GDT 499A46 and thename is DateTime 499A48.

As depicted in FIG. 499AB, a ReplenishmentOrderProposal package 499A50includes a ReplenishmentOrderProposal entity 499A52. TheReplenishmentOrderProposal entity 499A52 includes an @actionCode 499A60,an @completeTransmissionIndicator 499A68, an ID 499A76, aPurchasingGroupID 499A84, a TransshipmentMethodCode 499A92, and aConsignmentIndicator 499A00A. The @actionCode 499A60 has a cardinalityof one 499A62, the type is GDT 499A64 and the name is ActionCode 499A66.The @completeTransmissionIndicator 499A68 has a cardinality of one499A70, the type is GDT 499A72 and the name isCompleteTransmissionIndicator 499A74. The ID 499A76 has a cardinality ofone 499A78, the type is GDT 499A80 and the name isBusinessTransactionDocumentID 499A82. The PurchasingGroupID 499A84 has acardinality of zero or one 499A86, the type is GDT 499A88 and the nameis PurchasingGroupID 499A90. The TransshipmentMethodCode 499A92 has acardinality of zero or one 499A94, the type is GDT 499A96 and the nameis TransshipmentMethodCode 499A98. The ConsignmentIndicator 499A00A hasa cardinality of zero or one 499A02A, the type is GDT 499A04A and thename is ConsignmentIndicator 499A06A.

As depicted in FIG. 499AC, the ReplenishmentOrderProposal 499A52 alsoincludes an OrderPeriod 499A08A with a cardinality of zero or one499A10A, the type is GDT 499A12A and the name is DateTimePeriod 499A14A.The ReplenishmentOrderProposal 499A52 also includes a DeliveryPeriod499A16A with a cardinality of zero or one 499A18A, the type is GDT499A20A and the name is DateTimePeriod 499A22A.

A Party package 499A24A includes a BuyerParty entity 499A26A with acardinality of zero or one 499A28A. The BuyerParty entity 499A26Aincludes an InternalID 499A30A with a cardinality of zero or one499A32A, the type is GDT 499A34A, and the name isBusinessTransactionDocumentPartyInternalID 499A36A. A VendorParty499A38A has a cardinality of zero or one 499A40A and includes anInternalID 499A42A and a StandardID 499A50A. The InternalID 499A42A hasa cardinality of zero or one 499A44A, the type is GDT 499A46A and thename is BusinessTransactionDocumentPartyInternalID 499A48A. TheStandardID 499A50A has a cardinality of zero or one 499A52A, the type isGDT 499A54A, and the name is BusinessTransactionDocumentPartyStandardID499A56A.

As depicted in FIG. 499AD, a Party package includes aProductRecipientParty entity 499A58A with a cardinality of zero or one499A60A. The ProductRecipientParty entity 499A58A includes an InternalID499A62A with a cardinality of zero or one 499A64A, the type is GDT499A66A, and the name is BusinessTransactionDocumentPartyInternalID499A68A. A StandardID 499A70A is also included with a cardinality ofzero or one 499A72A, a type of GDT 499A74A and the nameBusinessTransactionDocumentPartyStandardID 499A76A.

A Location package 499A78A includes a ShipFromLocation entity 499A80Awith a cardinality of one 499A82A, the type is GDT 499A84A, and the nameis BusinessTransactionDocumentShipFromLocation 499A86A. An InternalIDentity 499A88A has a cardinality of zero or one 499A90A, the type is GDT499A92A and the name is LocationInternalID 499A94A. A StandardID entity499A96A is also included with a cardinality of zero or one 499A98A, thetype is GDT 499A00B and the name is LocationStandardID 499A02B.

As depicted in FIG. 499AE, a ShipToLocation package 499A04B has acardinality of one 499A06B, the type is GDT 499A08B and the name isBusinessTransactionDocumentIShipToLocation 499A10B. An InternalID entity499A12B is included with a cardinality of zero or one 499A14B, the typeis GDT 499A161B, and the name is LocationInternalID 499A18B. AStandardID entity 499A20B is included with a cardinality of zero or one499A22B, the type is GDT 499A24B, and the name is LocationStandardID499A26B.

A BusinessDocumentObjectReference package 499A28B includes aPurchaseOrderReference 499A30B with a cardinality of zero or one499A32B, the type is GDT 499A34B, and the name isBusinessTransactionDocumentReference 499A36B. The PurchaseOrderReference499A30B includes an ID entity 499A38B with a cardinality of one 499A40B,the type is GDT 499A42B, and the name isBusinessTransactionDocumentItemID 499A44B.

A ReplenishmentOrderProposal package 499A50 includes an Item package499A46B. The Item package 499A46B includes an Item entity 499A48B withany number 499A50B of item entities 499A48B for an Item package 499A46B.The name is ReplenishmentOrderProposalItem 499A52B. The Item entity499A48B includes an @actionCode 499A54B, an@completeTransmissionIndicator 499A62B, an ID 499A70B, aPurchasingGroupID 499A78B, a TransshipmentMethodCode 499A86B, aConsignmentIndicator 499A94B, and a ReturnsIndicator 499A02C. The@actionCode 499A54B has a cardinality of one 499A56B, the type is GDT499A58B, and the name is ActionCode 499A60B. The@completeTransmissionIndicator 499A62B has a cardinality of one 499A64B,the type is GDT 499A66B, and the name is CompleteTransmissionIndicator499A68B. The ID 499A70B has a cardinality of one 499A72B, the type isGDT 499A74B, and the name is BusinessTransactionDocumentItemID 499A76B.The PurchasingGroupID 499A78B has a cardinality of zero or one 499A80B,the type is GDT 499A82B, and the name is PurchasingGroupID 499A84B. TheTransshipmentMethodCode 499A86B has a cardinality of one 499A88B, thetype is GDT 499A90B, and the name is TransshipmentMethodCode 499A92B.The ConsignmentIndicator 499A94B has a cardinality of zero or one499A96B, the type is GDT 499A98B, and the name is ConsignmentIndicator499A00C. The ReturnsIndicator 499A02C has a cardinality of zero or one499A04C, the type is GDT 499A06C, and the name is ReturnsIndicator499A08C.

As depicted in FIG. 499AG, the Item package 499A46B includes aPlanningRelevanceIndicator 499A10C, a CompletedIndicator 499A18C, aReceivedQuantity 499A26C, and an OrderPeriod 499A34C. ThePlanningRelevanceIndicator 499A10C has a cardinality of zero or one499A12C, the type is GDT 499A14C, and the name isPlanningRelevanceIndicator 499A16C. The CompletedIndicator 499A18C has acardinality of zero one 499A20C, the type is GDT 499A22C, and the nameis BusinessTransactionCompletedIndicator 499A24C. the ReceivedQuantity499A26C has a cardinality of zero or one 499A28C, the type is GDT499A30C, and the name is Quantity 499A32C. The OrderPeriod 499A34C has acardinality of zero or one 499A36C, the type is GDT 499A38C, and thename is DateTimePeriod 499A40C.

A ProductInformation package 499A42C includes a Product entity 499A44Cwith a cardinality of one 499A46C, the type is GDT 499A48C and the nameis BusinessTransactionDocumentProduct 499A50C. The Product entity499A44C includes an InternalID and a StandardID 499A60C. The InternalID499A52C has a cardinality of one 499A54C, the type is GDT 499A56C, andthe name is ProductInternalID 499A58C. The StandardID 499A60C has acardinality of one 499A62C, the type is GDT 499A64C and the name isProductStandardID 499A66C.

As depicted in FIG. 499AI, the Item package 499A46B includes a Partypackage 499A00D. The Party package 499A00D includes a BuyerParty entity499A02D with a cardinality of zero or one 499A04D. An InternalID entity499A06D is included with a cardinality of zero or one 499A08D, the typeis GDT 499A10D, and the name isBusinessTransactionDocumentPartyInternalID 499A12D.

The Party package 499A00D also includes a VendorParty 499A14D with acardinality of zero or one 499A16D. The VendorParty 499A14D includes anInternalID 499A18D and a StandardID 499A26D. The InternalID 499A18D hasa cardinality of zero or one 499A20D, the type is GDT 499A22D, and thename is BusinessTransactionDocumentPartyInternalID 499A24D. TheStandardID 499A26D has a cardinality of zero or one 499A28D, the type isGDT 499A30D, and the name is BusinessTransactionDocumentPartyStandardID499A32D. A ProductRecipientParty entity 499A34D has a cardinality ofzero or one 499A36D.

The Party package 499A00D includes an InternalID 499A38D and aStandardID 499A46D. The InternalID 499A38D has a cardinality of zero orone 499A40D, the type is GDT 499A42D, and the name isBusinessTransactionDocumentPartyInternalID 499A44D. The StandardID499A46D has a cardinality of zero or one 499A48D, the type is GDT499A50D, and the name is BusinessTransactionDocumentPartyStandardID499A52D.

A Location package 499A54D includes a ShipFromLocation entity 499A56Dwith a cardinality of zero or one 499A58D, the type is GDT 499A60D, andthe name is BusinessTransactionDocumentShipFromLocation 499A62D. AnInternalID 499A64D and a StandardID 499A72D are included. The InternalID499A64D has a cardinality of zero or one 499A66D, the type is GDT499A68D, and the name is LocationInternalID 499A70D. The StandardID499A72D has a cardinality of zero or one 499A74D, the type is GDT499A76D, and the name is LocationStandardID 499A78D. A ShipToLocationentity 499A80D is also included with a cardinality of zero or one499A82D, the type is GDT 499A84D, and the name isBusinessTransactionDocumentShipToLocation 499A86D.

As depicted in FIG. 499AK, the Location package 499A54D includes anInternalID 499A88D with a cardinality of zero or one 499A90D, the typeis GDT 499A92D, and the name is LocationInternalID 499A94D. A StandardID499A96D is also included with a cardinality of zero or one 499A98D, thetype is GDT 499A00E, and the name is LocationStandardID 499A02E.

A BusinessDocumentObjectReference package 499A04E includes aPurchaseOrderReference entity 499A06E. The PurchaseOrderReference entity499A06E has a cardinality of zero or one 499A08E, the type is GDT499A10E, and the name is BusinessTransactionDocumentReference 499A12E.An ID entity 499A14E and an ItemID entity 499A22E are included. The ID499A14E has a cardinality of one 499A16E, the type is GDT 499A18E, andthe name is BusinessTransactionDocumentID 499A20E. The ItemID 499A22Ehas a cardinality of one 499A24E, the type is GDT 499A26E, and the nameis BusinessTransactionDocumentItemID 499A28E.

As depicted in FIG. 499AL, the ScheduleLine package 499A30E includes aConfirmedScheduleLine entity 499A32E with a cardinality of one 499A34E.The ConfirmedScheduleLine entity 499A32E includes aPurchaseOrderItemScheduleLineReferenceID entity 499A36E, aDeliveryPeriod entity 499A44E, and a Quantity entity 499A52E. ThePurchaseOrderItemScheduleLineReferenceID 499A36E has a cardinality ofzero or one 499A38E, the type is GDT 499A40E, and the name isBusinessTransactionDocumentItemSceduleLineID 499A42E. The DeliveryPeriod499A44E has a cardinality of zero or one 499A46E, the type is GDT499A48E, and the name is DateTimePeriod 499A50E. The Quantity 499A52Ehas a cardinality of zero or one 499A54E, the type is GDT 499A56E, andthe name is Quantity 499A58E.

(5) Message Choreography

FIG. 500 depicts a message choreography that describes the logicalsequence of messages that can be used to realize the scenario betweenvendor 50000 and product recipient 50002. The product recipient 50002informs a vendor 50000 of the need to perform a return delivery ofgoods. The Vendor 50000 initially sends a ReturnAuthorizationRequest50004 to a ProductRecipient 50002 to authorize a goods return. TheProductRecipient 50002 then sends instructions in the form ofReturnDeliveryInstructionNotification 50006 to Vendor 50000 to performthe return delivery. These instructions can be confirmed for example, bythe vendor 50000 sending a ReturnDeliveryInstructionConfirmation 50008to the product recipient 50002. The vendor 50000 informs the productrecipient 50002 of the return delivery usingDespatchedDeliveryNotification 50010. Receipt of the return delivery canbe confirmed by the product recipient 50002 relaying aRecievedDeliveryNotification 50012 to Vendor 50000.

(6) Message Data Type Data Model

FIG. 501 depicts the data model for theReturnDeliveryInstructionMessage. The message data typeReturnDeliveryInstructionMessage includes aReturnDeliveryInstructionMessage package 50100, which includes aReturnDeliveryInstructionMessage entity 50102. TheReturnDeliveryInstructionMessage package 50100 also includes aMessageHeader package 50104 and a ReturnDeliveryInstruction package50106. The message data type ReturnDeliveryInstructionMessage makes thestructure available for the following message data types:ReturnDeliveryInstructionNotificationMessage,ReturnDeliveryInstructionConfirmationMessage, and their associatedmessage types and interfaces. TheReturnDeliveryInstructionNotificationMessage and theReturnDeliveryInstructionConfirmationMessage are derived from theReturnDeliveryInstructionMessage as structural views.

There is a 1:c relationship between entities in this Interface unlessotherwise noted herein or indicated in the Figures.

(a) Message Header Package

The MessageHeader package 50104 groups together the business informationthat is relevant for sending a business document in a message. It mayinclude a MessageHeader entity 50108, which groups together the businessinformation from the viewpoint of the sending application to identifythe business document in a message, information about the sender, and,optionally, information about the recipient. The MessageHeader entity50108 may be divided up into a SenderParty 50110 and a RecipientParty50112, and is of type GDT: BusinessDocumentMessageHeaderParty. TheMessageHeader entity 50108 may also include an ID, which is theidentification of the business document in the technical message, and aCreationDateTime, which is the creation date of the business document inthe technical message. A MessageHeader is optional. There is a 1:1relationship between MessageHeader entity 50108 andReturnDeliveryInstructionMessage entity 50102.

A SenderParty entity 50110 is the party responsible for sending abusiness document at the business application level and is of type GDT:BusinessDocumentMessageHeaderParty.

A RecipientParty entity 50112 is the party responsible for receiving abusiness document at the business application level and is of type GDT:BusinessDocumentMessageHeaderParty.

(b) Return Delivery Instruction Package

The ReturnDeliveryInstruction package 50106 groups together theReturnDeliveryInstruction entity 50114 and its packages: a Party package50116; an Location package 50118; a ReturnDeliveryItem package 50120;and a HandlingUnit package 50122. There is a 1:1 relationship betweenthe ReturnDeliveryInstruction entity 50114 and theReturnDeliveryInstructionMessage entity 50102.

A ReturnDeliveryInstruction entity 50114 includes logisticalinstructions to a vendor for a return delivery that he or she is toperform in the future. The ReturnDeliveryInstruction contains values forthe business parties between which the return delivery is to take place,as well as the ship-to location of the return delivery. It subdividesinto instruction items (ReturnDeliveryInstructionItems) with informationabout the arrival times, the quantities of a product to be returned, andthe carriers who are to perform the return transport. References torelevant business documents, in particular to an authorization givenpreviously for return delivery of goods, can be specified for aReturnDeliveryInstructionItem.

ReturnDeliveryInstruction contains the following elements: an ID; aCreationDateTime; a DeliveryTypeCode; and a Note. The ID element is aunique identifier of the return delivery instruction and is of type GDT:BusinessTransactionDocumentID. The CreationDateTime element is thecreation date of the return delivery instruction and is of type GDT:DateTime. The DeliveryTypeCode element is a logistically-relevant typeof delivery (e.g., scrapping or disposal delivery) and is of type GDT:DeliveryTypeCode. The Note element is for return delivery instruction(e.g., data regarding reason for return delivery) is of type GDT: Note.

(i) Party Package

The Party package 50116 groups together the business partners that maybe relevant within the ReturnDeliveryInstruction. The Party package50116 includes a BuyerParty entity 50124, a VendorParty entity 50126,and ProductRecipientParty entity 50128.

The BuyerParty entity 50124 is a party that has purchased the goodsbeing returned or has ordered the repurchase of these goods. TheBuyerParty 501 is of type GDT: BusinessTransactionDocumentParty,whereby, in one implementation, only the InternalID, the StandardID, theBuyerID, the VendorID, and Address are required. For intra-enterprisecommunication (with common master data), use only InternalID for allparty entities. For an inter-enterprise communication (withbusiness-partner-specific master data), use only the StandardID or thepartner-role-specific ID of the receiving partner for all partyentities; in other words, use the BuyerID for Supplier Collaborationscenarios, and use the VendorID for Customer Collaboration scenarios.Due to the different possibilities for ID use, all ID elements of theparticular party are optional.

The VendorParty entity 50126 is the company that sends back the goodsand is of type GDT: BusinessTransactionDocumentParty, whereby, in oneimplementation, only the InternalID, the StandardID, the BuyerID, theVendorID, and Address are required. There is a 1:1 relationship betweenthe VendorParty entity 50126 and the ReturnDeliveryInstruction entity50114. For intra-enterprise communication (with common master data), useonly InternalID for all party entities. For an inter-enterprisecommunication (with business-partner-specific master data), use only theStandardID or the partner-role-specific ID of the receiving partner forall party entities; in other words, use the BuyerID for SupplierCollaboration scenarios, and use the VendorID for Customer Collaborationscenarios. Due to the different possibilities for ID use, all IDelements of the particular party are optional.

The ProductRecipientParty 50128 is the company to whom the goods arereturned and is of type GDT: BusinessTransactionDocumentParty, whereby,in one implementation, only the InternalID, the StandardID, the BuyerID,the VendorID, and Address are required. For intra-enterprisecommunication (with common master data), use only InternalID for allparty entities. For an inter-enterprise communication (withbusiness-partner-specific master data), use only the StandardID or thepartner-role-specific ID of the receiving partner for all partyentities; in other words, use the BuyerID for Supplier Collaborationscenarios, and use the VendorID for Customer Collaboration scenarios.Due to the different possibilities for ID use, all ID elements of theparticular party are optional.

(ii) Location Package

The Location package 50118 groups together the locations that can occurin a delivery process. It includes a ShipFromLocation entity 50130 and aShipToLocation entity 50132. There is a 1:1 relationship between theShipToLocation entity 50132 and the ReturnDeliveryInstruction entity50114.

The ShipFromLocation is the location from which goods are sent back. TheShipFromLocation entity 50130 is of type GDT:BusinessTransactionDocumentShipFromLocation, whereby the InternalID, theStandardID, the BuyerID, the VendorID, the Note, the LoadingLocation,and the Address are used. For intra-enterprise communication (withcommon master data), only use the InternalID for all location entities.For inter-enterprise communication (with business-partner-specificmaster data), use for all location entities either only the StandardIDor the partner-role-specific ID of the sending or receiving partner; inother words, the BuyerID or VendorID. Due to the different possibilitiesfor ID use, all the ID elements of each location are optional.

The ShipToLocation is the location to which goods are sent back. TheShipToLocation entity 50132 is of type GDT:BusinessTransactionDocumentShipToLocation, whereby the InternalID, theStandardID, the BuyerID, the VendorID, the Note, the LoadingLocation,and the Address are used. For intra-enterprise communication (withcommon master data), only use the InternalID for all location entities.For inter-enterprise communication (with business-partner-specificmaster data), use for all location entities either only the StandardIDor the partner-role-specific ID of the sending or receiving partner; inother words, the BuyerID or VendorID. Due to the different possibilitiesfor ID use, all the ID elements of each location are optional.

(iii) Return Delivery Instruction Item Package

The ReturnDeliveryInstructionItem package 50120 groups together theReturnDeliveryInstructionItem with its packages. It includes aReturnDeliveryInstructionItem entity 50134,DeliveryBusinessTransactionDocumentReference package 50136, a Partypackage 50138, a ProductInformation package 50140, and a Batch package50142.

The ReturnDeliveryInstructionItem entity 50134 is an item contained inthe ReturnDeliveryInstruction that specifies the quantity of a productto be returned with its planned delivery period. TheReturnDeliveryInstructionItem 50134 contains values for the carriers whoare going to perform the return, the ship-to location, and references tothe business documents that are relevant within the return delivery.There is a 1:n relationship between the ReturnDeliveryInstructionItementity 50134 and the ReturnDeliveryInstruction entity 50114.

The ReturnDeliveryInstructionItem 50134 contains the following elements:ID; DeliveryTypeCode; ReturnMaterialAuthorisationID; SerialID (serialnumber); GroupID; DeliveryPeriod; RequestedQuantity; ApprovedQuantity;and Note.

The ID is a unique identifier for a ReturnDeliveryInstructionItem and isof type GDT: BusinessTransactionDocumentItemID. The DeliveryTypeCode isa logistically-relevant type of delivery (e.g., scrapping or disposaldelivery) and is of type GDT: DeliveryTypeCode. TheReturnMaterialAuthorisationID is a unique identifier for authorizing agoods return to which the party returning the goods can refer in asubsequent notification of the return delivery; for example, using theDespatchedDeliveryNotification message. It is required specificallywithin return delivery scenarios in which the delivery item does notrefer to a purchase order or a scheduling agreement. TheReturnMaterialAuthorisationID is of typeGDT:ReturnMaterialAuthorisationID. The SerialID (serial number) is a uniqueidentifier for an individual item of a delivered product that isassigned in the context of production and is of type GDT: SerialID. Theserial numbers must only specify product instances of the productspecified in the associated ReturnDeliveryInstructionItem. Therefore,the number of serial numbers must be the same or smaller than theproduct quantity specified under “ApprovedQuantity” in theReturnDeliveryInstructionItem. The “smaller” case can occur if not allthe individual items of a product can be specified by serial numbers.The GroupID is a unique identifier for a group of instruction items towhich a ReturnDeliveryInstructionItem belongs and is of type GDT:BusinessTransactionDocumentItemGroupID. A return delivery must onlycontain the quantities of products that are listed inReturnDeliveryInstructionItems with the same GroupID. The DeliveryPeriodis the period in which the quantity of a product given in theReturnDeliveryInstructionItem should be delivered and is of type GDT:DateTimePeriod. The RequestedQuantity is a return delivery quantityrequested in the delivery unit of measure and is of type GDT: Quantity.The ApprovedQuantity is an approved return delivery quantity in thedelivery unit of measure and is of type GDT: Quantity. The Note is anote for item of return delivery instruction (e.g., instructions forhandling the product being returned that is specified in the item) andis of type GDT: Note.

The DeliveryItemBusinessTransactionDocumentReference package 50136groups together all the business document references that can berelevant to the ReturnDeliveryInstructionItem. TheDeliveryItemBusinessTransactionDocumentReference package 50136 includesa ReturnAuthorizationReference entity 50144.

A ReturnAuthorizationReference entity 50144 is the reference to therequest for authorization of a goods return and is of type GDT:BusinessTransactionDocumentReference.

The Party package 50138 groups together the business partners that mightbe relevant in a ReturnDeliveryInstructionItem. The Party package 50138includes a BuyerParty entity 50146 and a CarrierParty entity 50148.

A BuyerParty entity 50146 is a party that has purchased the product tobe returned or has ordered the repurchase of these goods. The BuyerPartyentity 50146 is type GDT: BusinessTransactionDocumentParty, whereby, inone implementation, only the InternalID, the StandardID, the BuyerID,the VendorID, and Address are required. For intra-enterprisecommunication (with common master data), only use the InternalID for allproduct entities. For inter-enterprise communication (withbusiness-partner-specific master data), use for all product entitieseither only the StandardID or the partner-role-specific ID of thesending or receiving partner; in other words, the BuyerID or VendorID.Due to the different possibilities for ID use, all ID elements of eachparticular product are optional.

In the case of BuyerParty 50146, a default logic may exist at the headerlevel for the items. This means that the BuyerParty 50146 specified atthe header level is valid for all items as long as the informationspecified at item level does not contradict this.

A CarrierParty entity 50148 is the company or person that/who transportsthe products being returned. The CarrierParty is type GDT:BusinessTransactionDocumentParty, whereby, in one implementation, onlythe InternalID, the StandardID, the BuyerID, the VendorID, and Addressare required. There is a 1:cn relationship between CarrierParty entity50148 and ReturnDeliveryInstructionItem entity 50134. Forintra-enterprise communication (with common master data), only use theInternalID for all product entities. For inter-enterprise communication(with business-partner-specific master data), use for all productentities either only the StandardID or the partner-role-specific ID ofthe sending or receiving partner; in other words, the BuyerID orVendorID. Due to the different possibilities for ID use, all ID elementsof each particular product are optional.

The ProductInformation package 50140 groups together all the informationfor identifying and describing a product in theReturnDeliveryInstructionItem. The ProductInformation package 50140contains a Product entity 50150.

The Product entity 50150 identifies and describes the product beingreturned and is of type GDT: BusinessTransactionDocumentProduct,whereby, in one implementation, only the InternalID, the StandardID, theBuyerID, and the VendorID are required. There is a 1:1 relationshipbetween Product entity 50150 and ReturnDeliveryInstructionItem entity50134. For inter-enterprise communication (withbusiness-partner-specific master data), use for all product entitieseither only the StandardID or the partner-role-specific ID of thesending or receiving partner; in other words, the BuyerID or VendorID.Due to the different possibilities for ID use, all ID elements of eachparticular product are optional.

The Batch package 50142 groups information used to identify and describea batch within the ReturnDeliveryInstructionItem. It contains a Batchentity 50152.

The Batch entity 50152 identifies and describes the batch to be returnedand contains the following elements: InternalID; BuyerID; VendorID;ManufacturingDate; BestBeforeDate; and OriginCountryCode.

The InternalID is a proprietary identifier for the batch and is of typeGDT: BatchID. The BuyerID is a unique identifier used by the BuyerPartyfor the batch and is of type GDT: BatchID. The VendorID is a Uniqueidentifier used by the VendorParty for the batch and is of type GDT:BatchID. The ManufacturingDate is the date of manufacture of the batchand is of type GDT: Date. The BestBeforeDate is the Best-before date ofbatch and is of type GDT: Date. The OriginCountryCode is a codedrepresentation of country of origin of the batch and is of type

GDT: CountryCode.

(iv) Delivery Handling Unit Package

The DeliveryHandlingUnit package entity 50122 summarizes informationthat characterizes in greater detail how the return delivery is to bepacked. The DeliveryHandlingUnit package entity 50122 includes aHandlingUnit entity 50154.

A HandlingUnit entity 50154 is a physical unit of packaging materials(load carrier, additional packaging materials) and the packaged products(of type “material”) and is of type GDT: HandlingUnit, whereby the lowerstructures “AdditionalPackaging” and “LowerLevelHandlingUnit” are notrequired. There is a 1:cn relationship between HandlingUnit entity 50154and a ReturnDeliveryInstruction entity 50114.

(7) Message Data Type Element Structure

The message data type element structure for the Return DeliveryInstruction Notification 50220 is depicted in FIG. 502A-L. The elementstructure is similar to the data model, but provides additionalinformation regarding the details of the interface. The elementstructure identifies the different packages 50200 in the interface, andrepresents the entities at various levels within the interface. Asdepicted in FIG. 502A, the interface for Return Delivery InstructionNotification 50220 includes six levels 50202, 50204, 50206, 50208,50210, and 50212. The outermost package of this interface is aReturnDeliveryInstructionNotification 50220, which includes aReturnDelivery-Notification entity 50222 at the first level 50202. TheReturnDelivery-Notification 50222 has a cardinality of one 1 50224, thetype is MDT 50226, and the name is ReturnDeliveryInstructionNotification50228.

The ReturnDeliveryInstructionNotification package 50220 includes aBusiness Document Header package 50230. The Business Document Headerpackage 50230 includes a MessageHeader entity 50232 that has acardinality of one 50234, the type is GDT 50236, and the name isBusinessDocumentMessageHeader 50238. The MessageHeader entity 50232includes an ID entity 50240, a CreationDateTime entity 50248, and aSenderParty entity 50256. The ID entity 50240 has a cardinality of one50242, the type is GDT 50244, and the name is BusinessDocumentMessageID50246. The CreationDateTime entity 50248 has a cardinality of one 50250,the type is GDT 50252, and the name is DateTime 50254. The SenderPartyentity 50256 has a cardinality of zero or one 50258, the type is GDT50260, and the name is BusinessDocumentMessageHeaderParty 50262.

The SenderParty entity 50256 includes an InternalID entity 50264 and aStandardID entity 50272. The InternalID entity 50264 has a cardinalityof zero or one 50266, the type is GDT 50268, and the name isPartyInternal ID 50270. The StandardID entity 50272 may have any number50274 of StandardID entities 50272 for a SenderParty entity 50256, thetype is GDT 50276, and the name is PartyStandardID 50278.

As depicted in FIG. 502B, the ReturnDeliveryInstructionNotificationpackage 50220 includes a RecipientParty entity 50280 at the third level.The RecipientParty entity 50280 has a cardinality of zero or one 50282,the type is GDT 50284, and the name isBusinessDocument-MessageHeaderParty 50286. The RecipientParty entity50280 includes an InternalID entity 50288 and a StandardID entity 50296.The InternalID entity 50288 has a cardinality of zero or one 50290, thetype is GDT 50292, and the name is PartyInternalID 50294. The StandardIDentity 50296 may have any number 50298 of StandardID entities 50296 fora RecipientParty entity 50280, the type is GDT 50200A and the name isPartyStandardID 50202A.

The ReturnDeliveryInstructionNotification package 50220 also includes aReturnDelivery Instruction package 50204A. The ReturnDeliveryInstruction package 50204A includes a ReturnDelivery-Instruction entity50206A with a cardinality of one 50208A, and a name“ReturnDeliveryInstruction” 50210A. The ReturnDelivery-Instructionentity 50206A includes an ID entity 50212A, a CreationDateTime entity50220A, and a DeliveryTypeCode entity 50228A. The ID entity 50212A has acardinality of zero or one 50214A, the type is GDT 50216A and the nameis BusinessTransactionDocumentID 50218A. The CreationDateTime entity50220A has a cardinality of one 50222A, the type is GDT 50224A, and thename is DateTime 50226A. The DeliveryTypeCode entity 50228A has acardinality of zero or one 50230A, the type is GDT 50232A, and the nameis DeliveryTypeCode 50234A.

As depicted in FIG. 502C, the ReturnDeliveryInstructionNotificationpackage 50220 also includes a Party package 50236A. The Party package50236A includes a BuyerParty entity 50238A with a cardinality of zero orone 50240A. The data type is GDT 50242A, and the name isBusinessTransactionDocumentParty 50244A. The BuyerParty entity 50238Aincludes an InternalID entity 50246A, a StandardID entity 50254A, aBuyerID entity 50262A, a VendorID entity 50270A, and an Address entity50278A. The InternalID entity 50246A has a cardinality of zero or one50248A, the type is GDT 50250A, and the name is PartyInternalID 50252A.The StandardID entity 50254A may have any number 50256A of StandardIDentities 50254A for a Party package, the type is GDT 50258A, and thename is PartyStandardID 50260A. The BuyerID entity 50262A has acardinality of zero or one 50264A, the type is GDT 50266A, and the nameis PartyPartyID 50268A. The VendorID entity 50270A has a cardinality ofzero or one 50272A, the type is GDT 50274A, and the name is PartyPartyID50276A. The Address entity 50278A has a cardinality of zero or one50280A, the type is GDT 50282A, and the name is Address 50284A.

The Party package 50236A includes a VendorParty entity 50286A at thethird level 50208. The cardinality of the VendorParty entity is zero orone 50288A for a Party package 50236A, the type is GDT 50290A, and thename is BusinessTransactionDocumentParty 50292A. The VendorParty entity50286A includes an InternalID entity 50294A with a cardinality of zeroor one 50296A, the type is GDT 50298A, and the name is PartyInternalID50200B.

As depicted in FIG. 502D, the VendorParty entity 50286A also includes aStandardID entity 50202B, a BuyerID entity 50210B, a VendorID entity50218B, and an Address entity 50226B. The StandardID entity 50202B mayhave any number 50204B of Standard ID entities for a VendorParty entity50286A. The data type is GDT 50206B, and the name is PartyStandardID50208B. The BuyerID entity 50210B has a cardinality of zero or one50212B, the type is GDT 50214B, and the name is PartyPartyID 50216B. TheVendorID entity 50218B has a cardinality of zero or one 50220B, the typeis GDT 50222B, and the name is PartyPartyID 50224B. The Address entity50226B has a cardinality of zero or one 50228B, the type is GDT 50230B,and the name is Address 50232B.

The ReturnDeliveryInstructionNotification 50220 also includes aProductRecipientParty entity 50234B with a cardinality of zero or one50236B, a data type of GDT 50238B, and a name ofBusinessTransactionDocumentParty 50240B. The ProductRecipientPartyentity 50234B includes an InternalID entity 50242B, a StandardID entity50250B, a BuyerID entity 50258B, a VendorID entity 50266B, and anAddress entity 50274B. The InternalID entity 50242B has a cardinality ofzero or one 50244B, the type is GDT 50246B, and the name isPartyInternalID 50248B. The StandardID entity 50250B may have any number50252B of StardardID entities 50250B for a ProductRecipientParty entity50234B. The data type is GDT 50254B and the name is PartyStandardID50256B. The BuyerID entity 50258 has a cardinality of zero or one50260B, the type is GDT 50262B, and the name is PartyPartyID 50264B. TheVendorID entity 50266B has a cardinality of zero or one 50268B, the typeis GDT 50270B, and the name is PartyPartyID 50272B. The Address entity50274B has a cardinality of zero or one 50276B, the type is GDT 50278B,and the name is Address 50280B.

As depicted in FIG. 502E, the ReturnDeliveryInstructionNotificationpackage 50220 includes a Location package 50282B. The Location package50282B includes a ShipFromLocation entity 50284B at the third level50208 with a cardinality of zero or one 50286B, and a type of GDT50288B, with a name of BusinessTransactionDocumentShipFromLocation50290B. The ShipFromLocation entity 50284B includes an InternalID entity50292B, a StandardID entity 50200C, a BuyerID entity 50208C, a VendorIDentity 50216C, a Note entity 50224C, and a LoadingLocation entity 50232Cat the fourth level 50210. The InternalID entity 50292B has acardinality of zero or one 50294B, the type is GDT 50296B, and the nameis LocationInternalID 50298B. The StandardID entity 50200C may have anynumber 50202C of StandardID entities 50200C for a ShipFromLocationentity 50284B. The type is GDT 50204C, and the name isLocationStandardID 50206C. The BuyerID entity 50208C has a cardinalityof zero or one 50210C, the type is GDT 50212C and the name isLocationPartyID 50214C. The VendorID entity 50216C has a cardinality ofzero or one 50218C, the type is GDT 50220C, and the name isLocationPartyID 50222C. The Note entity 50224C has a cardinality of zeroor one 50226C, the type is GDT 50228C, and the name is Note 50230C. TheLoadingLocation entity 50232C has a cardinality of zero or one 50234C,the type is GDT 50236C, and the name isBusinessTransactionDocumentLocation 50238C.

As depicted in FIG. 502F, the ShipFromLocation 50284B also includes anInternalID 50240C, a StandardID entity 50248C, a BuyerID entity 50256C,and a VendorID entity 50264C at the fifth level. The InternalID entity50240C has a cardinality of zero or one 50242C, the type is GDT 50244C,and the name is LocationInternalID 50246C. The StandardID entity 50248Cmay have any number 50250C of StandardID entities 50248C for aShipFromLocation entity 50284B. The type is GDT 50252C, and the name isLocationStandardID 50254C. The BuyerID entity 50256C has a cardinalityof zero or one 50258C, the type is GDT 50260C, and the name isLocationPartyID 50262C. The VendorID entity 50264C has a cardinality ofzero or one 50266C, the type is GDT 50268C, and the name isLocationPartyID 50270C. In addition, the ShipFromLocation entity 50284Bincludes an Address entity 50272C with a cardinality of zero or one50274C, a data type GDT 50276C, and a name of Address 50278C.

The ReturnDeliveryInstructionNotification package 50220 also includes aShipToLocation entity 50280C with a cardinality of zero or one 50282C, adata type GDT 50284C, and a name ofBusinessTransactionDocumentShipToLocation 50286C. The ShipToLocationentity 50280C includes an InternalID entity 50288C, a StandardID entity50296C, and a BuyerID entity 50204D. The InternalID entity 50288C has acardinality of zero or one 50290C, the type is GDT 50292C, and the nameis LocationInternalID 50294C. The StandardID entity 50296C may have anynumber 50298C of StandardID entities 50296Cfor a ShipToLocation entity50280C. The data type is GDT 50200D and the name is LocationStandardID50202D. The BuyerID 50204D has a cardinality of zero or one 50206D, thetype is GDT 50208D, and the name is LocationPartyID 50210D.

As depicted in FIG. 502G, the ShipToLocation entity 50280C includes aVendorID entity 50212D and a Note entity 50216D. The VendorID entity50212D has a cardinality of zero or one 50213D, the type is GDT 50214D,and the name is LocationPartyID 5021 SD. the Note entity 50216D has acardinality of zero or one 50217D, the type is GDT 50218D, and the nameis Note 50220D.

The ReturnDeliveryInstructionNotification package 50220 includes anUnloadingLocation entity 50222D at the third level 50208 with acardinality of zero or one 50224D. The data type is GDT 50226D, and thename is BusinessTransactionDocumentLocation 50228D. TheUnloadingLocation entity 50222D includes an InternalID entity 50230D, aStandardID entity 50238D, a BuyerID entity 50246D, and a VendorID 50256Dat the fifth level 50212. An Address entity 50264D is included at thefourth level 50210 and a Note entity 50272D is included at the thirdlevel 50208. The InternalID entity 50230D has a cardinality of zero orone 50232D, the type is GDT 50234D, and the name is LocationInternalID50236D. The StandardID entity 50238D may have any number 50240D ofStandardID entities 50238D for a UnloadingLocation entity 50222D. Thedata type is GDT 50242D and the name is LocationStandardID 50244D. TheBuyerID entity 50246D has a cardinality of zero or one 50248D, the typeis GDT 50250D, and the name is LocationPartyID 50252D. The VendorIDentity 50256D has a cardinality of zero or one 50258D, the type is GDT50260D, and the name is LocationPartyID 50262D. The Address entity50264D has a cardinality of zero or one 50266D, the type is GDT 50268D,and the name is Address entity 50270D. The Note entity 50272D has acardinality of zero or one 50274D, the type is GDT 50276D, and the nameis Note 50278D.

As depicted in FIG. 502G, the ReturnDeliveryInstructionNotificationpackage 50220 includes an Item package 50280D. The Item package 50280Dincludes an Item entity 50282D with any number 50284D of Item entitiesfor an Item package 50280D. The name is ReturnDeliveryInstructionItem50286D. The Item entity 50282D includes an ID entity 50288D and aDeliveryTypeCode entity 50296D. The ID entity 50288D has a cardinalityof zero or one 50290D, the type is GDT 50292D, and the name isBusinessTransactionDocumentItemID 50294D. The DeliveryTypeCode entity50296D has a cardinality of zero or one 50298D, the type is GDT 50200E,and the name is DeliveryTypeCode 50202E.

The ReturnDeliveryInstructionNotification package 50220 also includes aBusinessTransaction DocumentReference package 50204E. TheBusinessTransaction DocumentReference package 50204E. TheBusinessTransaction DocumentReference package 50204E includes aReturnAuthorisationRequest Reference entity 50206E with a cardinality ofzero or one 50208E, a type of GDT 50210E, and the nameBusinessTransactionDocumentReference 50212E. TheReturnAuthorisationRequest Reference entity 50206E includes aReturnMaterialAuthorisationID entity 50214E with a cardinality of one50216E, the type is GDT 50218E, and the name isReturnMaterialAuthorisationID 50220E.

The ReturnDeliveryInstructionNotification package 50220 also includes aParty package CC22E. The Party package 50222E includes a BuyerPartyentity 50224E with cardinality of zero or one 50226E, a data type GDT50228E, and the name BusinessTransactionDocumentParty 50230E. TheBuyerParty entity 50224E includes an InternalID entity 50232E and aStandardID entity 50240E. The InternalID entity 50232E has a cardinalityof zero or one 50234E, the type is GDT 50236E, and the name isPartyInternalID 50238E. The StandardID entity 50240E may have any number50242E of StandardID entities 50240E for a BuyerParty entity 50224E. Thedata type is GDT 50244E and the name is PartyStandardID 50246E.

As depicted in FIG. 502H, the BuyerParty 50224E includes a BuyerID50248E, a VendorID 502056E, and an Address 50264E. The BuyerID entity50248E has a cardinality of zero or one 50250E, the type is GDT 50252E,and the name is PartyPartyID 50254E. The VendorID entity 502056E has acardinality of zero or one 50258E, the type is GDT 50260E and the nameis PartyPartyID 50262E. The Address entity 50264E has a cardinality ofzero or one 50266E, the type is GDT 50268E, and the name is Address50270E.

The ReturnDeliveryInstructionNotification package 50220 includes aCarrierParty entity 50272E at the fourth level 50210. The CarrierPartyentity 50272E may have any number 50274E of CarrierParty entities 50272Efor a ReturnDeliveryInstructionNotification package 50220. The data typeis GDT 50276E and the name is BusinessTransactionDocumentParty 50278E.The CarrierParty 50272E includes an InternalID entity 50280E, aStandardID entity 50288E, a BuyerID entity 50296E, a VendorID entity50204F, and a Address entity 50212F. The InternalID entity 50280E has acardinality of zero or one 50282E, the type is GDT 50284E, and the nameis PartyInternalID 50286E. The StandardID entity 50288E may have anynumber 50290E of StandardID entities 50288E for a CarrierParty entity50272E. The data type is GDT 50292E, and the name is PartyStandardID50294E. The BuyerID entity 50296E has a cardinality of zero or one50298E, the type is GDT 50200F, and the name is PartyPartyID 50202F. TheVendorID entity 50204F has a cardinality of zero or one 50206F, the typeis GDT 50208F, and the name is PartyPartyID 50210F. The Address entity50212F has a cardinality of zero or one 50214F, the type is GDT 50216F,and the name is Address 50218F.

As depicted in FIG. 5021, the ReturnDeliveryInstructionNotificationpackage 50220 includes a ProductInformation package 50220F. TheProductInformation package 50220F includes a Product entity 50222F witha cardinality of one 50224F, a data type GDT 50226F, and a name ofBusinessTransactionDocumentProduct 50228F. The Product entity 50222Fincludes an InternalID entity 50230F, a StandardID entity 50238F, aBuyerID entity 50246F, and a VendorID entity 50254F. The InternalIDentity 50230F has a cardinality of zero or one 50232F, the type is GDT50234F, and the name is ProductInternalID 50236F. The StandardID entity50238F has a cardinality of zero or one 50240F, the type is GDT 50242F,and the name is ProductStandardID 50244F. The BuyerID entity 50246F hasa cardinality of zero or one 50248F, the type is GDT 50250F, and thename is ProductPartyID 50252F. The VendorID entity 50254F has acardinality of zero or one 50256F, the type is GDT 50258F, and the nameis ProductPartyID 50260F.

The ReturnDeliveryInstructionNotification package 50220 also includes aBatch package 50262F. The Batch package 50262F includes a Batch entity50264F with a cardinality of zero or one 50266F. The Batch entity 50264Fincludes an InternalID entity 50266F, a VendorID entity 50274F, aProductRecipientID entity 50282F, and a ManufacturingDate entity 50290F.The InternalID entity 50266Fhas a cardinality of zero or one 50268F, thetype is GDT 50270F, and the name is BatchID 50272F. The VendorID entity50274F has a cardinality of zero or one 50276F, the type is GDT 50278F,and the name is BatchID 50280F. The ProductRecipientID entity 50282F hasa cardinality of zero or one 50284F, the type is GDT 50286F, and thename is BatchID 50288F. The ManufacturingDate entity 50290F has acardinality of zero or one 50292F, the type is GDT 50294F, and the nameis Date 50296F.

As depicted in FIG. 502J, the Batch entity 50264F also includes aBestBeforeDate entity 50298F and an OriginCountryCode entity 50206G. TheBestBeforeDate entity 50298F has a cardinality of zero or one 50200G,the type is GDT 50202G, and the name is Date 50204G. TheOriginCountryCode entity 50206G has a cardinality of zero or one 50208G,the type is GDT 50210G, and the name is CountryCode 50212G.

The ReturnDeliveryInstructionNotification package 50220 includes aSerialID entity 50214G, a GroupID entity 50200, a DeliveryPeriod entity50222G, a RequestedQuantity entity 50230G, an ApprovedQuantity entity50238G, and a Note entity 50246G at the fourth level 50210. The SerialIDentity 50214G may have any number 50216G of SerialID entities 50214G fora ReturnDeliveryInstructionNotification package 50220, a data type ofGDT 50218G, and a name SerialID 50220G. The GroupID entity 50200 hascardinality of zero or one 50200, the type is GDT 50200, and the name isBusinessTransactionDocumentItemGroupID 50200. The DeliveryPeriod entity50222G has a cardinality of zero or one 50224G, the type is GDT 50236G,and the name is DateTimePeriod 50228G. The RequestedQuantity entity50230G has a cardinality of zero or one 50232G, the type is GDT 50234G,and the name is Quantity 50236G. The ApprovedQuantity entity 50238G hasa cardinality of one 50240G, the type is GDT 50242G, and the name isQuantity 50244G. The Note entity 50246G has a cardinality of zero or one50248G, the type is GDT 50250G, and the name is Note 50252G.

The ReturnDeliveryInstructionNotification package 50220 also includes aHandling Unit package 50254G. The Unit package 50254G includes aHandlingUnit entity 50256G which may have any number 50258G ofHandlingUnit entities 50256G for a Handling Unit package 50254G. Thedata type is GDT 50260G and the name is HandlingUnit 50262G. TheHandlingUnit entity 50256G includes an ID entity 50264G and aLoadCarrier entity 50272G. The ID entity 50264G has a cardinality of one50255G, a type of GDT 50268G, and the name HandlingUnitID 50270G. TheLoadCarrier entity 50272G has a cardinality of one 50274G and a datatype of GDT 50276G.

As depicted in FIG. 502K, the LoadCarrier entity 50272G includes aProduct entity 50278G with a cardinality of one 50280G and a data typeGDT 50282G. The a Product entity 50278G includes an InternalID entity50284G, a StandardID entity 50292G, a Buyer ID entity 50200H, and aVendor ID entity 50208H. The InternalID 50284G has a cardinality of zeroor one 50286G, the type is GDT 50288G, and the name is ProductInternalID50290G. The StandardID entity 50292G has a cardinality of zero or one50294G, the type is GDT 50296G, and the name is ProductStandardID50298G. The Buyer ID entity 50200H has a cardinality of zero or one50202H, the type is GDT 50204H, and the name is ProductPartyID 50206H.The Vendor ID entity 50208H has a cardinality of zero or one 50210H, thetype is GDT 50212H, and the name is ProductPartyID 50214H.

The ReturnDeliveryInstructionNotification package 50220 also includes aHeightMeasure 50216H, a LengthMeasure entity 50224H, a WidthMeasureentity 50232H, a GrossVolumeMeasure entity 50240H, and aNetVolumeMeasure entity 50248H. The HeightMeasure entity 50216H has acardinality of zero or one 50218H, the type is GDT 50220H, and the nameis Measure 50222H. The LengthMeasure entity 50224H has a cardinality ofzero or one 50226H, the type is GDT 50228H, and the name is Measure50230H. The WidthMeasure 50232H has a cardinality of zero or one 50234H,the type is GDT 50236H, and the name is Measure 50238H. TheGrossVolumeMeasure entity 50240H has a cardinality of zero or one50242H, the type is GDT 50244H, and the name is Measure 50246H. TheNetVolumeMeasure entity 50248H has a cardinality of zero or one 50250H,the type is GDT 50252H, and the name is Measure 50254H.

The ReturnDeliveryInstructionNotification package 50220 also includes aGrossWeightMeasure entity 50256H, a NetWeightMeasure 50264H, and a Load50272H at the fourth level 50210. The GrossWeightMeasure 50256H has acardinality of zero or one 50258H, the type is GDT 50260H, and the nameis Measure 50262H. The NetWeightMeasure entity 50264H has a cardinalityof zero or one 50266H, the type is GDT 50268H, and the name is Measure50270H. The Load entity 50272H may have any number 50274H of Loadentities 50272 for a ReturnDeliveryInstructionNotification package50220. The data type is GDT 50276H. ABusinessTransactionDocumentReference entity 50278H is included at thefifth level 50212 and has a type of GDT 50280H. An Item ID entity 50282His included at the sixth level and has a cardinality of one 50284H, thetype is GDT 50286H, and the name is BusinessTransactionDocumentItemID50288H.

The Load entity 50272H includes a Quantity entity 50289H and a SerialIDentity 50293H at the fifth level 50212. The Quantity entity 50289H has acardinality of one 50290H, the type is GDT 50291H, and the name isQuantity 50292H. The SerialID entity 50293H has a cardinality of zero orone 50294H, the type is GDT 50295H, and the name is SerialID 50296H.

oo) RFQ Legal Document Interfaces

RFQLegalDocument interfaces can be used to exchange bid invitation databetween a purchaser and a document management system in an A2A processand to generate a legal text document (e.g., a form contract). RFQ(“Request for Quotation”) is a term (“Ausschreibung” in German) thatincludes bid invitations and auctions.

Many complex processes can exist that run in distributed systemlandscapes and that are dependent on information regarding bidinvitations. The RFQLegalDocument interface can provide directintegration with a Document Management System (e.g., the application“DocumentBuilder” which can be referred to by “Document Management”). ADocument Management System can generate a legal text document withcorresponding legal clauses using the business data framework of the bidinvitation and send this as an attachment back to a procurement systemthat is carrying out the bid invitation.

(1) Message Types

(a) RFQ Legal Document Request

An RFQLegalDocumentRequest is a request from Purchasing to DocumentManagement to generate a legal text document from a bid invitation. Thestructure of the message type RFQLegalDocumentRequest can be determinedby the message data type RFQLegalDocumentMessage, which contains theobject RFQ in the RFQLegalDocument view. An RFQLegalDocumentRequestmessage can place a bid invitation at the disposal of the DocumentManagement System. In the Document Management System, enhancements canbe made and added to an RFQLegalDocumentRequest in the form ofattachments. The business document object RFQ (bid invitation) remainsunchanged in structure and process ownership can remain in a procurementsystem.

(b) RFQ Legal Document Notification

An RFQLegalDocumentNotification is a notification from DocumentManagement to Purchasing with a legal text document. The message typeRFQLegalDocumentNotification can be determined by the message data typeRFQLegalDocumentMessage, which contains the object RFQ in theRFQLegalDocument view. A generated legal text document is transmitted asa structure element LegalDocumentAttachment, while other structureelements of the MDT RFQLegalDocumentMessage are not used.

(2) Message Choreography

In some B2B processes, an initiator is a purchaser who sends a bidinvitation. During a period before a submission deadline, informationgoes back and forth between the bidder and the purchaser. Thatinformation concerns the bid, queries, revised bids, possible changes tothe bid invitation, and the like. After the submission deadline passes,the purchaser compares bids and decides to accept one, more, or none atall.

With regard to the RFQLegalDocument interfaces described in thisdocument, the scenarios involving an initiative for creation of thelegal text document coming from a purchaser can be distinguished. Insome scenarios, a legal department is called on in parallel and withmanual coordination, to come up with legal wording based on a businessdata framework of a bid invitation. On agreement, the legal wording(e.g., a contract) is signed and is usually filed as an unstructuredtext document on a file server. This manual process of coordinationbetween a structured document in the procurement system and a legal textdocument is being converted to a system-integrated process by means ofthe messages RFQLegalDocumentRequest 50306 andRFQLegalDocumentNotification 50308.

FIG. 503 shows the message choreography for RFQLegalDocument. Themessage choreography describes the possible logical sequence of themessages that are necessary to realize the scenario between a DocumentManagement server 50300, a Purchasing server 50302 and a Supplier server50304.

In the framework of the bid invitation process, purchasing can send thecurrent status of the structured business document at certain times toDocument Management using the RFQLegalDocumentRequest 50306. Theconditions that trigger sending of the status can be determined by theDocument Management user. The Document Management System can create thelegal text document from the structured data framework. Thus, DocumentManagement can avail of the predefined contract clauses and textpassages in order to make the legal department's internal process moreefficient. The resulting legal text document is then returned toPurchasing in the form of an attachment with theRFQLegalDocumentNotification 50308, without changing the structure ofthe business object RFQ.

Other messages are sent between the Purchasing server 50302 and theSuplier server 50304. An RFQRequest message 50310 is sent from thePurchasing server 50302 to the Supplier server 50304. An RFQRequest isthe request from a purchaser to a bidder to participate in a request forquotation for a product. An RFQAcceptanceConfirmation 50312 is sent fromthe Supplier server 50304 to the Purchasing server 50302. AnRFQChangeRequest message 50314 is sent from the Purchasing server 50302to the Supplier server 50304. An RFQChangeRequest is a change to thepurchaser's request for a bidder to participate in the request forquotation for a product. An RFQCancellationRequest message 50316 is sentfrom the Purchasing server 50302 to the Supplier server 50304. AnRFQCancellationRequest is a cancellation by the purchaser of a requestfor quotation for a product. A QuoteNotification message 50318 is sentfrom the Supplier server 50304 to the Purchasing server 50302. AQuoteNotification is the quote of a bidder communicated to a purchaserconcerning the request for quotation for a product by the purchaser. AnRFQResultNotification message 50320 is sent from the Purchasing server50302 to the Supplier server 50304. An RFQResultNotification is anotification by a purchaser to a bidder about the type and extent of theacceptance of a quote or about the rejection of the quote. AnRFQResultAcceptanceConfirmation message 50322 is sent from the Supplierserver 50304 to the Purchasing server 50302.

Messages within the bid invitation process can be sent EOIO (exactlyonce in order) and serialized using message queues. Each purchase ordercould have its own message queue (as opposed to one queue for all bidinvitations) such that one failed message might not block all the otherbid invitation messages in the entire system.

To handle errors, for example, to restart a process that is corrupt as aresult of a failed message, the bid invitation system should provide anoption for transferring the current status of a bid invitation at anytime using an RFQ message. At the same time the procurement systemshould provide a facility to transfer the current status of thepreceding document (requirement or purchase contract) with anRFQExecutionRequest message (not shown) with all data. To be able toreset a process following a failed RFQExecutionRequest message, the bidinvitation system should at all times be capable of restarting a bidinvitation process with an RFQExecutionRequest message.

The RFQLegalDocument message can be implemented in an assignment systemusing the message RFQLegalDocumentRequest_Out andRFQLegalDocumentNotification_In.

(3) Data Model of the RFQ Legal Document Message

The message data type RFQLegalDocumentMessage groups businessinformation that is relevant for the sending of a business document in amessage and the object RFQ contained in the business document in theview required for RFQLegalDocument. As depicted in FIG. 504, theRFQLegalDocumentMessage package 50402 includes a MessageHeader package50404, an RFQ package 50406 and an RFQLegalDocumentMessage entity 50408.

Elements or entities of the RFQLegalDocumentMessage message data typethat might not be used in all message types may include all or fewer ofthe following: the InternalAttachmentWebAddress entity 50408C and theInternalDescription entity 50410C of the Description package 50438 ofthe RFQ package 50406, and those entities of the Description package50416B of the Item package 50440. The message data typeRFQLegalDocumentMessage provides the structure for the message typesRFQLegalDocumentRequest and RFQLegalDocumentNotification and therelevant interfaces.

(a) MessageHeader Package

A MessageHeader package 50408 groups together the business informationthat is relevant for sending a business document in a message. Itincludes a MessageHeader entity 50410. This package is not required andmay remain empty.

A MessageHeader entity 50410 groups the business information from theperspective of the sending application to identify the business documentin a message, to provide information about the sender, and to provideany information about the recipient. The MessageHeader entity 50410includes a SenderParty entity 50414 and a RecipientParty entity 50416.There is a 1:c relationship 50418 between the MessageHeader entity 50410and the SenderParty entity 50414. There is a 1:cn relationship 50420between the MessageHeader entity 50410 and the RecipientParty entity50416. The MessageHeader entity 50410 is of type GDT:BusinessDocumentMessageHeader. The MessageHeader entity 50410 caninclude an ID, a ReferenceID, and a CreationDateTime.

The SenderParty entity 50414 is of type GDT:BusinessDocumentMessageHeader-Party. The SenderParty entity 50414 can befilled by the sending application to name a contact person for anyproblems with the message. This is particularly useful if an additionalinfrastructure (such as a marketplace or a tendering platform) islocated between the sender and the recipient. The SenderParty entity50414 is used to transfer the message and can be ignored by thereceiving application. It should be filled by the sender particularly ifthe participating parties are not transferred with the RFQ package50406.

The RecipientParty entity 50416 is of type GDT:BusinessDocument-MessageHeaderParty. The RecipientParty entity 50416 canbe filled by the sending application to name a contact person for anyproblems that occur with the message. This is particularly useful if anadditional infrastructure (such as a marketplace or a tenderingplatform) is located between the sender and the recipient. TheRecipientParty entity 50416 is used to transfer the message and can beignored by the receiving application. It should be filled by the senderparticularly if the participating parties are not transferred with theRFQ package 50406.

(b) RFQ Package

The RFQ package 50406 contains the object in a view required forRFQLegalDocument. In this view, the object RFQ can be structurallyidentical to a view of the RFQ object used in the message data typeRFQMessage with the exception of all or fewer of the variances describedbelow.

The RFQ entity 50414 is of type GDT: RFQInformation and the RFQPartypackage 50446 may include an optional specification of a BuyerParty50448. In an RFQAttachment Package 50436, InternalAttachmentWebAddress50408C is not necessary for a LegalDocument scenario for transmission toDocument Management and may, therefore, not be used (e.g., never used ifno scenario covers it). Similarly, in the RFQ Description Package 50438,the InternalDescription entity 50412C is not necessary for aLegalDocument scenario for transmission to Document Management and may,therefore, not be used. Also, in the RFQItem Package 50440, in theRFQItemAttachment Package 50414B, the InternalAttachmentWebAddress50414C is not necessary for the LegalDocument scenario for transmissionto Document Management, and need not be used.

In any case, the data model for the RFQLegalDocumentMessage message datatype can include an InternalAttachment entity 50408C andLegalDocumentAttachment entity 50410C in the RFQAttachment package50436. Also, the RFQDescription package 50438 can include anInternalDescription entity 50412C.

Similarly, the RFQItemAttachment package 50414B can include theInternalAttachment entity 50414C and LegalDocumentAttachment entity50416C. Also, the RFQItemDescription package 50416B can include anInternalDescription entity 50418C.

The RFQ package 50406 includes a Party package 50422, a Location package50424, a DeliveryInformation package 50426, a PaymentInformation package50428, a ProductInformation package 50430, aBusinessTransactionDocumentReference package 50432, aFollowUpBusinessTransactionDocument package 50434, an Attachment package50436, a Description package 50438, and an Item package 50440. The RFQpackage 50406 also includes an RFQ entity 50444. There is a 1:1relationship 50446 between the RFQLegalDocumentMessage entity 50408 andthe RFQ entity 50444.

The RFQ entity 50444 is a request (or a change to a request) from abuyer to a bidder to submit a quotation for the products (goods orservices) specified in the RFQ. In addition to the buying party and thebidder, additional parties can be involved in the RFQ entity 50444 (seeParty package 50422 below). The delivery location can also be specified(see Location package 50424 below). Delivery and payment terms are alsoagreed upon (see DeliveryInformation package 50426 andPaymentInformation package 50428 below). The RFQ entity 50444 cancontain a reference to a Quote if the bidder has a question or if thebuyer has changed the RFQ entity 50444 (seeBusinessTransactionDocumentReference package 50432 andFollowUpBusinessTransactionDocumentReference package 50434 below). Notesor references to attachments can be specified for the RFQ (seeAttachment package 50436 and Description package 50438 below). The RFQentity 50444 is of type GDT: RFQ.

The RFQ entity 50444 includes an ID, a VersionID, a PostingDateTime, aLastChangeDateTime, a PublishDateTime, a DisplayDateTime, aBiddingStartDateTime, a QuoteSubmissionDateTime, a QuoteOpeningDateTime,a QuoteBindingDateTime, a ContractValidityDateTimePeriod, a Note, anRFQPublicIndicator, a QuoteChangeAllowedIndicator, aQuoteUnplannedItemPermissionCode, a QuotePriceBiddingCondition-Code, aQuoteQuantityBiddingConditionCode, a QuoteItemBiddingConditionCode,RequestedQuoteCurrencyCode, and a ContractTargetAmount. The ID is aunique identifier specified by the buyer for the RFQ. The ID is of typeGDT: BusinessTransactionDocumentID. The VersionID is the uniqueidentifier that the buyer assigns to the version of an RFQ. TheVersionID is of type GDT: VersionID.

The PostingDateTime is the creation date/time of the RFQ at the buyer.The PostingDateTime is of type GDT: DateTime, as are the followingelements in this paragraph. The LastChangeDateTime is the date/time ofthe last change made to the RFQ by the buyer. The PublishDateTime is thedate/time when the RFQ is sent. The DisplayDateTime is the date/time asof which the published RFQ is displayed on a tendering platform. TheBiddingStartDateTime is the date/time as of which quotations can besubmitted. The QuoteSubmissionDateTime is the date/time after theBiddingStartDateTime up to which quotations can be submitted. TheQuoteOpeningDateTime is the date/time when the quotations are opened anddisplayed for the quotation comparison. The QuoteBindingDateTime is thedate/time up to which bidders are bound to the quotations they havesubmitted.

The ContractValidityDateTimePeriod is the validity period of thecontract that is to be assigned using the RFQ. TheContractValidityDateTimePeriod is of type GDT: DateTimePeriod. The Noteis a short description or the title of the RFQ. It is generally used toprovide the user with a simple method for searching for a particularRFQ. The Note is of type GDT: Note. The RFQPublicIndicator specifieswhether the RFQ process is a closed RFQ process with bidders that havebeen explicitly invited or an open RFQ process in which bidders who havenot been explicitly invited can also participate. The RFQPublicIndicatoris of type GDT: BusinessTransactionDocumentPublicIndicator. TheQuoteChangeAllowedIndicator is indicator that the buyer assigns to anRFQ to indicate whether the bidder may change quotes after they havebeen issued. In one implementation, “True” means that quotes may bechanged and “False” means that only quotes that have not been changedare valid. The QuoteChangeAllowedIndicator is of type GDT:AllowedIndicator. The QuoteUnplannedItem-PermissionCode specifieswhether the bidder's quotation is allowed to contain own items withalternative quotations. The QuoteUnplannedItemPermissionCode is of typeGDT: UnplannedItemPermissionCode. The QuotePriceBiddingConditionCodespecifies whether the bidder is allowed to specify pricing information.If the RFQ is used to check the bidder's ability to meet certaintechnical requirements, for example, prices might not be required. TheQuoteQuantityBiddingConditionCode specifies whether the bidder isallowed to enter in the quotation a quantity other than the requestedquantity. The QuoteItemBiddingConditionCode specifies whether the bidderhas to submit a quotation for all items. TheQuotePriceBidding-ConditionCode and QuoteItemBiddingConditionCode are oftype GDT: BiddingConditionCode. The ContractTargetAmount is the targetamount in contractual negotiations. The ContractTargetAmount is of typeGDT: Amount. The RequestedQuoteCurrencyCode is the currency that thebuyer defines in the RFQ. The bidder's quote must be in this currency.The RequestedQuoteCurrencyCode is of type GDT: CurrencyCode.

The ContractTargetAmount in the QuoteNotification is informationprovided to the buyer by the bidder. The ContractTarget-Amount is usedif a contract is to be negotiated and assigned using an RFQ. Differencesbetween the RFQContractTargetAmount and the QuoteContractTargetAmountare allowed and are subject to the business framework of the negotiationprocess as defined by the buyer and bidder. There are no dependenciesbetween how the ContractTargetAmount is used at header and/or itemlevel. The bidder decides which information to supply to the buyer.

(i) RFQ Party Package

The Party package 50422 groups together the business parties that occurin one of the RFQ messages. The party package 50422 includes aBuyerParty entity 50448, a BidderParty entity 50450, aBidderPortalProviderParty entity 50452, a ProductRecipientParty entity50454, a VendorParty entity 50456, a ManufacturerParty entity 50458, anda PayerParty entity 50460. There is a respective 1:c relationship 50462,50464, 50466, 50468, 50470, 50472, and 50474 between the RFQ entity50444 and the BuyerParty entity 50448, the BidderParty entity 50450, theBidderPortalProviderParty entity 50452, the ProductRecipientParty entity50454, the VendorParty entity 50456, the ManufacturerParty entity 50458,and the PayerParty entity 50460.

In one implementation, either the ID or the ID and address can betransferred for each party. If the ID is transferred, the ID addressdefined in the master data is used. If the ID and address aretransferred, the ID identifies the party and the address is deemed to bea document address that is different to the master data address. The IDand address may be sent to avoid misunderstandings. The receivingapplication may implement a suitable optimization strategy to ensurethat the system does not create many identical document addresses.

A default logic is used for the parties: from the header to the itemsand within item hierarchies. Parties specified in the header are usedfor the items for which a corresponding party is not explicitlytransferred and that are directly assigned to the header. In accordancewith the same logic, parties transferred at item level are used forsubitems assigned to the relevant item in an item hierarchy. The defaultlogic is used for the party as a whole, including the contact person. Inone implementation, parts of a party specified at header level or for ahierarchy item cannot be specified in more detail at item level. Thedefault logic may be a simplified version of the transferred message. Asregards logic, parties at header level and for hierarchy items behave asif they have been explicitly transferred for the subitems of themessage. This also means that if changed items are transmitted ratherthan all items, the parties are used for the transmitted items. Changesmade to parties also apply to items relevant for the party in question.

A BuyerParty is a party that buys goods or services. The BuyerPartyentity 50448 is of type GDT: BusinessTransactionParty. The sameBuyerParty entity 50448 is used for all the items in an RFQ in oneimplementation. The BuyerParty is not changed once an RFQ has beencreated. Changes can be made to the BuyerParty/Contact entity and adifferent BuyerParty/Contact entity is permitted for each item. Changescan be made to the address of the BuyerParty, but different addressesare not permitted for each item. If a ProductRecipientParty is notexplicitly specified in an RFQ process, the BuyerParty is also used asthe ProductRecipientParty. If a ProductRecipientParty and ShipToLocationare not explicitly specified in the RFQ process, the BuyerParty addressis also used as the ship-to address. If a PayerParty is not explicitlyspecified in an RFQ process, the BuyerParty is also used as thePayerParty.

The BuyerParty entity 50448 includes an Address entity 50476 and aContact entity 50478. There is a 1:c relationship 50480 between theBuyerParty entity 50448 and the Address entity 50476, and there a 1:crelationship 50482 between the BuyerParty entity 50448 and Contactentities 50478. The Address entity 50476 includes a PersonName entity50484, an Office entity 50486, a PhysicalAddress entity 50488, aGeoCoordinates entity 50490 and a Communication entity 50492. There is arespective 1:c relationship 50494, 50496, 50498, 50400A, and 50402Abetween the Address entity 50476 and the PersonName entity 50484, theOffice entity 50486, the PhysicalAddress entity 50488, theGeoCoordinates entity 50490 and the Communication entity 50492.

The Contact entity 50478 includes an Address entity 50404A. There is a1:c relationship 50405A between the Contact entity 50478 and the Addressentity 50404A. The Address entity 50404A includes a PersonName entity50406A, an Office entity 50408A, a PhysicalAddress entity 50410A, aGeoCoordinates entity 50412A, and a Communication entity 50414A. Thereis a respective 1:c relationship 50416A, 50418A, 50420A, 50422A, and50424A between the Address entity 50404A and the PersonName entity50406A, the Office entity 50408A, the PhysicalAddress entity 50410A, theGeoCoordinates entity 50412A, and the Communication entity 50414A.

The BidderParty is a party that bids for goods or services. TheBidderParty entity 50450 is of type GDT:BusinessTransactionDocumentParty. The same BidderParty entity 50450 maybe used for all the items in an RFQ. The BidderParty entity 50450 is notchanged once an RFQ has been created. Changes can be made to theBidderParty/Contact entity and a different BidderParty/Contact entity ispermitted for each item. Changes can be made to the address of theBidderParty, but different addresses are not permitted for each item. Ifa VendorParty is not explicitly specified in an RFQ process, theBidderParty is also used as the VendorParty. If a VendorParty andShipFromLocation are not explicitly specified in an RFQ process, theaddress of the BidderParty is used as the ship-from address for thematerial items. The BidderParty entity 50450 includes the same elementsas that described above for the BuyerParty entity 50448, as denoted byellipses 50426A.

A BidderPortalProviderParty is a party that runs a portal that bringsbusiness partners together for a business transaction. TheBidderPortalProviderParty entity 50452 is of type GDT:BusinessTransactionDocumentParty. The BidderPortalProviderParty entity50452 is explicitly specified if an RFQ is to be sent to a publictendering platform. The BidderPortalProviderParty entity 50452 includesthe same elements as that described above for the BuyerParty entity50448, as denoted by ellipses 50428A.

The ProductRecipientParty is the party to which goods are delivered orfor whom services are provided. The ProductRecipientParty entity 50454is of type GDT: BusinessTransactionDocumentParty. If a ShipToLocation isnot explicitly specified in an RFQ process, the ProductRecipientPartyentity 50454 address is used as the ship-to address. TheProductRecipientParty is not synonymous with the ShipToLocation andshould be used when the ProductRecipientParty (company or person) isdifferent than the BuyerParty. The ProductRecipientParty entity 50454includes the same elements as that described above for the BuyerPartyentity 50448, as denoted by ellipses 50430A.

A VendorParty is a party that delivers goods or provides services. TheVendorParty entity 50456 is of type GDT:BusinessTransactionDocumentParty. If a ShipFromLocation is notexplicitly specified in an RFQ process, the address of the VendorPartyentity 50456 is used as the ship-from address for the material items.The VendorParty entity 50456 is not the company or person that isresponsible for transporting the goods. The CarrierParty entity isresponsible for this; however, this party is not typically used in theRFQ interfaces. The VendorParty is not synonymous with theShipFromLocation and should be used when the VendorParty (company orperson) is actually different than the BidderParty. The VendorPartyentity 50456 includes the same elements as that described above for theBuyerParty entity 50448, as denoted by ellipses 50432A.

A ManufacturerParty is a party that manufactures goods. TheManufacturerParty entity 50458 is of type GDT:BusinessTransactionDocumentParty. The ManufacturerParty entity 50458 canbe used for material items. With regard to the ManufacturerParty entity50458, the default logic (from header to item to subitems) is used formaterial items; for other items, the ManufacturerParty entity 50458 isignored. The ManufacturerParty entity 50458 can be used to uniquelydefine the context of a ManufacturerProductID entity. TheManufacturerParty entity 50458 includes the same elements as thatdescribed above for the BuyerParty entity 50448, as denoted by ellipses50434A.

A PayerParty is a party that pays for goods or services. The PayerPartyentity 50460 is of type GDT: BusinessTransactionDocumentParty. ThePayerParty is used for the ContractPayer. The ContractPayer is the partypaying for contractual negotiations. The PayerParty entity 50460includes the same elements as that described above for the BuyerPartyentity 50448, as denoted by ellipses 50436A.

(ii) RFQ Location Package

A Location package 50424 groups together the locations that can occur inone of the RFQ messages. The Location package 50424 includes aShipToLocation entity 50438A. There is a 1:c relationship 50440A betweenthe RFQ entity 50444 and the ShipToLocation entity 50438A. TheShipToLocation entity 50438A includes an Address entity 50442A. There isa 1:c relationship 50444A between the ShipToLocation entity 50438A andthe Address entity 50442A.

A similar default logic to that used for Parties is also used forlocations. In one implementation, either the ID or the address, or bothcan be transferred to each location. If the ID is transferred, the IDaddress defined in the master data is used. If the address istransferred, it is this address that is used (if necessary, a locationis assigned at the address recipient). If the ID and address aretransferred, the ID identifies the location and the address is deemed tobe a document address that is different to the master data address. TheID and address may be sent to avoid misunderstandings. The receivingapplication should implement a suitable optimization strategy to ensurethat the system does not create many identical document addresses.

The ShipToLocation is the location to which goods are to be delivered orwhere services are to be provided. The ShipToLocation entity 50438A isof type GDT: BusinessTransaction-DocumentLocation.

The Address entity 50442A includes a PersonName entity 50446A, an Officeentity 50448A, a PhysicalAddress entity 50450A, a GeoCoordinates entity50452A, and a Communication entity 50454A. There is a respective 1:crelationship 50456A, 50458A, 50460A, 50462A, and 50464A between theAddress entity 50442A and the PersonName entity 50446A, the Officeentity 50448A, the PhysicalAddress entity 50450A, the GeoCoordinatesentity 50452A, and the Communication entity 50454A.

(iii) RFQ Delivery Information Package

A DeliveryInformation package 50426 groups together the informationabout a required delivery in an RFQ process. The DeliveryInformationpackage 50426 includes a DeliveryTerms entity 50466A. There is a 1:crelationship 50468A between the RFQ entity 50444 and the DeliveryTermsentity 50466A.

The DeliveryTerms is the condition and agreement that is valid forexecuting the delivery and transporting the tendered goods and for thenecessary services and activities. The DeliveryTerms entity 50466A istype GDT: DeliveryTerms. It includes an Incoterms entity 50470A. Thereis a 1:c relationship 50472A between the DeliveryTerrns entity 50466Aand the Incoterms entity 50470A. The Incoterms is allowed to be used formaterial items. The default logic takes the Incoterms entity intoaccount for material items. For other items, Incoterms may be ignored.

(iv) RFQ Payment Information Package

A PaymentInformation package 50428 groups together the paymentinformation in an RFQ process. The PaymentInformation package 50428includes a CashDiscountTerms entity 50474A and a PaymentForm entity50476A. There is a 1:c relationship 50478A between the RFQ entity 50444and the CashDiscountTerms entity 50474A, and a 1:c relationship 50480Abetween the RFQ entity 50444 and the PaymentForm entity 50476A.

The CashDiscountTerms is the term of payment in an RFQ process. TheCashDiscountTerms entity 50474A is type GDT: CashDiscountTerms.

A PaymentForm is the payment form together with the data required. ThePaymentForm entity 50476A includes a PaymentFormCode, which is the codedrepresentation of the payment form. The PaymentFormCode is of type GDT:PaymentFormCode.

(v) RFQ Product Information Package

The ProductInformation package 50430 groups together the productcategory. The ProductInformation package 50430 includes aProductCategory entity 50482A. There is a 1:c relationship 50484Abetween the RFQ entity 50444 and the ProductCategory entity 50482A.

The ProductCategory includes the details about a product category asgenerally understood from a commercial point of view in businesstransaction documents. The ProductCategory entity 50482A includesdetails for identifying the product category using an internal ID, astandard ID, and IDs assigned by involved parties. The ProductCategoryentity 50482A is of type GDT:BusinessTransactionDocumentProductCategory. The product category atheader level can be used to classify the RFQ and provide the bidderswith an initial indication of what is involved in the RFQ. The productcategory can differ between the buyer and seller.

(vi) RFQ Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 50432 groups togetherbusiness document references that can occur in one of the RFQ messages.The BusinessTransactionDocumentReference package 50432 includes aQuoteReference entity 50486A. There is a 1:c relationship 50488A betweenthe RFQ entity 50444 and the QuoteReference entity 50486A.

A QuoteReference is a reference to a quotation. The QuoteReferenceentity 50486A is of type GDT: BusinessTransactionDocument-Reference.

In one implementation, a QuoteReference can reference one quotation,that is, one ID is permissible. As far as the referenced quotation isconcerned, there are no conflicts with a QuoteReference at item level.If a reference is used at both header and item level, it refers to one(the same) quotation.

The reference to a quotation is required at both header and item level,since RFQs do not always have item data. The QuoteReference is used whenquestions and answers are exchanged between the bidder and buyer and ifthe RFQ is changed.

(vii) RFQ Follow-Up Business Transaction Document Package

A FollowUpBusinessTransactionDocument package 50434 groups together theinformation about which business transaction documents the buyer isexpecting as a result of the RFQ process. TheFollowUpBusinessTransactionDocument entity 50434 includes aFollowUpPurchaseOrder entity 50490A and a FollowUpPurchaseContractentity 50492A. There is a 1:c relationship 50494A between the RFQ entity50444 and the FollowUpPurchaseOrder entity 50490A, and a 1:crelationship 50496A between the RFQ entity 50444 and theFollowUpPurchaseContract entity 50492A. In theFollowUpBusinessTransactionDocument package 50434, the buyer providesthe bidders with information about whether the RFQ is to result in acontract or a purchase order. However, the buyer can also leave thisopen by not providing any information.

The FollowUpPurchaseOrder provides information about whether the buyerexpects a purchase order as a result of the RFQ process. TheFollowUpPurchaseOrder entity 50490A includes a RequirementCode, which isa coded representation of information about whether the buyer expects apurchase order as a result of the RFQ process. The RequirementCode is oftype GDT: FollowUpBusinessTransactionDocumentRequirementCode. TheRequirementCode entity can be changed by the buyer.

The FollowUpPurchaseContract provides information about whether thebuyer expects a contract as the result of the RFQ process. TheFollowUpPurchaseContract entity 50492A includes a RequirementCode, whichis a coded representation of information about whether the buyer expectsa contract as a result of the RFQ process. The RequirementCode is oftype GDT: FollowUpBusinessTransactionDocumentRequirementCode. TheRequirementCode can be changed by the buyer.

(viii) RFQ Attachment Package

The Attachment package 50436 groups together the attachment informationregarding the RFQ. The Attachment package 50436 includes an Attachmententity 50498A. The Attachment is any document that refers to the RFQ.The Attachment entity 50498A is of type GDT: Attachment. There is a 1:crelationship 50400B between the RFQ entity 50444 and the Attachmententity 50498A.

(ix) RFQ Description Package

The Description package 50438 groups together the texts regarding theRFQ. The Description package 50438 includes a Description entity 50402B.The Description is a natural-language text regarding the RFQ, which isvisible to parties. The Description entity 50402B is of type GDT:Description. There is a 1:c relationship 50403B between the RFQ entity50444 and the Description entity 50402B.

The Description can be used for textual information about thetransferred RFQ and not just the current message. An example of thiswould be information stating that the employee responsible in Purchasingwill be on vacation as of a specific date, and indicating the name andtelephone number of a substitute as of this date. The Description canalso be used for communication between the buyer and bidder in order toprocess queries, for example. In the case of a public tenderingplatform, measures are taken to ensure that individual communicationswith individual bidders, which contain explanatory information about theRFQ, are also made available to other RFQ participants. This is ensuredby sending a copy of the description to the tendering platform, where itis published.

(x) RFQ Item Package

An RFQItem package 50440 includes a ProductInformation package 50404B, aParty package 50406B, a Location package 50408B, a DeliveryInformationpackage 50410B, a BusinessTransactionDocumentReference package 50412B,an Attachment package 50414B, a Description package 50416B, and aScheduleLine package 50418B. The Item package 50440 also includes anRFQItem entity 50420B. There is a 1:cn relationship 50422B between theRFQ entity 50444 and the RFQItem entity 50420B. RFQItem entities arearranged hierarchically using a Hierarchy Relationship 50424B. TheHierarchy Relationship 50424B is the relationship between a sub-item anda higher-level parent item in an item hierarchy. There is a 1:cnrelationship 50426B between the RFQItem entity 50420B and itssubordinate entities, and there is a 1:c relationship 50428B between theRFQItem entity 50420B and its superordinate entities.

The RFQItem specifies a product tendered by an RFQ with additionalinformation on such a product. The RFQItem entity 50420B includesdetailed information about a particular product (see ProductInformationpackage 50404B). The quantity of the product and (delivery) dates/timesare specified in the schedule line. For the RFQItem (compared to theinformation of the RFQ), deviating parties, locations, and deliveryterms can be defined (see Party package 50406B, Location package 50408B,and DeliveryInformation package 50410B). The RFQItem can containreferences to other business documents that are relevant for the item(see BusinessTransactionDocumentReference package 50412B). Notes orreferences to attachments can also be specified for the RFQItem (seeAttachment package 50414B and Description package 50416B). The RFQItementity 50420B is of type GDT: RFQItem.

The RFQItem entity 50420B includes an ID and a ContractTargetAmount. TheID is a unique identifier specified by the buyer for an item within anRFQ. The ID is of type GDT: BusinessTransactionDocumentItemID. TheContractTargetAmount is the target amount in contractual negotiations.The ContractTargetAmount is of type GDT: Amount.

A HierarchyRelationship 50424B includes a ParentItemBuyerID, aParentItemVendorID, and a TypeCode. The ParentItemBuyerID is thereference to a parent item with the item number assigned by the buyer.The ParentItemBuyerID is of type GDT: BusinessTransactionDocumentItemID.The ParentItemVendorID is the reference to a parent item with the itemnumber assigned by the seller. The ParentItemVendorID is of type GDT:BusinessTransactionDocumentItemID. The TypeCode represents thehierarchical relationship between the subitem and its higher-levelparent item. The TypeCode is of type GDT:BusinessTransactionDocumentItemHierarchyRelationshipTypeCode. TheParentItemBuyerID, ParentItemVendorID and TypeCode are generally notchanged once an item has been created. Either the ParentItemBuyerID orthe ParentItemVendorID is specified.

(a) RFQ Item Product Information Package

A ProductInformation package 50404B groups together the product and theproduct category. The ProductInformation package 50404B includes aProduct entity 50430B and a ProductCategory entity 50432B. There is a1:c relationship 50434B between the Item entity 50420B and the Productentity 50430B, and a 1:c relationship 50436B between the Item entity50420B and the ProductCategory entity 50432B.

A Product includes the details about a product as generally understoodfrom a commercial point of view in business documents. These are thedetails for identifying a product and product type, and the descriptionof the product. The Product entity 50430B is of type GDT:BusinessTransactionDocumentProduct.

A ProductCategory includes the details about a product category asgenerally understood from a commercial point of view in businesstransaction documents. The ProductCategory entity 50432B includesdetails for identifying the product category using an internal ID, astandard ID, and IDs assigned by involved parties. The ProductCategoryentity 50432B is of type GDT:BusinessTransaction-DocumentProductCategory. The product category isderived directly from the product if a product number is specified forthe product. It can differ for the buyer and seller if they haveclassified the same product differently. This is allowed and should betolerated by the systems involved. The product category at item levelcan differ from the product category at header level.

(b) RFQ Item Party Package

The Party package 50406B groups together the business parties that canoccur in one of the RFQ messages at the item level and represents partof the Party package 50422 at the header level. The party package 50406Bincludes a BuyerParty entity 50438B, a BidderParty entity 50440B, aProductRecipientParty entity 50442B, a VendorParty entity 50444B, and aManufacturerParty entity 50446B. There is a respective 1:c relationship50448B, 50450B, 50452B, 50454B, and 50456B between the Item entity50420B and the BuyerParty entity 50438B, the BidderParty entity 50440B,the ProductRecipientParty entity 50442B, the VendorParty entity 50444B,and the ManufacturerParty entity 50446B. Each of the BuyerParty entity50438B, the BidderParty entity 50440B, the ProductRecipientParty entity50442B, the VendorParty entity 50444B, and the ManufacturerParty entity50446B includes the same elements as that described above for theBuyerParty entity 50448 as denoted by ellipses 50458B, 50460B, 50462B,50464B, and 50466B.

(c) RFQ Item Location Package

Similar to the Location package 50424 at the header level, the Locationpackage 50408B at the item level includes a ShipToLocation entity50468B. There is a 1:c relationship 50470B between the Item entity50420B and the ShipToLocation entity 50468B. The ShipToLocation entity50468B includes the same elements as that described above for theShipToLocation entity 50438A as denoted by ellipses 50472B.

(d) RFQ Item Delivery Information Package

Similar to the DeliveryInformation package 50426 at the header level,the DeliveryTerms package 50410B at the item level includes aDeliveryTerms entity 50474B. There is a 1:c relationship 50476B betweenthe Item entity 50420B and the DeliveryTerms entity 50474B. TheDeliveryTerms contains a MaximumLeadTimeDuration, which is the maximumlead time from the time of the order to the receipt of the delivery.This duration can be agreed in RFQs or contractual negotiations andrepresents the basis (that is binding) for the calculation of thereceived delivery date for an order date. The MaximumLeadTimeDuration isof type GDT: Duration.

The DeliveryTerms entity 50474B includes an Incoterms entity 50478B.There is a 1:c relationship 50480B between the DeliveryTerms entity50474B and the Incoterms entity 50478B.

(e) RFQ Item Business Transaction Document Reference Package

The BusinessTransactionDocumentReference package 50412B groups togetherthe business document references that can occur in one of the RFQmessages. The BusinessTransaction-DocumentReference package 50412Bincludes a QuoteReference entity 50482B, a PurchaseContractReferenceentity 50484B, and a BuyerProductCatalogueReference entity 50486B. Thereis a respective 1:c relationship 50488B, 50490B, and 50492B between theItem entity 50420B and the QuoteReference entity 50482B, thePurchaseContractReference entity 50484B, and theBuyerProductCatalogueReference entity 50486B.

A QuoteReference is a reference to the quotation or the item within thequotation. The QuoteReference entity 50482B is of type GDT:BusinessTransactionDocumentReference. In one implementation, aQuoteReference entity 50482B can reference one item, that is, one ItemIDis permissible. As far as the referenced quotation is concerned, thereare no conflicts with a QuoteReference entity 50486A at the headerlevel. If a quotation reference is maintained at both the header anditem levels, it refers to one (the same) quotation.

The PurchaseContractReference is a reference to a purchase contract oritem in a purchase contract. The PurchaseContractReference entity 50484Bis of type GDT: BusinessTransaction-DocumentReference. In oneimplementation, a PurchaseContractReference entity 50484B can referenceone item, that is, one ItemID is permissible. Unless otherwise agreed,the seller is responsible for determining the correctPurchaseContractReference for a specified SellerContractReference.

A BuyerProductCatalogueReference is a reference to the buyer's productcatalog or an item within the buyer's product catalog. TheBuyerProductCatalogueReference entity 50486B is of type GDT:CatalogueReference. In one implementation, aBuyerProductCatalogueReference entity 50486B can reference one item,that is, one ItemID is permissible. The BuyerProductCatalogueReferenceentity 50486B should be filled if an RFQItem entity 50420B refers to acatalog whose number and item numbers were assigned by the buyer. In theRFQ process, the BuyerProductCatalogueReference entity 50486B can beused as a substitute product number if the product is defined in acatalog rather than having its own master record.

(f) RFQ Item Attachment Package

The RFQItemAttachment package 50414B includes an Attachment entity50494B. There is a 1:c relationship 50496B between the Item entity50420B and the Attachment entity 50494B.

(g) RFQ Item Description Package

The RFQItemDescription package 50416B includes a Description entity50498B. There is a 1:c relationship 50400C between the Item entity50420B and the Description entity 50498B.

(h) RFQ Item Schedule Line Package

The ScheduleLine package 50418B groups together the quantity and dateinformation about an RFQItem. The ScheduleLine package 50418B includes aScheduleLine entity 50402C. There is a 1:c relationship 50404C betweenthe Item entity 50420B and the ScheduleLine entity 50402C.

A ScheduleLine is a line containing the quantity and date of theperformance schedule requested by the buyer in an RFQ. The ScheduleLineentity 50402C is of type GDT: RFQItemScheduleLine. The ScheduleLineentity 50402C includes a DeliveryPeriod entity 50406C. There is a 1:1relationship 50408C between the ScheduleLine entity 50402C and theDeliveryPeriod entity 50406C.

The ScheduleLine entity 50402C includes an ID, a DeliveryPeriod, and aQuantity. The ID is the ScheduleLine number assigned by the procurementsystem. The ID is of type GDT:BusinessTransactionDocumentItemScheduleLineID. The DeliveryPeriod is theperiod in which the buyer expects a product to be delivered or serviceprovided. The DeliveryPeriod is of type GDT: DateTimePeriod. TheQuantity is the RFQ quantity or the target quantity in contractualnegotiations. The Quantity is of type GDT: Quantity.

In one implementation, one ScheduleLine is allowed for each RFQ item.When used more than once, the information in the ScheduleLine andDeliveryInformation is consistent (for example, if used twice, thedelivery date is identical in both cases). The ID is optional; aprocurement system does not have to number the ScheduleLine entities.

(4) Element Structure of the RFQ Legal Document Message

The message data type element structure for the RFQ Legal Documentmessage is depicted in FIG. 505A. The element structure is similar tothe data model, but provides additional information regarding thedetails of the interface. The element structure identifies the differentpackages 50500 in the interface, and represents the entities at variouslevels within the interface. As depicted in FIG. 505A, the interface forRFQLegalDocumentMessage includes five levels 50502D, 50504D, 50506D,50508D, and 50510D. The outermost package of this interface is aRFQLegalDocumentMessage package 50500, which includes anRFQLegalDocumentMessage entity 50501 at the first level 50502D. TheRFQLegalDocumentMessage entity 50501 is of a type MDT 50502“RFQLegalDocumentMessage” 50503.

The RFQLegalDocumentMessage package 50500 includes an RFQ package 50504.The RFQ package 50504 includes an RFQ entity 50505 at the second level50504D, a Party package 50577, a Location package 50530A, aDeliveryInformation package 50547A, a PaymentInformation package 50556A,a ProductInformation package 50577A, aFollowUpBusinessTransactionDocument package 50590A, an Attachmentpackage 50503B, a Description package 50516B, and an Item package50525B. The RFQ entity 50505 is of a type AGDT 50507 “RFQInformation”50508. There is one 50506 RFQ entity 50505 for each RFQ package 50504.The RFQ entity 50505 includes an ID entity 50509, a PostingDateTimeentity 50513, a LastChangeDateTime entity 50517, a PublishDateTimeentity 50521, a DisplayDateTime entity 50525, a BiddingStartDateTimeentity 50529, a QuoteSubmissionDateTime entity 50533, aQuoteOpeningDateTime entity 50537, a QuoteBindingDateTime entity 50541,a ContractValidityPeriod entity 50545, a Note entity 50549, anRFQPublicIndicator entity 50553, a QuoteUnplannedItemPermissionCodeentity 50557, a QuotePriceBiddingConditionCode entity 50561, aQuoteQuantityBiddingConditionCode entity 50565, aQuoteItemBiddingConditionCode entity 50569, and a ContractTargetAmountentity 50573 at the third level 50506D.

The ID entity 50509 is of a type GDT 50511“BusinessTransactionDocumentID” 50512. There is one 50510 ID entity50509 for an RFQ entity 50505. The PostingDateTime entity 50513 is of atype GDT 50515 “DateTime” 50516. There is zero or one 50514PostingDateTime entity 50513 for an RFQ entity 50505. TheLastChangeDateTime entity 50517 is of a type GDT 50519 “DateTime” 50520.There is zero or one 50518 LastChangeDateTime entity 50517 for an RFQentity 50505. The PublishDateTime entity 50521 is of a type GDT 50523“DateTime” 50524. There is zero or one 50522 PublishDateTime entity50521 for an RFQ entity 50505. The DisplayDateTime entity 50525 is of atype GDT 50527 “DateTime” 50528. There is zero or one 50526DisplayDateTime entity 50525 for an RFQ entity 50505. TheBiddingStartDateTime entity 50529 is of a type GDT 50531 “DateTime”50532. There is zero or one 50530 BiddingStartDateTime entity 50529 foran RFQ entity 50505. The QuoteSubmissionDateTime entity 50533 is of atype GDT 50535 “DateTime” 50536. There is zero or one 50534QuoteSubmissionDateTime entity 50533 for an RFQ entity 50505. TheQuoteOpeningDateTime entity 50537 is of a type GDT 50539 “DateTime”50540. There is zero or one 50538 QuoteOpeningDateTime entity 50537 foran RFQ entity 50505. The QuoteBindingDateTime entity 50541 is of a typeGDT 50543 “DateTime” 50544. There is zero or one 50542QuoteBindingDateTime entity 50541 for an RFQ entity 50505. TheContractValidityPeriod entity 50545 is of a type GDT 50547“DateTimePeriod” 50548. There is zero or one 50546ContractValidityPeriod entity 50545 for an RFQ entity 50505. The Noteentity 50549 is of a type GDT 50551 “Note” 50552. There is zero or one50550 Note entity 50549 for an RFQ entity 50505. The RFQPublicIndicatorentity 50553 is of a type GDT 50555“BusinessTransactionDocumentPublicIndicator” 50556. There is zero or one50554 RFQPublicIndicator entity 50553 for an RFQ entity 50505. TheQuoteUnplannedItemPermissionCode entity 50557 is of a type GDT 50559“UnplannedItemPermissionCode” 50560. There is zero or one 50558QuoteUnplannedItemPermissionCode entity 50557 for an RFQ entity 50505.The QuotePriceBiddingConditionCode entity 50561 is of a type GDT 50563“BiddingConditionCode” 50564. There is zero or one 50562QuotePriceBiddingConditionCode entity 50561 for an RFQ entity 50505. TheQuoteQuantityBiddingConditionCode entity 50565 is of a type GDT 50567“BiddingConditionCode” 50568. There is zero or one 50566QuoteQuantityBiddingConditionCode entity 50565 for an RFQ entity 50505.The QuoteItemBiddingConditionCode entity 50569 is of a type GDT 50571“BiddingConditionCode” 50572. There is zero or one 50570QuoteItemBiddingConditionCode entity 50569 for an RFQ entity 50505. TheContractTargetAmount entity 50573 is of a type GDT 50575 “Amount” 50576.There is zero or one 50574 ContractTargetAmount entity 50573 for an RFQentity 50505.

The Party package 50577 includes a BuyerParty entity 50578, aBidderParty entity 50506A, a BidderPortalProviderParty entity 50510A, aProductRecipientParty entity 50514A, a VendorParty entity 50518A, aManufacturerParty entity 50522A, and a PayerParty entity 50526A at thethird level 50506D. The BuyerParty entity 50578 is of a type AGDT 50580“BusinessTransactionDocumentParty” 50581. There is zero or one 50579BuyerParty entity 50578 for each Party package 50577. The BuyerPartyentity 50578 includes a StandardID entity 50582, an InternalID entity50586, an Address entity 50590, and a ContactPerson entity 50594 at thefourth level 50508D. The StandardID entity 50582 is of a type CDT 50584“PartyStandardID” 50585. There is any number of 50583 StandardID entity50582 for a BuyerParty entity 50578. The InternalID entity 50586 is of atype CDT 50588 “PartyInternalID” 50589. There is zero or one 50587InternalID entity 50586 for a BuyerParty entity 50578. The Addressentity 50590 is of a type AGDT 50592 “Address” 50593. There is zero orone 50591 Address entity 50590 for a BuyerParty entity 50578.

The ContactPerson entity 50594 is of a type AGDT 50596 “ContactPerson”50597. There is zero or one 50595 ContactPerson entity 50594 for aBuyerParty entity 50578. The ContactPerson entity 50594 includes anInternalID entity 50598 and an Address entity 50502A at the fifth level50510D. The InternalID entity 50598 is of a type CDT 50500A“ContactPersonID” 50501A. There is zero or one 50599 InternalID entity50598 for a ContactPerson entity 50594. The Address entity 50502A is ofa type AGDT 50504A “Address” 50505A. There is zero or one 50503A Addressentity 50502A for a ContactPerson entity 50594.

The BidderParty entity 50506A is of a type AGDT 50508A“BusinessTransactionDocumentParty” 50509A. There is zero or one 50507ABidderParty entity 50506A for each Party package 50577. TheBidderPortalProviderParty entity 50510A is of a type AGDT 50512A“BusinessTransactionDocumentParty” 50513A. There is zero or one 50511 ABidderPortalProviderParty entity 50510A for each Party package 50577.The ProductRecipientParty entity 50514A is of a type AGDT 50516A“BusinessTransactionDocumentParty” 50517A. There is zero or one 50515AProductRecipientParty entity 50514A for each Party package 50577. TheVendorParty entity 50518A is of a type AGDT 50520A“BusinessTransactionDocumentParty” 50521A. There is zero or one 50519AVendorParty entity 50518A for each Party package 50577. TheManufacturerParty entity 50522A is of a type AGDT 50524A“BusinessTransactionDocumentParty” 50525A. There is zero or one 50523AManufacturerParty entity 50522A for each Party package 50577. ThePayerParty entity 50526A is of a type AGDT 50528A“BusinessTransactionDocumentParty” 50529A. There is zero or one 50527APayerParty entity 50526A for each Party package 50577.

The Location package 50530A includes a ShipToLocation entity 5053 1A atthe third level 50506D. The ShipToLocation entity 50531A is of a typeAGDT 50533A “BusinessTransactionDocumentLocation” 50534A. There is zeroor one 50532A ShipToLocation entity 50531 A for each Location package50530A. The ShipToLocation entity 5053 1A includes a StandardID entity50535A, an InternalID entity 50539A, and an Address entity 50543A at thefourth level 50508D. The StandardID entity 50535A is of a type CDT50537A “LocationStandardID” 50538A. There is any number of 50536AStandardID entity 50535A for a ShipToLocation entity 50531A. TheInternalID entity 50539A is of a type CDT 50541A “LocationInternalID”50542A. There is zero or one 50540A InternalID entity 50539A for aShipToLocation entity 50531A. The Address entity 50543A is of a typeAGDT 50545A “Address” 50546A. There is zero or one 50544A Address entity50543A for a ShipToLocation entity 50531A.

The DeliveryInformation package 50547A includes a DeliveryTerms entity50548A at the third level 50506D. The DeliveryTerms entity 50548A is ofa type AGDT 50550A “DeliveryTerms” 50551A. There is zero or one 50549ADeliveryTerms entity 50548A for each DeliveryInformation package 50547A.The DeliveryTerms entity 50548A includes an Incoterms entity 50552A atthe fourth level 50508D. The Incoterms entity 50552A is of a type GDT50554A “Incoterms” 50555A. There is zero or one 50553A Incoterms entity50552A for a DeliveryTerms entity 50548A.

The PaymentInformation package 50556A includes a CashDiscountTermsentity 50557A and a PaymentForm entity 50571A at the third level 50506D.The CashDiscountTerms entity 50557A is of a type AGDT 50559A“CashDiscountTerms” 50560A. There is zero or one 50558ACashDiscountTerms entity 50557A for each PaymentInformation package50556A. The CashDiscountTerms entity 50557A includes aMaximumCashDiscount entity 50561A, a NormalCashDiscount entity 50565A,and a FullPaymentDueDaysValue entity 50569A at the fourth level 50508D.The MaximumCashDiscount entity 50561A is of a type GDT 50563A“CashDiscount” 50564A. There is zero or one 50562A MaximumCashDiscountentity 50561A for a CashDiscountTerms entity 50557A. TheNormalCashDiscount entity 50565A is of a type GDT 50567A “CashDiscount”50568A. There is zero or one 50566A NormalCashDiscount entity 50565A fora CashDiscountTerms entity 50557A. There is zero or one 50570AFullPaymentDueDaysValue entity 50569A for a CashDiscountTerms entity50557A.

The PaymentForm entity 50571A includes a Code entity 50573A at thefourth level 50508D. There is zero or one 50572A PaymentForm entity50571A for each PaymentInformation package 50556A. The Code entity50573A is of a type GDT 50575A “PaymentFormCode” 50576A. There is one50574A Code entity 50573A for a PaymentForm entity 50571A.

The ProductInformation package 50577A includes a ProductCategory entity50578A at the third level 50506D. The ProductCategory entity 50578A isof a type GDT 50580A “BusinessTransactionDocumentProductCategory”50581A. There is zero or one 50579A ProductCategory entity 50578A foreach ProductInformation package 50577A.The ProductCategory entity 50578Aincludes a StandardID entity 50582A and an InternalID entity 50586A atthe fourth level 50508D. The StandardID entity 50582A is of a type CDT50584A “ProductCategoryStandardID” 50585A. There is any number of 50583AStandardID entity 50582A for a ProductCategory entity 50578A. TheInternalID entity 50586A is of a type CDT 50588A“ProductCategoryInternalID” 50589A. There is zero or one 50587AInternalID entity 50586A for a ProductCategory entity 50578A.

The FollowUpBusinessTransactionDocument package 50590A includes aFollowUpPurchaseOrder entity 50591 A and a FollowUpPurchaseContractentity 50597A at the third level 50506D. The FollowUpPurchaseOrderentity 50591A includes a RequirementCode entity 50593A at the fourthlevel 50508D. There is zero or one 50592A FollowUpPurchaseOrder entity50591 A for each FollowUpBusinessTransactionDocument package 50590A. TheRequirementCode entity 50593A is of a type GDT 50595A“FollowUpBusinessTransactionDocumentRequirementCode” 50596A. There isone 50594A RequirementCode entity 50593A for a FollowUpPurchaseOrderentity 50591A. The FollowUpPurchaseContract entity 50597A includes aRequirementCode entity 50599A at the fourth level 50508D. There is zeroor one 50598A FollowUpPurchaseContract entity 50597A for eachFollowUpBusinessTransactionDocument package 50590A. The RequirementCodeentity 50599A is of a type GDT 50501B“FollowUpBusinessTransactionDocumentRequirementCode” 50502B. There isone 50500B RequirementCode entity 50599A for a FollowUpPurchaseContractentity 50597A.

The Attachment package 50503B includes an AttachmentWebAddress entity50504B, an InternalAttachmentWebAddress entity 50508B, and aLegalDocumentAttachment entity 50512B at the third level 50506D. TheAttachmentWebAddress entity 50504B is of a type GDT 50506B“AttachmentWebAddress” 50507B. There is any number of 50505BAttachmentWebAddress entity 50504B for each Attachment package 50503B.The InternalAttachmentWebAddress entity 50508B is of a type GDT 50510B“AttachmentWebAddress” 50511B. There is any number of 50509BInternalAttachmentWebAddress entity 50508B for each Attachment package50503B. The LegalDocumentAttachment entity 50512B is of a type GDT50514B “Attachment” 50515B. There is any number of 50513BLegalDocumentAttachment entity 50512B for each Attachment package50503B.

The Description package 50516B includes a Description entity 50517B andan InternalDescription entity 50521B at the third level 50506D. TheDescription entity 50517B is of a type GDT 50519B “Description” 50520B.There is zero or one 50518B Description entity 50517B for eachDescription package 50516B. The InternalDescription entity 50521B is ofa type GDT 50523B “Description” 50524B. There is zero or one 50522BInternalDescription entity 50521B for each Description package 50516B.

The Item package 50525B includes an Item entity 50526B at the thirdlevel 50506D, a ProductInformation package 50548B, a Party package50577B, a Location package 50598B, a DeliveryInformation package 50519C,a BusinessTransactionDocumentReference package 50532C, an Attachmentpackage 50557C, a Description package 50566C, and a ScheduleLine package50575C.

The Item entity 50526B is of a type AGDT 50528B “RFQInformationItem”50529B. There is any number of 50527B Item entity 50526B for each Itempackage 50525B. The Item entity 50526B includes an ID entity 50530B, aContractTargetAmount entity 50534B, and a HierarchyRelationship entity50538B at the fourth level 50508D. The ID entity 50530B is of a type GDT50532B “BusinessTransactionDocumentItemID” 50533B. There is one 50531BID entity 50530B for an Item entity 50526B. The ContractTargetAmountentity 50534B is of a type GDT 50536B “Amount” 50537B. There is zero orone 50535B ContractTargetAmount entity 50534B for an Item entity 50526B.The HierarchyRelationship entity 50538B includes a ParentItemID entity50540B and a TypeCode entity 50544B at the fifth level 50510D. There iszero or one 50539B HierarchyRelationship entity 50538B for an Itementity 50526B. The ParentItemID entity 50540B is of a type GDT 50542B“BusinessTransactionDocumentItemID” 50543B. There is one 50541BParentItemID entity 50540B for a HierarchyRelationship entity 50538B.The TypeCode entity 50544B is of a type GDT 50546B“BusinessTransactionDocumentItemHierarchyRelationshipTypeCode” 50547B.There is one 50545B TypeCode entity 50544B for a HierarchyRelationshipentity 50538B.

The ProductInformation package 50548B includes a Product entity 50549Band a ProductCategory entity 50569B at the fourth level 50508D. TheProduct entity 50549B is of a type GDT 50551B“BusinessTransactionDocumentProduct” 50552B. There is zero or one 50550BProduct entity 50549B for each ProductInformation package 50548B. TheProduct entity 50549B includes a StandardID entity 50553B, aManufacturerID entity 50557B, a TypeCode entity 50561B, and a Noteentity 50565B at the fifth level 50510D. The StandardID entity 50553B isof a type CDT 50555B “ProductStandardID” 50556B. There is any number of50554B StandardID entity 50553B for a Product entity 50549B. TheManufacturerID entity 50557B is of a type CDT 50559B “ProductPartyID”50560B. There is zero or one 50558B ManufacturerID entity 50557B for aProduct entity 50549B. The TypeCode entity 50561B is of a type GDT50563B “ProductTypeCode” 50564B. There is zero or one 50562B TypeCodeentity 50561B for a Product entity 50549B. The Note entity 50565B is ofa type GDT 50567B “Note” 50568B. There is zero or one 50566B Note entity50565B for a Product entity 50549B.

The ProductCategory entity 50569B is of a type GDT 50571B“BusinessTransactionDocumentProduct” 50572B. There is zero or one 50570BProductCategory entity 50569B for each ProductInformation package50548B. The ProductCategory entity 50569B includes a StandardID entity50573B. The StandardID entity 50573B is of a type CDT 50575B“ProductCategoryStandardID” 50576B. There is any number of 50574BStandardID entity 50573B for a ProductCategory entity 50569B.

The Party package 50577B includes a BuyerParty entity 50578B, aBidderParty entity 50582B, a ProductRecipientParty entity 50586B, aVendorParty entity 50590B, and a ManufacturerParty entity 50594B at thefourth level 50508D. The BuyerParty entity 50578B is of a type AGDT50580B “BusinessTransactionDocumentParty” 50581B. There is zero or one50579B BuyerParty entity 50578B for each Party package 50577B. TheBidderParty entity 50582B is of a type AGDT 50584B“BusinessTransactionDocumentParty” 50585B. There is zero or one 50583BBidderParty entity 50582B for each Party package 50577B. TheProductRecipientParty entity 50586B is of a type AGDT 50588B“BusinessTransactionDocumentParty” 50589B. There is zero or one 50587BProductRecipientParty entity 50586B for each Party package 50577B. TheVendorParty entity 50590B is of a type AGDT 50592B“BusinessTransactionDocumentParty” 50593B. There is zero or one 50591BVendorParty entity 50590B for each Party package 50577B. TheManufacturerParty entity 50594B is of a type AGDT 50596B“BusinessTransactionDocumentParty” 50597B. There is zero or one 50595BManufacturerParty entity 50594B for each Party package 50577B.

The Location package 50598B includes a ShipToLocation entity 50599B atthe fourth level 50508D. The ShipToLocation entity 50599B is of a typeAGDT 50501C “BusinessTransactionDocumentLocation” 50502C. There is zeroor one 50500C ShipToLocation entity 50599B for each Location package50598B. The ShipToLocation entity 50599B includes a StandardID entity50503C, a BuyerID entity 50507C, a BidderID entity 50511C, and anAddress entity 50515C at the fifth level 50510D. The StandardID entity50503C is of a type CDT 50505C “LocationStandardID” 50506C. There is anynumber of 50504C StandardID entity 50503C for a ShipToLocation entity50599B. The BuyerID entity 50507C is of a type CDT 50509C“LocationPartyID” 50510C. There is zero or one 50508C BuyerID entity50507C for a ShipToLocation entity 50599B. The BidderID entity 50511C isof a type CDT 50513C “LocationPartyID” 50514C. There is zero or one50512C BidderID entity 50511C for a ShipToLocation entity 50599B. TheAddress entity 50515C is of a type AGDT 50517C “Address” 50518C. Thereis zero or one 50516C Address entity 50515C for a ShipToLocation entity50599B.

The DeliveryInformation package 50519C includes a DeliveryTerms entity50520C at the fourth level 50508D. The DeliveryTerms entity 50520C is ofa type AGDT 50522C “DeliveryTerms” 50523C. There is zero or one 50521CDeliveryTerms entity 50520C for each DeliveryInformation package 50519C.The DeliveryTerms entity 50520C includes a MaximumLeadTimeDurationentity 50524C and an Incoterms entity 50528C at the fifth level 50510D.The MaximumLeadTimeDuration entity 50524C is of a type GDT 50526C“Duration” 50527C. There is zero or one 50525C MaximumLeadTimeDurationentity 50524C for a DeliveryTerms entity. The Incoterms entity 50528C isof a type GDT 50530C “Incoterms” 50530C. There is zero or one 50529CIncoterms entity 50528C for a DeliveryTerms entity.

The BusinessTransactionDocumentReference package 50532C includes aPurchaseContractReference entity 50533C and aBuyerProductCatalogueReference entity 50545C at the fourth level 50508D.The PurchaseContractReference entity 50533C is of a type GDT 50535C“BusinessTransactionDocumentReference” 50536C. There is zero or one50534C PurchaseContractReference entity 50533C for eachBusinessTransactionDocumentReference package 50532C. ThePurchaseContractReference entity 50533C includes an ID entity 50537C andan ItemID entity 50541C at the fifth level 50510D. The ID entity 50537Cis of a type GDT 50539C “BusinessTransactionDocumentID” 50540C. There isone 50538C ID entity 50537C for a PurchaseContractReference entity50533C. The ItemID entity 50541C is of a type GDT 50543C“BusinessTransactionDocumentItemID” 50544C. There is any number of50542C ItemID entity 50541C for a PurchaseContractReference entity50533C.

The BuyerProductCatalogueReference entity 50545C is of a type AGDT50547C “CatalogueReference” 50548C. There is zero or one 50546CBuyerProductCatalogueReference entity 50545C for eachBusinessTransactionDocumentReference package 50532C. TheBuyerProductCatalogueReference entity 50545C includes an ID entity50549C and an ItemID entity 50553C at the fifth level 50510D. The IDentity 50549C is of a type GDT 50551C “CatalogueID” 50552C. There is one50550C ID entity 50549C for a BuyerProductCatalogueReference entity50545C. The ItemID entity 50553C is of a type GDT 50555C“CatalogueItemID” 50556C. There is zero or one 50554C ItemID entity50553C for a BuyerProductCatalogueReference entity 50545C.

The Attachment package 50557C includes an AttachmentWebAddress entity50558C and an InternalAttachmentWebAddress entity 50562C at the fourthlevel 50508D. The AttachmentWebAddress entity 50558C is of a type GDT50560C “AttachmentWebAddress” 50561C. There is any number of 50559CAttachmentWebAddress entity 50558C for each Attachment package 50557C.The InternalAttachmentWebAddress entity 50562C is of a type GDT 50564C“AttachmentWebAddress” 50565C. There is any number of 50563CInternalAttachmentWebAddress entity 50562C for each Attachment package50557C.

The Description package 50566C includes a Description entity 50567C andan InternalDescription entity 50571C at the fourth level 50508D. TheDescription entity 50567C is of a type GDT 50569C “Description” 50570C.There is zero or one 50568C Description entity 50567C for eachDescription package 50566C. The InternalDescription entity 50571C is ofa type GDT 50573C “Description” 50574C. There is zero or one 50572CInternalDescription entity 50571C for each Description package 50566C.

The ScheduleLine package 50575C includes a ScheduleLine entity 50576C atthe fourth level 50508D. The ScheduleLine entity 50576C is of a typeAGDT 50578C “RFQItemScheduleLine” 50579C. There is zero or one 50577CScheduleLine entity 50576C for each ScheduleLine package 50575C. TheScheduleLine entity 50576C includes an ID entity 50580C, aDeliveryPeriod entity 50584C, and a Quantity entity 50588C at the fifthlevel 50510D. The ID entity 50580C is of a type GDT 50582C“BusinessTransactionDocumentItemScheduleLineID” 50583C. There is zero orone 50581C ID entity 50580C for a ScheduleLine entity 50576C. TheDeliveryPeriod entity 50584C is of a type AGDT 50586C “DateTimePeriod”50587C. There is one 50585C DeliveryPeriod entity 50584C for aScheduleLine entity 50576C. The Quantity entity 50588C is of a type GDT50590C “Quantity” 50591C. There is zero or one 50589C Quantity entity50588C for a ScheduleLine entity 50576C.

pp) SupplyChainExceptionReport Interface

In B2B processes, SupplyChainExceptionReport interfaces are used by abusiness partner, such a a vendor entity, to send a notification aboutone or more exceptions that have occurred in the supply chain. Eachexception is triggered typically either by an unforeseen event thataffects the execution of the logistics process (such as productionstandstill) or is triggered when logistics-relevant threshold values ortolerances agreed upon between business partners in the supply chain areexceeded or fallen below the logistics-relevant threshold values. Thesethreshold values or tolerances are defined at the level of the ship-fromor ship-to locations and/or at product level as discussed below.Exceptions may be identified with automatically or manually-controlledmonitoring of the logistics processes. They can affect differentlogistics-relevant issues such as forecast deviations, variances tologistical key figures, shortfall quantities of products, andtransportation or production problems. The recipient of the notificationtransmitted using the SupplyChainExceptionReport interface is trigger toperform a corresponding process to handle the exception identified inthe notification.

The motivating business scenario is the “Collaborative Planning andForecasting” business scenario which describes the coordination of salesand purchase order forecasts between a buyer (e.g., retail company) anda vendor (e.g., consumer products manufacturer).

(1) SupplyChainExceptionReportNotification MessageType

A SupplyChainExceptionReportNotification is a notification or reportmessage to an entity, such as a buyer, about exceptions that haveoccurred during logistics planning or logistics execution within asupply chain. The SupplyChainExceptionReportNotification messagestructure is based on the message data typeSupplyChainExceptionReportNotificationMessage.

(2) Message Choreography

FIG. 506 depicts the message choreography for SupplyChainExceptionReportinterfaces. The choreography involves two business entities: a buyer50602 and a vendor 50604. In the implementation shown in FIG. 506, thebuyer 50602 transmits a sales forecast or purchase order forecast(ProductForecastNotification 50606) to the vendor 50604. TheProductForecastNotifiation 50606 may cause the vendor 50604 to generateone or more exceptions that the vendor 50604 subsequently notifies tothe buyer 50602 via a SupplyChainExceptionReportNotification 50608. Inresponse to the SupplyChainExceptionReportNotification 50608, the buyer50602 may send the vendor 50604 a revised version of the originalforecast (ProductForecastRevisionNotification 50610).

(3) Message Data Type SupplyChainExceptionReportMessage

The data model for the message data typeSupplyChainExceptionReportMessage used to implement aSupplyChainExceptionReportNotification 50708 is depicted in FIG. 507.The SupplyChainExceptionReportMessage message data type groups thebusiness information that is relevant for sending a business document ina message and the SupplyChainExceptionReport object or entity includedin the business document. As depicted in FIG. 507, the message data typeSupplyChainExceptionReportMessage includes aSupplyChainExceptionReportMessage package 50702, which includes aMessageHeader package 50704, a SupplyChainExceptionReport package 50706,and a SupplyChainExceptionReportMessage entity 50708.

(a) Message Header Package

A MessageHeader package 50704 groups together the business informationthat is relevant for sending a business document in a message. TheMessageHeader package 50704 includes a MessageHeader entity 50710. Thereis a 1:1 relationship between the SupplyChainExceptionReportMessageentity 50708 and the MessageHeader entity 50710. Where a relationship isidentified between entitites in FIG. 507 for this Interface, therespective relationship is a 1:1 relationship unless otherwise notedherein or indicated in FIG. 507. The MessageHeader package 50704 alsoincludes a SenderParty entity 50712 and a RecipientParty entity 50714.There is a 1:c relationship between the MessageHeader entity 50710 andthe SenderParty entity 50712 and between the MessageHeader entity 50710and the RecipientParty entity 50714.

The SenderParty 50712 is the party responsible for sending a businessdocument at the business application level. The SenderParty entity 50712is of type GDT: BusinessDocumentMessageHeaderParty.

The RecipientParty 50714 is the party responsible for receiving abusiness document at the business application level. The RecipientPartyentity 50714 is of type GDT: BusinessDocumentMessageHeaderParty.

(b) SupplyChainExceptionReport package

The SupplyChainExceptionReport package 50706 includes a Party package50716, a SupplyChainException package 50718, and aSupplyChainExceptionReport entity 50720. The SupplyChainExceptionReportentity 50720 identifies the exceptions that have occurred duringlogistics planning or logistics execution within a supply chain. Theexceptions identified in the SupplyChainExceptionReport entity 50720 aregrouped in relation to a sending and a receiving party, each of whichmay be ascertained from the list of business partners for the supplychain.

(i) SupplyChainExceptionReportParty Package

The SupplyChainExceptionReportParty package 50716 includes a BuyerPartyentity 50722, a VendorParty entity 50724, and a ProductRecipientPartyentity 50726. There is a respective 1:c relationship between theSupplyChainExceptionReport entity 50720 and each of the BuyerPartyentity 50722, the VendorParty entity 50724, and theProductRecipientParty entity 50726.

The BuyerParty entity 50722, as a buyer of goods or services, isaffected by the exceptions identified in the SupplyChainExceptionReportentity 50720. The BuyerParty entity 50722 is of type GDT:BusinessTransactionDocumentParty. In one implementation, the BuyerPartyentity 50722 includes the InternalID, the StandardID, the BuyerID, andthe VendorID elements identified in the type GDT:BusinessTransactionDocumentParty.

The VendorParty entity 50724, as a vendor of goods or services, is alsoaffected by the exceptions identified in the SupplyChainExceptionReportentity 50720. The VendorParty entity 50724 is of type GDT:BusinessTransactionDocumentParty. In one implementation, the BuyerPartyentity 50722 includes the InternalID, the StandardID, the BuyerID, andthe VendorID elements identified in the type GDT:BusinessTransactionDocumentParty.

The ProductRecipientParty entity 50726, as a recipient of goods orservices, is also affected by the exceptions identified in theSupplyChainExceptionReport entity 50720. The ProductRecipientPartyentity 50726 is of type GDT: BusinessTransactionDocumentParty and usesthe InternalID, the StandardID, the BuyerID, and the VendorID of thistype.

(ii) SupplyChainException Package

The SupplyChainException package 50718 includes aBusinessTransactionDocumentReference package 50728, a Location package50730, a ProductInformation package 50732, a Batch package 50734, aPropertyValuation package 50736, a Log package 50738, and aSupplyChainException entity 50740, which has a I :n relationship withthe SupplyChainExceptionReport entity 50720. The SupplyChainExceptionentity 50720 is an exception that has occurred in the supply chain. TheSupplyChainException entity 50720 includes the following an ActionCodeattribute, which is a representation of an instruction to the messagerecipient as to how he or she should deal with the transmittedexception. For example, in one implementation, an ActionCode mayidentify a new creation instruction, a change instruction, or a deleteinstruction for an associated product forecast (e.g., as indentified inProductForecastNotification 50706). Each ActionCode is of type GDT:ActionCode. The SupplyChainException entity 50720 also includes thefollowing elements: an InternalID that is a unique internal identifierfor the SupplyChainException entity 50720 and used if the sender andrecipient are able to access the same master data. The InternalID is oftype GDT: BusinessTransactionDocumentID; a BuyerID that is a uniqueidentifier used to identify the BuyerParty entity 50722 associated withthe SupplyChainException entity 50740. The BuyerID is of type GDT:BusinessTransactionDocumentID; a VendorID that is a unique identifierused to identify the VendorParty entity 50724 associated with theSupplyChainException entity 50740. The VendorID is of type GDT:BusinessTransactionDocumentID; a Name that describes theSupplyChainException entity 50740. The Name is of type GDT: Name; aTypeID that is a unique identifier for the type of SupplyChainException(such as product shortage). The TypeID is of type GDT:SupplyChainExceptionTypeID; a CreationDateTime, which is a creation timeof the SupplyChainException entity 50740. The CreationDateTime is oftype GDT: DateTime; a LastChangeDateTime, which identifies the last timethe SupplyChainException entity 50740 was changed. TheLastChangeDateTime is of type GDT: DateTime; a StatusCode, which is arepresentation of the status, such as new, resolved, or unresolved, ofthe SupplyChainException entity 50740. The StatusCode is of type GDT:SupplyChainExceptionStatusCode; a ProcessingPriorityCode, which is arepresentation of the urgency of the processing of aSupplyChainException entity 50740. The ProcessingPriorityCode is of typeGDT: BusinessTransactionPriorityCode; a ValidityPeriod, which isidentifies a period that the SupplyChainException entity 50740 is valid.This period can start in the past, present, or future (for forecasts)depending on the type and occurrence time of the exception. TheValidityPeriod is of type GDT: DateTimePeriod; a Note, which is textconcerning the SupplyChainException entity 50740. The Note is of typeGDT: Note;

(a) BusinessTransactionDocumentReference Package

The SupplyChainException BusinessTransactionDocumentReference package50728 groups references to business documents for which aSupplyChainException 50740 can occur. The SupplyChainExceptionBusinessTransactionDocumentReference package 50728 includes aPurchaseOrderReference entity 50742, a SchedulingAgreementReferenceentity 50744, a SalesOrderReference entity 50746, and anInboundDeliveryReference entity 50748. There is a respective 1:crelationship between the SupplyChainException entity 50740 and each ofthe PurchaseOrderReference entity 50742, theSchedulingAgreementReference entity 50744, the SalesOrderReferenceentity 50746, and the InboundDeliveryReference entity 50748.

The PurchaseOrderReference entity 50742 is the reference to a purchaseorder or to an item within a purchase order for which aSupplyChainException has occurred. The PurchaseOrderReference entity50742 includes the purchase order number and purchase order item numberassigned by the BuyerParty 50722. The PurchaseOrderReference entity50742 is of type GDT: BusinessTransactionDocumentReference.

The SchedulingAgreementReference entity 50744 is the reference to anitem in a scheduling agreement for which a SupplyChainException 50740has occurred. The SchedulingAgreementReference entity 50744 includes anItemID and is of type GDT: BusinessTransactionDocumentReference.

The SalesOrderReference entity 50746 is the reference to a sales orderor to an item in a sales order. The SalesOrderReference entity 50746includes the order number and order item number assigned by the seller.The SalesOrderReference is of type GDT:BusinessTransactionDocumentReference.

The InboundDeliveryReference entity 50748 is the reference to an inbounddelivery or an item of an inbound delivery for which aSupplyChainException 50740 has occurred. The InboundDeliveryReference isof type GDT: BusinessTransactionDocumentReference.

(b) Location Package

The SupplyChainException Location Package 50730 groups locations where aSupplyChainException 50740 may occur. The SupplyChainException LocationPackage 50730 includes a ShipFromLocation 50750 and a ShipToLocation50752. There is a 1:c relationship between the SupplyChainExceptionenity 50740 and each of the ShipFromLocation entity 50750 and theShipToLocation entity 50752.

The ShipFromLocation entity 50750 is the location from which the orderedproducts are delivered and where the SupplyChainException 50740 hasoccurred. The ShipFromLocation entity 50750 is of type GDT:BusinessTransactionDocumentShipFromLocation, where, in oneimplementation, only the InternalID, the StandardID, the BuyerID, andthe VendorID are used. In another implementation, for intra-enterprisecommunication, only the InternalID in each ShipFromLocation entity 50750is used. In yet another implementation, for inter-enterprisecommunication, each ShipFromLocation entity 50750 either uses theStandardID or the partner-role-specific ID of the sending or receivingpartner; in other words, the BuyerID or VendorID. However, all the IDelements of each ShipFromLocation entity 50750 are optional.

The ShipToLocation entity 50752 is the location where the orderedproducts are delivered and where the SupplyChainException 50740 hasoccurred. The ShipToLocation entity 50752 is of type GDT:BusinessTransactionDocumentShipToLocation, where, in one implementation,only the InternalID, the StandardID, the BuyerID, and the VendorID areused. In another implementation, for intra-enterprise communication,only the InternalID in each ShipToLocation entity 50752 is used. In yetanother implementation, for inter-enterprise communication, eachShipToLocation entity 50752 either uses the StandardID or thepartner-role-specific ID of the sending or receiving partner; in otherwords, the BuyerID or VendorID. However, all the ID elements of eachShipToLocation entity 50750 are optional.

(c) ProductInformation Package

The SupplyChainException ProductInformation package 50732 includes aProduct entity 50754 associated with the SupplyChainException 50740.There is a 1:c relationship between the SupplyChainException enity 50740and the Product entity 50754. The Product entity 50754 is of type GDT:BusinessTransactionDocumentProduct, where, in one implementation, onlythe InternalID, the StandardID, the BuyerID, the VendorID, and thePackageQuantity are used. In another implementation, forintra-enterprise communication, only the InternalID is used for eachProduct entity 50754. In yet another implementation, forinter-enterprise communication, each Product entity 50754 uses eitheronly the StandardID or the partner-role-specific ID of the sending orreceiving partner, in other words, the BuyerID or VendorID. However, allID elements of each Product entity 50754 are optional.

(d) Batch Package

The Batch package includes a Batch entity 50756 for which theSupplyChainException 50740 has occurred. There is a 1:c relationshipbetween the SupplyChainException enity 50740 and the Batch entity 50756.The Batch entity 50756 includes an InternalID, a BuyerID, a VendorID, aManufacturingDate, a BestBeforeDate, and an OriginCountryCode. TheInternalID identifies the Batch 50756 and is of type GDT: BatchID. TheBuyerID is a unique identifier assigned by the BuyerParty 50722 for theBatch 50756 and is of type GDT: BatchID. The VendorID is a uniqueidentifier assigned by the VendorParty for the Batch 50756 and is oftype GDT: BatchID. The ManufacturingDate is the date of manufacture ofthe Batch 50756 and is the type of the GDT: Date. The BestBeforeDate isthe date of the Batch 50756 and is of type GDT: Date. TheOriginCountryCode is a representation of the country of origin of theBatch 50756 and is of type GDT: CountryCode.

(e) PropertyValuation Package

The SupplyChainException PropertyValuation package 50736 groupsinformation about characteristic properties of a SupplyChainException50740 that may not be described by the ShipFromLocation entity 50750,the ShipToLocation entity 50752, or the Product entity 50754. TheSupplyChainException PropertyValuation package 50736 includes aPropertyValuation entity 50758 assigned to and describes properties of acharacteristic of the SupplyChainException 50740. There is a 1:ncrelationship between the SupplyChainException enity 50740 and thePropertyValuation entity 50758. The PropertyValuation entity 50758 is oftype GDT: PropertyValuation, where, in one implementation, only aPropertyReference and one PropertyValue (with AmountSpecification,QuantitySpecification, DateTimeSpecification, and NameSpecificationelements) are supported. The PropertyReference is used to specify theidentifier of the characteristic of the SupplyChainException 50740assigned to the PropertyValuation entity 50758. Each PropertyValue isused to specify the related characteristic value. The use of thePropertyValuation entity 50758 as an additional description option forcharacteristic properties of a SupplyChainException 50740 may require abilateral agreement between the message sender and the message recipientor the use of industry standards for characteristics and theirproperties. Examples of additional characteristic properties of aSupplyChainException 50740 are as follows: An exception type codecorreponding to a sales price increase having a PropertyID for the salesprice and an AmountSpecification, an exception type code correspondingto a product shortage having a PropertyID for the shortfall quantity anda QuantitySpecification, an Exception type code corresponding to adelivery delay having a PropertyID for arrival time and aDateTimeSpecification, and an Exception type code corresponding to anassembly line standstill having a PropertyID for the assembly linedescription and a NameSpecification.

(f) Log Package

The SupplyChainException Log package 50738 groups logs that are relevantto the SupplyChainException 50740. The SupplyChainException Log package50738 includes a ValidationLog entity 50760, which includes one or moreItem entities 50762. The ValidationLog entity 50760 is a log for theprocess of the logistics planning or logistics execution check for aSupplyChainException. There is a 1:c relationship between theSupplyChainException enity 50740 and the PropertyLog entity 50760. Thereis a 1:n relationship between the PropertyLog enity 50760 and the Itementity 50762. The ValidationLog entity 50760 is of type GDT: Log, where,in one implementation, only the elements TypeID, SeverityCode, and Noteare used in the Item. The check for exceptions may be performed using anautomatically or manually-controlled process according to a definedcriteria. If this check detects an exception, the relevant check log maybe transmitted using the SupplyChainException ValidationLog entity50760.

(4) Message Data Type Element Structure

The message data type element structure for the Supply Chain ExceptionReport message is depicted in FIG. 508. The element structure is similarto the data model, but provides additional information regarding thedetails of the interface. The element structure identifies the differentpackages 50800 in the interface, and represents the entities at variouslevels within the interface. As depicted in FIG. 508, the interface forSupplyChainExceptionReportMessage includes eight levels 50802, 50804,50806, 50808, 50810, 50812, 50814, and 50816. The outermost package ofthis interface is a SupplyChainExceptionReportMessage package 50824,which includes a SupplyChainExceptionReportNotification entity 50826 atthe first level 50802. The SupplyChainExceptionReportNotification entity50826 is of a type MDT 50828 “SupplyChainExceptionReportMessage” 50830.

The SupplyChainExceptionReportMessage package 50824 includes aMessageHeader package 50832 and a SupplyChainExceptionReport package50808A.

The MessageHeader package 50832 includes a MessageHeader entity 50834 atthe second level 50804. The MessageHeader entity 50834 includes an IDentity 50842, a CreationDateTime entity 50850, a SenderParty entity50858, and a RecipientParty entity 50882 at the third level 50806. TheMessageHeader entity 50834 is of a type GDT 50838“BusinessDocumentMessageHeader” 50840. There is one 50836 MessageHeaderentity 50834 for each MessageHeader package 50832. The ID entity 50842is of a type GDT 50846 “Business DocumentMessageID” 50848. There is one50844 ID entity 50842 for a MessageHeader entity 50834. TheCreationDateTime entity 50850 is of a type GDT 50854 “DateTime” 50856.There is one 50852 CreationDateTime entity 50850 for a MessageHeaderentity 50834.

The SenderParty entity 50858 includes an InternalID entity 50866 and aStandardID entity 50874 at the fourth level 50808. The SenderPartyentity 50858 is of a type GDT 50862 “BusinessDocumentMessageHeaderParty”50864. There is zero or one 50852 SenderParty entity 50858 for aMessageHeader entity 50834. The InternaliD entity 50866 is of a type GDT50870 “PartyInternalID” 50872. There is zero or one 50868 InternaliIDentity 50866 for a SenderParty entity 50858. The StandardID entity 50874is of a type GDT 50878 “PartyStandardID” 50880. There is any number of50876 StandardID.entity 50874 for a SenderParty entity 50858.

The RecipientParty entity 50882 includes an InternalID entity 50890 anda StandardID entity 50898 at the fourth level 50808. The RecipientPartyentity 50882 is of a type GDT 50886 “BusinessDocumentMessageHeaderParty”50888. There is zero or one 50884 RecipientParty entity 50882 for aMessageHeader entity 50834. The InternalID entity 50890 is of a type GDT50894 “PartyInternalID” 50896. There is zero or one 50892 InternalIDentity 50890 for a RecipientParty entity 50882. The StandardID entity50898 is of a type GDT 50804A “PartyStandardID” 50806A. There is anynumber of 50802A StandardID entity 50898 for a RecipientParty entity50882.

The SupplyChainExceptionReport package 50808A includes aSupplyChainExceptionReport entity 50810A at the second level, a PartyPackage 50814A, and a SupplyChainException package 50838B. TheSupplyChainExceptionReport entity 50810A has a data type name“SupplyChainExceptionReport” 50812A. There is one 50810ASupplyChainExceptionReport entity 50810A for eachSupplyChainExceptionReport package 50808A.

The Party package 50814A includes a BuyerParty entity 50816A, aVendorParty entity 50856A, and a ProductRecipientParty entity 50896A atthe third level 50806. The BuyerParty entity 50816A includes anInternalID entity 50824A, a StandardID entity 50832A, a BuyerID entity50840A, and a VendorID entity 50848A at the fourth level 50808. TheBuyerParty entity 50816A is of a type GDT 50820A“BusinessTransactionDocumentParty” 50822A. There is zero or one 50818ABuyerParty entity 50816A for each Party package 50814A. The InternalIDentity 50824A is of a type GDT 50828A “PartyInternalID” 50830A. There iszero or one 50826A InternalID 50824A for a BuyerParty entity 50816A. TheStandardID entity 50832A is of a type GDT 50836A “PartyStandardID”50838A. There is any number of 50834A StandardID entity 50832A for aBuyerParty entity 50816A. The BuyerID entity 50840A is of a type GDT50844A “PartyPartyID” 50846A. There is zero or one 50842A BuyerID entity50840A for a BuyerParty entity 50816A. The VendorID entity 50848A is ofa type GDT 50892A “PartyPartyID” 50846A. There is zero or one 50890AVendorID entity 50848A for a BuyerParty entity 50816A.

The ProductRecipientParty entity 50896A includes an InternalID entity50806B, a StandardID entity 50814B, a BuyerID entity 50822B, and aVendorID entity 50830B at the fourth level 50808. TheProductRecipientParty entity 50896A is of a type GDT 50802B“BusinessTransactionDocumentParty” 50804B. There is zero or one 50898AProductRecipientParty entity 50896A for each Party package 50814A. TheInternalID entity 50806B is of a type GDT 50810B “PartyInternalID”50812B. There is zero or one 50808B InternalID 50806B for aProductRecipientParty entity 50896A. The StandardID entity 50814B is ofa type GDT 50818B “PartyStandardID” 50820B. There is any number of50816B StandardID entity 50814B for a ProductRecipientParty entity50896A. The BuyerID entity 50822B is of a type GDT 50826B “PartyPartyID”50828B. There is zero or one 50824B BuyerID entity 50822B for aProductRecipientParty entity 50896A. The VendorID entity 50830B is of atype GDT 50834B “PartyPartyID” 50836B. There is zero or one 50832BVendorID entity 50830B for a ProductRecipientParty entity 50896A. TheSupplyChainException package 50838B includes a SupplyChainExceptionentity 50840B at the third level 50806, aBusinessTransactionDocumentReference package 50832C, a Location package50866C, a ProductInformation package 50850D, a Batch package 50810E, aPropertyValuation package 50864E, and a Log package 50856F.

The SupplyChainException entity 50840B includes an @actionCode entity50846B, an InternalID entity 50854B, a BuyerID entity 50862B, a VendorIDentity 50870B, a Name entity 50878B, a TypeID entity 50886B, aCreationDateTime entity 50892B, a LastChangeDateTime entity 50802C, aStatusCode entity 50810C, a ProcessingPriorityCode entity 50818C, and aValidityPeriod entity 50826C at the fourth level 50808. TheSupplyChainException entity 50840B has a data type name“SupplyChainException” 50844B. There is any number of 50842BSupplyChainException entity 50840B for each SupplyChainException package50838B.

The ActionCode entity 50846B is of a type GDT 50850B “ActionCode”50844B. There is zero or one 50848B @actionCode entity 50846B for aSupplyChainException entity 50840B. The InternalID entity 50854B is of atype GDT 50858B “BusinessTransactionDocumentID” 50860B. There is zero orone 50856B InternalID entity 50854B for a SupplyChainException entity50840B. The BuyerID entity 50862B is of a type GDT 50866B“BusinessTransactionDocumentID” 50868B. There is zero or one 50864BBuyerID entity 50862B for a SupplyChainException entity 50840B. TheVendorID entity 50870B is of a type GDT 50874B“BusinessTransactionDocumentID” 50876B. There is zero or one 50872BVendorID entity 50870B for a SupplyChainException entity 50840B. TheName entity 50878B is of a type GDT 50882B “Name” 50876B. There is zeroor one 50880B Name entity 50878B for a SupplyChainException entity50840B. The TypeID entity 50886B is of a type GDT 50890B“SupplyChainExceptionTypeID” 50890B. There is one 50888B TypeID entity50886B for a SupplyChainException entity 50840B. The CreationDateTimeentity 50892B is of a type GDT 50896B “DateTime” 50898B. There is one50894B CreationDateTime entity 50892B for a SupplyChainException entity50840B. The LastChangeDateTime entity 50802C is of a type GDT 50806C“DateTime” 50808C. There is zero or one 50804C LastChangeDateTime entity50802C for a SupplyChainException entity 50840B. The StatusCode entity50810C is of a type GDT 50814C “SupplyChainExceptionStatusCode” 50816C.There is zero or one 50812C StatusCode entity 50810C for aSupplyChainException entity 50840B. The ProcessingPriorityCode entity50818C is of a type GDT 50822C “BusinessTransactionPriorityCode” 50824C.There is one 50820C ProcessingPriorityCode entity 50818C for aSupplyChainException entity 50840B. The ValidityPeriod entity 50826C isof a type GDT 50830C “DateTimePeriod” 50832C. There is zero or one50828C ValidityPeriod entity 50826C for a SupplyChainException entity50840B.

The BusinessTransactionDocumentReference package 50832C includes aPurchaseOrderReference entity 50834C, a SchedulingAgreementReferenceentity 50842C, a SalesOrderReference entity 50850C, and anInboundDeliveryReference entity 50858C at the fourth level 50808. ThePurchaseOrderReference entity 50834C is of a type GDT 50838C“BusinessTransactionDocumentReference” 50840C. There is zero or one50836C PurchaseOrderReference entity 50834C for eachBusinessTransactionDocumentReference package 50832C. TheSchedulingAgreementReference entity 50842C is of a type GDT 50846C“BusinessTransactionDocumentReference” 50848C. There is zero or one50844C SchedulingAgreementReference entity 50842C for eachBusinessTransactionDocumentReference package 50832C. TheSalesOrderReference entity 50850C is of a type GDT 50854C“BusinessTransactionDocumentReference” 50856C. There is zero or one50852C SalesOrderReference entity 50850C for eachBusinessTransactionDocumentReference package 50832C. TheInboundDeliveryReference entity 50858C is of a type GDT 50862C“BusinessTransactionDocumentReference” 50864C. There is zero or one50860C InboundDeliveryReference entity 50858C for eachBusinessTransactionDocumentReference package 50832C.

The Location package 50866C includes a ShipFromLocation entity 50868Cand a ShipToLocation entity 50810D at the fourth level 50808. TheShipFromLocation entity 50868C includes an InternalID entity 50876C, aStandardID entity 50884C, a BuyerID entity 50892C, and a VendorID entity50802D. The ShipFromLocation entity 50868C is of a type GDT 50872C“BusinessTransactionDocumentShipFromLocation” 50874C. There is zero orone 50868C ShipFromLocation entity 50868C for each Location package50866C. The InternalID entity 50876C is of a type GDT 50880C“LocationInternalID” 50882C. There is zero or one 50878C InternalIDentity 50876C for a ShipFromLocation entity 50868C. The StandardIDentity 50884C is of a type GDT 50888C “LocationStandardID” 50890C. Thereis zero or one 50886C StandardID entity 50884C for a ShipFromLocationentity 50868C. The BuyerID entity 50892C is of a type GDT 50896C“LocationPartyID” 50898C. There is zero or one 50894C BuyerID entity50892C for a ShipFromLocation entity 50868C. The VendorID entity 50802Dis of a type GDT 50806D “LocationPartyID” 50808D. There is zero or one50804D VendorID entity 50802D for a ShipFromLocation entity 50868C.

The ShipToLocation entity 50810D is of a type GDT 50814D“BusinessTransactionDocumentShipToLocation” 50816D. There is zero or one50812D ShipToLocation entity 50810D for each Location package 50866C.The InternalID entity 50818D is of a type GDT 50822D“LocationInternalID” 50824D. There is zero or one 50820D InternalIDentity 50818D for a ShipToLocation entity 50810D. The StandardID entity50826D is of a type GDT 50830D “LocationStandardID” 50832D. There iszero or one 50828D StandardID entity 50826D for a ShipToLocation entity50810D. The BuyerID entity 50834D is of a type GDT 50838D“LocationPartyID” 50840D. There is zero or one 50836D BuyerID entity50834D for a ShipToLocation entity 50810D. The VendorID entity 50842D isof a type GDT 50846D “LocationPartyID” 50848D. There is zero or one50844D VendorID entity 50842D for a ShipToLocation entity 50810D.

The ProductInformation package 50850D includes a Product entity 50852Dat the fourth level 50808. The Product entity 50852D includes anInternalID entity 50860D, a StandardID entity 50868D, a BuyerID entity50876D, a VendorID entity 50884D, a ChangeID entity 50892D, and aPackageQuantity entity 50802E. The Product entity 50852D is of a typeGDT 50856D “BusinessTransactionDocumentProduct” 50858D. There is zero orone 50854D Product entity 50852D for each ProductInformation package50850D. The InternalID entity 50860D is of a type GDT 50864D“ProductInternalID” 50866D. There is zero or one 50862D InternalIDentity 50860D for a Product entity 50852D. The StandardID entity 50868Dis of a type GDT 50872D “ProductStandardID” 50874D. There is zero or one50870D StandardID entity 50868D for a Product entity 50852D. The BuyerIDentity 50876D is of a type GDT 50880D “ProductPartyID” 50882D. There iszero or one 50878D BuyerID entity 50876D for a Product entity 50852D.The VendorID entity 50884D is of a type GDT 50888D “ProductPartyID”50890D. There is zero or one 50886D VendorID entity 50884D for a Productentity 50852D. The ChangeID entity 50892D is of a type GDT 50896D“ProductChangeID” 50898D. There is zero or one 50894D ChangeID entity50892D for a Product entity 50852D. The PackageQuantity entity 50802E isof a type GDT 50806E “Quantity” 50808E. There is zero or one 50804EPackageQuantity entity 50802E for a Product entity 50852D.

The Batch package 50812E includes a Batch entity 50812E at the fourthlevel 50808. The Batch entity 50812E includes an InternalID entity50816E, a BuyerID entity 50824E, a VendorID entity 50832E, aManufacturingDate entity 50840E, a BestBeforeDate entity 50848E, and anOriginCountryCode entity 50856E at the fifth level 50810. There is zeroor one 50814E Batch entity 50812E for each Batch package 50812E. TheInternalID entity 50816E is of a type GDT 50820E “BatchInternalID”50822E. There is zero or one 50818E InternalID entity 50816E for a Batchentity 50812E. The BuyerID entity 50824E is of a type GDT 50828E“BatchPartyID” 50830E. There is zero or one 50826E BuyerID entity 50824Efor a Batch entity 50812E. The VendorID entity 50832E is of a type GDT50836E “BatchPartyID” 50838E. There is zero or one 50834E VendorIDentity 50832E for a Batch entity 50812E. The ManufacturingDate entity50840E is of a type GDT 50844E “Date” 50846E. There is zero or one50842E ManufacturingDate entity 50840E for a Batch entity 50812E. TheBestBeforeDate entity 50848E is of a type GDT 50852E “Date” 50854E.There is zero or one 50850E BestBeforeDate entity 50848E for a Batchentity 50812E. The OriginCountryCode entity 50856E is of a type GDT50860E “CountryCode” 50862E. There is zero or one 50858EOriginCountryCode entity 50856E for a Batch entity 50812E.

The PropertyValuation package 50864E includes a PropertyValuation entity50866E at the fourth level 50808. The PropertyValuation entity 50866E isof a type GDT 50870E “PropertyValuation” 50872E. There is any number of50868E PropertyValuation entity 50866E for each PropertyValuationpackage 50864E. The PropertyValuation entity 50866E includes aPropertyReference entity 50874E and a ValueGroup entity 50890E at thefifth level 50810.

The PropertyReference entity 50874E is of a type GDT 50878E“PropertyReference” 50880E. There is one 50876E PropertyReference entity50874E for a PropertyValuation entity 50866E.The PropertyReferenceentity 50874E includes an ID entity 50882E at the sixth level 50812. TheID entity 50882E is of a type GDT 50886E “PropertyID” 50888E. There isone 50884E ID entity 50882E for a PropertyReference entity 50874E.

There is one 50892E ValueGroup entity 50890E for a PropertyValuationentity 50866E. The ValueGroup entity 50890E includes a PropertyValueentity 50894E at the sixth level 50812. The PropertyValue entity 50894Eincludes an AmountSpecification entity 50802F, a QuantitySpecificationentity 50814F, a DateTimeSpecification entity 50826F, and aNameSpecification entity 50838F at the seventh level 50814.

There is zero or one 50804F AmountSpecification entity 50802F for aPropertyValue entity 50894E. The AmountSpecification entity 50802Fincludes an Amount entity 50806F at the eighth level 50818. The Amountentity 50806F is of a type GDT 50810F “Amount” 50812F. There is one50808F Amount entity 50806F for an AmountSpecification entity 50802F.There is one 50816F QuantitySpecification entity 50814F for aPropertyValue entity 50894E. The QuantitySpecification entity 50814Fincludes a Quantity entity 50818F at the eighth level 50818. TheQuantity entity 50818F is of a type GDT 50822F “Quantity” 50824F. Thereis one 50820F Quantity entity 50818F for a QuantitySpecification entity50814F. There is one 50828F DateTimeSpecification entity 50826F for aPropertyValue entity 50894E. The DateTimeSpecification entity 50826Fincludes a DateTime entity 50830F at the eighth level 50818. TheDateTime entity 50830F is of a type GDT 50834F “DateTime” 50836F. Thereis one 50832F DateTime entity 50830F for a DateTimeSpecification entity50826F. There is one 50840F NameSpecification entity 50838F for aPropertyValue entity 50894E. The NameSpecification entity 50838Fincludes a Name entity 50842F at the eighth level 50818. The Name entity50842F is of a type GDT 50844F “Name” 50846F. There is one 50843F Nameentity 50842F for a NameSpecification entity 50838F.

The SupplyChainException package 50838B also includes a Note entity50848F at the fourth level 50808. The Note entity 50848F is of a typeGDT 50852F “Note” 50854F. There is zero or one 50850F Note entity 50848Ffor each SupplyChainException package 50838B.

The Log package 50856F includes a ValidationLog entity 50858F at thefourth level 50808. The ValidationLog entity 50858F is of a type GDT50862F “Log” 50864F. There is zero or one 50860F ValidationLog entity50858F for each Log package 50856F. The ValidationLog entity 50858Fincludes a MinimumLogItemSeverityCode entity 50866F and an Item entity50874F at the fifth level 50810.

The MinimumLogItemSeverityCode entity 50866F is of a type GDT 50870F“LogItemSeverityCode” 50872F. There is zero or one 50868FMinimumLogItemSeverityCode entity 50866F for a ValidationLog entity50858F. The Item entity 50874F is of a type GDT 50878F “LogItem” 50880F.There is any number of 50876F Item entity 50874F for a ValidationLogentity 50858F. The Item entity 50874F includes a TypeID entity 50882F, aSeverityCode entity 50890F, and a Note Entity 50898F at the sixth level50812. The TypeID entity 50882F is of a type CCT 50886F “Identifier”50888F. There is one 50884F TypeID entity 50882F for an Item entity50874F. The SeverityCode entity 50890F is of a type GDT 50894F“LogItemSeverityCode” 50896F. There is zero or one 50892F SeverityCodeentity 50890F for an Item entity 50874F. The Note entity 50898F is of atype GDT 50804G “Note” 50806G. There is zero or one 50802G Note entity50898F for an Item entity 50874F.

qq) VATDeclaration Interfaces

Value Added Tax (VAT) Declaration Interfaces are used to report taxes onsales/purchases to a tax authority and for the tax authority to confirmthe receipt and correctness of the tax return. Taxes on sales/purchasesare levied on taxable goods and services. There is typically aprovisional return of the accrued taxes on sales/purchases per month orquarter and a final return at the end of the year. In Germany, forexample, the tax return is sent to a tax office or to one of fourclearing houses. The clearing house distributes the returns to theindividual federal states. The VATDeclaration Interfaces are based onthe following message types: a VATDeclarationRequest and aVATDeclarationConfirmation.

One business scenario for the VATDeclarationRequest andVATDeclarationConfirmation messages is the electronic advance return fortax on sales and Purchases. Here, data for an electronic tax return fortax on sales/purchases is transferred to the integration server from thetax register using the VATDeclarationRequest. The integration serverconverts the data into a country-specific format for the tax return fortax on sales/purchases. The tax authority synchronously orasynchronously returns a log about the receipt, completeness, and formalcorrectness of the tax return. The integration server converts this loginto the format of the VATDeclarationConfirmation message and transfersit to the tax register.

(1) Message Types

(a) VATDeclarationRequest

A VATDeclarationRequest is a request to a tax authority to handle a taxreturn for tax on sales/purchases. The structure of the message typeVATDeclarationRequest is based on the message data typeVATDeclarationRequestMessage. The VATDeclarationRequest is transformedwithin the Exchange Infrastructure into the legal format for a taxreturn for tax on sales/purchases that is required by the taxauthorities.

(b) VATDeclarationConfirmation

A VATDeclarationConfirmation is a confirmation about the receipt,completeness, formal correctness and, if necessary, consistency of a taxreturn for tax on sales/purchases. The structure of the message typeVATDeclarationConfirmation is based on the message data typeVATDeclarationConfirmationMessage. The confirmation of the tax authorityabout the tax return for tax on sales/purchases is transformed withinthe Exchange Infrastructure from the official format of the taxauthority to the VATDeclarationConfirmation.

(2) Message Choreography

FIG. 509 depicts an exemplary message choreography for a VAT declarationcreation process between business applications or entities (e.g., TaxRegister entity 50902 and Tax Authority entity 50904) implementing VATDeclaration Interfaces in accordance with the subject matter describedherein. In the implementation shown in FIG. 509, the TaxOperator sendsthe VATDeclarationRequest 50906 from the TaxRegister entity 50902 to theTaxAuthority entity 50904 for the TaxPayer.

Depending on the country in which the tax authority operates, aconfirmation for the tax return for tax on sales/purchases can be sentusing the VATDeclarationConfirmation 50908. This can happensynchronously or asynchronously.

(3) Interfaces

The VATDeclarationRequest_Out interface is used to asynchronously send amessage of type VATDeclarationRequest 50906 to tax authorities. TheVATDeclarationConfirmation_In interface is used to asynchronouslyreceive a message of type VATDeclarationConfirmation 50908.

The VATDeclarationRequestConfirmation_Out interface is used tosynchronously send a message of type VATDeclarationRequest 50906 andreceive an answer of type VATDeclarationConfirmation 50908.

(4) Message Data Type VATDeclarationMessage

FIG. 510 depicts a data model of the message data typeVATDeclarationMessage. The message data type VATDeclarationMessagegroups the business information that is relevant for sending a businessdocument in a message and the VATDeclaration object is contained in thebusiness document. As shown in FIG. 510, message data typeVATDeclarationMessage includes a VATDeclarationMessage package 51002,which includes a MessageHeader package 51004, a VATDeclaration package51006, and a VATDeclarationMessage entity 51008.

The template message data type VATDeclarationMessage is the maximumstructure (template) for the message data typesVATDeclarationRequestMessage, VATDeclarationConfirmationMessage, and themessage types and interfaces based on it. VATDeclarationRequestMessageand VATDeclarationConfirmationMessage are derived as structural viewsfrom VATDeclarationMessage.

(a) MessageHeader Package

The MessageHeader package 51004 groups the business information that isrelevant for sending a business document in a message. The MessageHeaderpackage 51004 contains the MessageHeader entity 51010. There is a 1:crelationship between the VATDeclarationMessage entity 51008 and theMessageHeader entity 51010. Where a relationship is identified betweenentitites in FIG. 510 for this Interface, the respective relationship isa 1:1 relationship unless otherwise noted herein or indicated in FIG.510. The MessageHeader entity 51010 groups business information from theperspective of the sending application to identify the business documentin a message, information about the sender, and information about therecipient.

The MessageHeader entity 51010 is of type GDT:BusinessDocumentMessageHeader. In some implementations, theMessageHeader entity 51010 contains an ID element, that is theidentification of the business document in the technical message, and aReferenceID, that is a unique identifier for the message preceding theVATDeclarationConfirmation to report taxes on sales/purchases.

The MessageHeader entity 51010 can be used or not used in theVATDeclarationConfirmationMessage depending on the country in which thetax return for tax on sales/purchases is submitted.

(b) VATDeclaration Package

The VATDeclaration package 51006 groups the VATDeclaration with itspackages. The VATDeclaration package 51006 contains a Log package 51012,a Party package 51014, and an Item package 51016.

In some implementations, the Log package 51012 is not used in theVATDeclarationRequestMessage and the Item package 51016 is not used inthe VATDeclarationConfirmationMessage.

The VATDeclaration package 51006 also contains a VATDeclaration entity51018. The VATDeclaration entity 51018 is a tax return for tax onsales/purchases to a tax authority. The VATDeclaration entity 51018contains the following elements: an actionCode, an ID, a Period, anAcceptanceStatusCode, a PaymentAmount, an AdvancePaymentAmount, aTaxDueClearingIndicator, a CollectionAuthorisationRevocationIndicator,and a Note. The actionCode is a coded display of information regardinghow the tax authority should process the transferred VATDeclaration.This concerns the actionCode “01” (Create) for a new VATDeclaration orthe actionCode “02” (Change) to correct the contents of an earlierVATDeclaration. The actionCode is of type GDT: ActionCode. The ID is aunique identifier of tax return for tax on sales/purchases assigned bythe TaxOperator and is of type GDT: BusinessTransactionDocumentID. ThePeriod is the calendar period for which taxes on sales/purchases arereported and is of type GDT: DatePeriod. The AcceptanceStatusCode is thestatus of acceptance by the tax authority on the tax return for tax onsales/purchases. The codes “accepted” or “rejected” are possible. ThePeriod is of type GDT: AcceptanceStatusCode. The PaymentAmount is theamount of taxes on sales/purchases to be paid for the calendar periodspecified and is of type GDT: Amount. The AdvancePaymentAmount is theamount paid in advance for taxes on sales/purchases and is of type GDT:Amount. The TaxDueClearingIndicator indicates whether a reimbursement oftaxes on sales/purchases, which results from the transferredVATDeclaration, is cleared against the tax office with payables. TheTaxDueClearingIndicator is of type GDT: DueClearingIndicator. TheCollectionAuthorisationRevocationIndicator indicates whether or not acollection authorization issued earlier is revoked and is of type GDT:RevocationIndicator. The Note is a comment on the VATDeclaration. Thiscan be free text such as “Due to poor demand there was only low sales inthe current period.” It can be used, for example, in an Austrian taxreturn for tax on sales/purchases. In some implementations, the languageto be used is predefined by the country or tax authority in which thereturn is submitted. The Note is of type GDT: Note.

In some implementations, during VATDeclarationRequestMessage, theAcceptanceStatusCode is not used in the VATDeclarationRequestMessage. Insome implementations, the AdvancePaymentAmount and Note elements areoptional.

In some implementations, during a VATDeclarationConfirmationMessage, theID and Period elements are optional. In addition, the actionCodeattribute and the PaymentAmount, AdvancePaymentAmount,TaxDueClearingIndicator, CollectionAuthorisationRevocationIndicator, andNote elements are not used.

(i) VATDeclarationLog Package

The Log package 51012 groups a ValidationLog entity 51020 and aValidationLogItem entity 51022. In some implementations, the Log package51012 is not used in the VATDeclarationRequestMessage and it is optionalin the VATDeclarationConfirmationMessage. The ValidationLog entity 51020is a series of log messages from the tax authority that is has receivedand validated a tax return for tax on sales/purchases. TheValidationLogItem entity 51022 is a log message on the receipt andvalidation of a tax return for tax on sales/purchases. TheValidationLogItem entity 51022 is of type GDT: LogItem, where only thefollowing elements are used: a TypeID, a SeverityCode, and a Note. TheTypeID is a unique identification of the character of a log message onthe receipt or form of a tax return for tax on sales/purchases. TheSeverityCode is a coded display of the severity of the named log messageand is of type GDT: LogItemSeverityCode. The Note is a short text of thelog message. There is a 1:n relationship between the ValidationLogentity 51020 and the ValidationLogItem entity 51022.

(ii) VATDeclarationParty Package

The Party Package 51014 is the grouping of the business partners thatmay be relevant within the tax return for tax on sales/purchases. TheParty Package 51014 contains the entities: TaxPayerParty 51024,TaxAuthorityParty 51026, and TaxOperatorParty 51028. The TaxPayerPartyentity 51024 is a party that is liable to tax on sales/purchases. TheTaxPayerParty entity 51024 is of type GDT:BusinessTransactionDocumentParty, where only the TaxID and Addresselements are used. The Address is a company address. The TaxPayerPartyentity 51024 is a company or a group of companies that report theirtaxes on sales/purchases jointly. The TaxAuthorityParty entity 51026 isthe tax authority that receives the VATDeclaration and is of type GDT:TaxAuthorityParty. The TaxOperatorParty entity 51028 is a party thatcreates and sends the tax return for tax on sales/purchases for theTaxPayerParty entity 51026. The TaxOperatorParty entity 51028 is of typeGDT: BusinessTransactionDocumentParty, where only the Address andContactPerson elements are used. The Address is a company address. Onlythe Address element is used in ContactPerson (address of contactperson). The TaxOperatorParty entity 51028 is typically a tax adviser orthe tax department of a company. If the TaxOperatorParty entity 51028 isnot specified, the TaxPayerParty entity 51024 performs this role. Thereis a 1:c relationship between the VATDeclaration entity 51018 and theTaxOperatorParty entity 51028.

(iii) VATDeclarationItem Package

The VATDeclarationItem package 51016 groups the VATDeclarationItementity 51030. In some implementations, the Item package 51016 is notused in the VATDeclarationConfirmationMessage. There is a 1:nrelationship between the VATDeclaration entity 51018 and theVATDeclarationItem entity 51030. The VATDeclarationItem entity 51030 isdetailed information on the type and scope of reported taxes onsales/purchases. The VATDeclarationItem contains the elements:TaxDeclarationAmountTypeCode, Amount, and Note. TheTaxDeclarationAmountTypeCode is a coded display for the type of anamount in a tax return (in tax ID). For example, whether it is a taxbase amount or a tax amount. The TaxationKeyID is dependent on thecountry, tax number, and calendar period for which the taxes onsales/purchases are reported. The TaxDeclarationAmountTypeCode is oftype GDT: TaxDeclarationAmountTypeCode. The Amount is the amount appliedto taxes on sales/purchases by the type specified by the tax ID. TheAmount is used with plus/minus sign, where the meaning of the plus/minussign is dependent on the tax ID. The Amount is of type GDT: Amount. TheNote is a textual description of the tax ID and is of type GDT: Note.

(5) Message Data Type Element Structure

The message data type element structure for the VAT Declaration messageis depicted in FIG. 511A. The element structure is similar to the datamodel, but provides additional information regarding the details of theinterface. The element structure identifies the different packages 51100in the interface, and represents the entities at various levels withinthe interface. As depicted in FIG. 511A, the interface forVATDeclarationMessage includes five levels 51102, 51104, 51106, 51108,and 51110. The outermost package of this interface is aVATDeclarationMessage package 51116, which includes aVATDeclarationMessage entity 51118 at the first level 51102. TheVATDeclarationMessage entity 51118 is of a type MDT 51120“VATDeclarationMessage” 51122.

The VATDeclarationMessage package 51116 includes a MessageHeader package51124 and a VATDeclaration package 51158. The MessageHeader package51124 includes a MessageHeader entity 51126 at the second level 51104.The MessageHeader entity 51126 is of a type GDT 51130“BusinessDocumentMessageHeader” 51132. There is zero or one 51128MessageHeader entity 51126 for each MessageHeader package 51124. TheMessageHeader entity 51126 includes an ID entity 51134, a ReferenceIDentity 51142, and a CreationDateTime entity 51150 at the third level51106. The ID entity 51134 is of a type GDT 51138“BusinessDocumentMessageID” 51140. There is one 51136 ID entity 51134for a MessageHeader entity 51126. The ReferenceID entity 51142 is of atype GDT 51146 “BusinessDocumentMessageID” 51148. There is zero or one51144 ReferenceID entity 51142 for a MessageHeader entity 51126. TheCreationDateTime entity 51150 is of a type GDT 51154 “DateTime” 51156.There is one 51152 CreationDateTime entity 51150 for a MessageHeaderentity 51126.

The VATDeclaration package 51158 includes a VATDeclaration entity 51160at the second level 51104, a Log package 51140A, a Party package 51182A,and an Item package 51148B.

The VATDeclaration entity 51160 has a data type name “VATDeclaration”51166. There is one 51162 VATDeclaration entity 51160 for eachVATDeclaration package 51158. The VATDeclaration entity 51160 includesan @actionCode entity 51168, an ID entity 51176, a Period entity 51184,an AcceptanceStatusCode entity 51192, a PaymentAmount entity 51100A, anAdvancePaymentAmount entity 51108A, a TaxDueClearingIndicator entity51116A, a CollectionAuthorisationRevocationIndicator entity 51124A, anda Note entity 51132A at the third level 51106.

The @actionCode entity 51168 is of a type GDT 51172 “ActionCode” 51174.There is zero or one 51170 @actionCode entity 51168 for a VATDeclarationentity 51160. The ID entity 51176 is of a type GDT 51180“BusinessTransactionDocumentID” 51182. There is one 51178 ID entity51176 for a VATDeclaration entity 51160. The Period entity 51184 is of atype GDT 51188 “DatePeriod” 51190. There is one 51186 Period entity51184 for a VATDeclaration entity 51160. The AcceptanceStatusCode entity51192 is of a type GDT 51196 “AcceptanceStatusCode” 51198. There is zeroor one 51194 AcceptanceStatusCode entity 51192 for a VATDeclarationentity 51160. The PaymentAmount entity 51100A is of a type GDT 51104A“Amount” 51106A. There is one 51102A PaymentAmount entity 51 100A for aVATDeclaration entity 51160. The AdvancePaymentAmount entity 51108A isof a type GDT 51112A “Amount” 51114A. There is zero or one 51110AAdvancePaymentAmount entity 51108A for a VATDeclaration entity 51160.The TaxDueClearingIndicator entity 51116A is of a type GDT 51120A“DueClearingIndicator” 51122A. There is one 51118ATaxDueClearingIndicator entity 51116A for a VATDeclaration entity 51160.The CollectionAuthorisationRevocationIndicator entity 51124A is of atype GDT 51128A “RevocationIndicator” 51130A. There is zero or one51126A CollectionAuthorisationRevocationIndicator entity 51124A for aVATDeclaration entity 51160. The Note entity 51132A is of a type GDT51136A “Note” 51138A. There is zero or one 51134A Note entity 51132A fora VATDeclaration entity 51160.

The Log package 51140A includes a ValidationLog entity 51142A at thethird level 51106. The ValidationLog entity 51142A has a data type name“VATDeclarationValidationLog” 51148A. There is zero or one 51144AValidationLog entity 51142A for each Log package 51140A. TheValidationLog entity 51142A includes an Item entity 51150A at the fourthlevel 51108. The Item entity 51150A is of a type GDT 51154A “LogItem”51156A. There is any number of 51152A Item entity 51150A for aValidationLog entity 51142A. The Item entity 51150A includes a TypeIDentity 51158A, a SeverityCode entity 51166A, and a Note entity 51174A atthe fifth level 51110. The TypeID entity 51158A is of a type CCT 51162A“Identifier” 51164A. There is zero or one 51160A TypeID entity 51158Afor an Item entity 51150A. The SeverityCode entity 51166A is of a typeGDT 51170A “LogItemSeverityCode” 51172A. There is zero or one 51168ASeverityCode entity 51166A for an Item entity 51150A. The Note entity51174A is of a type GDT 51178A “Note” 51180A. There is one 51176A Noteentity 51174A for an Item entity 51150A.

The Party package 51182A includes a TaxPayerParty entity 51184A, aTaxAuthorityParty entity 51108B, and a TaxOperatorParty entity 51116B atthe third level 51106. The TaxPayerParty entity 51184A is of a type GDT51188A “BusinessTransactionDocumentParty” 51190A. There is one 51186ATaxPayerParty entity 51184A for each Party package 51182A. TheTaxPayerParty entity 51184A includes a TaxID entity 51192A and anAddress entity 51100B at the fourth level 51192A. The TaxID entity51192A is of a type GDT 51196A “PartyTaxID” 51198A. There is one 51194ATaxID entity 51192A for a TaxPayerParty entity 51184A. The Addressentity 51100B is of a type GDT 51104B “Address” 51106B. There is zero orone 51102B Address entity 51100B for a TaxPayerParty entity 51184A.

The TaxAuthorityParty entity 51108B is of a type GDT 51112B“TaxAuthorityParty” 51114B. There is one 51110B TaxAuthorityParty entity51108B for each Party package 51182A.

The TaxOperatorParty entity 51116B is of a type GDT 51120B“BusinessTransactionDocumentParty” 51122B. There is zero or one 51118BTaxOperatorParty entity 51116B for each Party package 51182A. TheTaxOperatorParty entity 51116B includes an Address entity 51124B and aContactPerson entity 51132B at the fourth level 51108. The Addressentity 51124B is of a type GDT 51128B “Address” 51130B. There is zero orone 51126B Address entity 51124B for a TaxOperatorParty entity 51116B.The ContactPerson entity 51132B is of a type GDT 51136B “ContactPerson”51138B. There is one 51134B ContactPerson entity 51132B for aTaxOperatorParty entity 51116B. The ContactPerson entity 51132B includesan Address entity 51140B at the fifth level 51110. The Address entity51140B is of a type GDT 51144B “Address” 51146B. There is one 51142BAddress entity 51140B for a ContactPerson entity 51132B.

The Item package 51148B includes an Item entity 51150B at the thirdlevel 51106. The Item entity 51150B has a data type name“VatDeclarationItem” 51156B. There is any number of 51152B Item entity51150B for each Item package 51148B. The Item entity 51150B includes aTaxDeclarationAmountTypeCode entity 51158B, an Amount entity 51166B, anda Note entity 51174B at the fourth level 51108. TheTaxDeclarationAmountTypeCode entity 51158B is of a type GDT 51162B“TaxDeclarationAmountTypeCode” 51164B. There is one 51160BTaxDeclarationAmountTypeCode entity 51158B for an Item entity 51150B.The Amount entity 51166B is of a type GDT 51170B “Amount” 51172B. Thereis one 51168B Amount entity 51166B for an Item entity 51150B. The Noteentity 51174B is of a type GDT 51178B “Note” 51180B. There is zero orone 51176B Note entity 51174B for an Item entity 51150B.

The message data type element structure for the VAT Declaration Requestmessage is depicted in FIG. 512A. The element structure is similar tothe data model, but provides additional information regarding thedetails of the interface. The element structure identifies the differentpackages 51200 in the interface, and represents the entities at variouslevels within the interface. As depicted in FIG. 512A, the interface forVATDeclarationRequestMessage includes five levels 51202, 51204, 51206,51208, and 51210. The outermost package of this interface is aVATDeclarationRequestMessage package 51216, which includes aVATDeclarationRequestMessage entity 51218 at the first level 51202. TheVATDeclarationRequestMessage entity 51218 is of a type MDT 51220“VATDeclarationRequestMessage” 51222. The VATDeclarationRequestMessagepackage 51216 includes a MessageHeader package 51224 and aVatDeclaration package 51250.

The MessageHeader entity 51226 is of a type GDT 51230“BusinessDocumentMessageHeader” 51232. There is zero or one 51228MessageHeader entity 51226 for each MessageHeader package 51224. TheMessageHeader entity 51226 includes an ID entity 51234 and aCreationDateTime entity 51242. The ID entity 51234 is of a type GDT51238 “BusinessDocumentMessageID” 51240. There is one 51236 ID entity51234 for a MessageHeader entity 51226. The CreationDateTime entity51242 is of a type GDT 51246 “DateTime” 51248. There is one 51244CreationDateTime entity 51242 for a MessageHeader entity 51226.

The VATDeclaration package 51250 includes a VATDeclaration entity 51252at the second level 51204, a Party package 51224A, and an Item package51290A.

The VATDeclaration entity 51260 has a data type name“VATDeclarationRequest” 51258. There is one 51254 VATDeclaration entity51252 for each VATDeclaration package 51250. The VATDeclaration entity51252 includes an @actionCode entity 51260, an ID entity 51268, a Periodentity 51276, a PaymentAmount entity 51284, an AdvancePaymentAmountentity 51292, a TaxDueClearingIndicator entity 51200A, aCollectionAuthorisationRevocationIndicator entity 51208A, and a Noteentity 51216A at the third level 51106.

The @actionCode entity 51260 is of a type GDT 51264 “ActionCode” 51266.There is one 51262 @actionCode entity 51260 for a VATDeclaration entity51252.

The ID entity 51268 is of a type GDT 51272“BusinessTransactionDocumentID” 51274. There is one 51270 ID entity51268 for a VATDeclaration entity 51252.

The Period entity 51276 is of a type GDT 51280 “DatePeriod” 51282. Thereis one 51278 Period entity 51276 for a VATDeclaration entity 51252. ThePaymentAmount entity 51284 is of a type GDT 51288 “Amount” 51290. Thereis one 51286 PaymentAmount entity 51284 for a VATDeclaration entity51252. The AdvancePaymentAmount entity 51292 is of a type GDT 51296“Amount” 51298. There is zero or one 51294 AdvancePaymentAmount entity51292 for a VATDeclaration entity 51252. The TaxDueClearingIndicatorentity 51200A is of a type GDT 51204A “DueClearingIndicator” 51206A.There is one 51202A TaxDueClearingIndicator entity 51200A for aVATDeclaration entity 51252. TheCollectionAuthorisationRevocationIndicator entity 51208A is of a typeGDT 51212A “RevocationIndicator” 51214A. There is one 51210ACollectionAuthorisationRevocationIndicator entity 51208A for aVATDeclaration entity 51252. The Note entity 51216A is of a type GDT51220A “Note” 51222A. There is zero or one 51218A Note entity 51216A fora VATDeclaration entity 51252.

The Party package 51224A includes a TaxPayerParty entity 51226A, aTaxAuthorityParty entity 51250A, and a TaxOperatorParty entity 51258A atthe third level 51206. The TaxPayerParty entity 51226A is of a type GDT51230A “BusinessTransactionDocumentParty” 51232A. There is one 51228ATaxPayerParty entity 51226A for each Party package 51224A. TheTaxPayerParty entity 51226A includes a TaxID entity 51234A and anAddress entity 51242A at the fourth level 51208.

The TaxID entity 51234A is of a type GDT 51238A “PartyTaxID” 51240A.There is one 51236A TaxID entity 51234A for a TaxPayerParty entity51226A.

The Address entity 51242A is of a type GDT 51246A “Address” 51248A.There is zero or one 51244A Address entity 51242A for a TaxPayerPartyentity 51226A.

The TaxAuthorityParty entity 51250A is of a type GDT 51254A“TaxAuthorityParty” 51256A. There is one 51252A TaxAuthorityParty entity51250A for each Party package 51224A.

The TaxOperatorParty entity 51258A is of a type GDT 51262A“BusinessTransactionDocumentParty” 51264A. There is zero or one 51260ATaxOperatorParty entity 51258A for each Party package 51224A. TheTaxOperatorParty entity 51258A includes an Address entity 51266A and aContactPerson entity 51274A at the fourth level 51208. The Addressentity 51266A is of a type GDT 51270A “Address” 51272A. There is zero orone 51268A Address entity 51266A for a TaxOperatorParty entity 51258A.The ContactPerson entity 51274A is of a type GDT 51278A “ContactPerson”51280A. There is one 51276A ContactPerson entity 51274A for aTaxOperatorParty entity 51258A. The ContactPerson entity 51274A includesan Address entity 51282A at the fifth level 51210. The Address entity51282A is of a type GDT 51286A “Address” 51288A. There is one 51284AAddress entity 51282A for a ContactPerson entity 51274A.

The Item package 51290A includes an Item entity 51292A at the thirdlevel 51206. The Item entity 51292A has a data type name“VatDeclarationItem” 51298A. There is any number of 51294A Item entity51292A for each Item package 51290A. The Item entity 51292A includes aTaxDeclarationAmountTypeCode entity 51200B, an Amount entity 51208B, anda Note entity 51216B at the fourth level 51208.

The TaxDeclarationAmountTypeCode entity 51200B is of a type GDT 51204B“TaxDeclarationAmountTypeCode” 51206B. There is one 51202BTaxDeclarationAmountTypeCode entity 51200B for an Item entity 51292A.The Amount entity 51208B is of a type GDT 51212B “Amount” 51214B. Thereis one 51210B Amount entity 51208B for an Item entity 51292A.

The Note entity 51216B is of a type GDT 51220B “Note” 51222B. There iszero or one 51218B Note entity 51216B for an Item entity 51292A.

The message data type element structure for the VAT DeclarationConfirmation message is depicted in FIG. 513A. The element structure issimilar to the data model, but provides additional information regardingthe details of the interface. The element structure identifies thedifferent packages 51300 in the interface, and represents the entitiesat various levels within the interface. As depicted in FIG. 513A, theinterface for VATDeclarationConfirmationMessage includes five levels51302, 51304, 51306, 51308, and 51310. The outermost package of thisinterface is a VATDeclarationConfirmationMessage package 51316, whichincludes a VATDeclarationConfirmationMessage entity 51318 at the firstlevel 51302. The VATDeclarationConfirmationMessage entity 51318 is of atype MDT 51320 “VATDeclarationConfirmationMessage” 51322.

The VATDeclarationConfirmationMessage package 51316 includes aMessageHeader package 51324 and a VATDeclaration package 51358. TheMessageHeader package 51324 includes a MessageHeader entity 51326 at thesecond level 51304. The MessageHeader entity 51326 is of a type GDT51330 “MessageHeader” 51332. There is zero or one 51328 MessageHeaderentity 51326 for each MessageHeader package 51324. The MessageHeaderentity 51326 includes an ID entity 51334, a ReferenceID entity 51342,and a CreationDateTime entity 51350. The ID entity 51334 is of a typeGDT 51338 “BusinessDocumentMessageID” 51340. There is one 51336D entity51334 for a MessageHeader entity 51326. The ReferenceID entity 51342 isof a type GDT 51346 “BusinessDocumentMessageID” 51348. There is zero orone 51344 ReferenceID entity 51342 for a MessageHeader entity 51326. TheCreationDateTime entity 51350 is of a type GDT 51354 “DateTime” 51356.There is one 51352 CreationDateTime entity 51350 for a MessageHeaderentity 51326.

The VATDeclaration package 51358 includes a VATDeclaration entity 51360at the second level 51304, a Log package 51392, and a Party package51334A.

The VATDeclaration entity 51360 has a data type name“VATDeclarationConfirmation” 51366. There is one 51362 VATDeclarationentity 51360 for each VATDeclaration package 51358. The VATDeclarationentity 51360 includes an ID entity 51368, a Period entity 51376, and anAcceptanceStatusCode entity 51384 at the third level 51306.

The ID entity 51368 is of a type GDT 51372“BusinessTransactionDocumentID” 51374. There is zero or one 51370Dentity 51368 for a VATDeclaration entity 51360.

The Period entity 51376 is of a type GDT 51380 “DatePeriod” 51382. Thereis zero or one 51378 Period entity 51376 for a VATDeclaration entity51360. The AcceptanceStatusCode entity 51384 is of a type GDT 51388“AcceptanceStatusCode” 51390. There is one 51386 AcceptanceStatusCodeentity 51384 for a VATDeclaration entity 51360.

The Log package 51392 includes a ValidationLog entity 51394 at the thirdlevel 51306. The ValidationLog entity 51394 has a data type name“VATDeclarationValidationLog” 51300A. There is zero or one 51396ValidationLog entity 51394 for each Log package 51392. The ValidationLogentity 51394 includes an Item entity 51302A at the fourth level 51308.The Item entity 51302A is of a type GDT 51306A “LogItem” 51308A. Thereis any number of 51304A Item entity 51302A for a ValidationLog entity51394. The Item entity 51302A includes a TypeID entity 51310A, aSeverityCode entity 51318A, and a Note entity 51326A at the fifth level51310. The TypeID entity 51310A is of a type CCT 51314A “Identifier”51316A. There is zero or one 51312A TypeID entity 51310A for an Itementity 51302A. The SeverityCode entity 51318A is of a type GDT 51322A“LogItemSeverityCode” 51324A. There is zero or one 51320A SeverityCodeentity 51318A for an Item entity 51302A. The Note entity 51326A is of atype GDT 51330A “Note” 51332A. There is one 51328A Note entity 51326Afor an Item entity 51302A.

The Party package 51334A includes a TaxPayerParty entity 51336A, aTaxAuthorityParty entity 51360A, and a TaxOperatorParty entity 51368A atthe third level 51306. The TaxPayerParty entity 51336A is of a type GDT51340A “BusinessTransactionDocumentParty” 51342A. There is one 51338ATaxPayerParty entity 51336A for each Party package 51334A. TheTaxPayerParty entity 51336A includes a TaxID entity 51344A and anAddress entity 51352A at the fourth level 51392A. The TaxID entity51344A is of a type GDT 51348A “PartyTaxID” 51350A. There is one 51346ATaxID entity 51344A for a TaxPayerParty entity 51336A. The Addressentity 51352A is of a type GDT 51356A “Address” 51358A. There is zero orone 51354A Address entity 51352A for a TaxPayerParty entity 51336A.

The TaxAuthorityParty entity 51360A is of a type GDT 51364A“TaxAuthorityParty” 51366A. There is one 51362A TaxAuthorityParty entity51360A for each Party package 51334A. The TaxOperatorParty entity 51368Ais of a type GDT 51372A “BusinessTransactionDocumentParty” 51374A. Thereis zero or one 51370A TaxOperatorParty entity 51368A for each Partypackage 51334A. The TaxOperatorParty entity 51368A includes an Addressentity 51376A and a ContactPerson entity 51384A at the fourth level51308. The Address entity 51376A is of a type GDT 51380A “Address”51382A. There is zero or one 51378A Address entity 51376A for aTaxOperatorParty entity 51368A. The ContactPerson entity 51384A is of atype GDT 51388A “ContactPerson” 51390A. There is one 51386AContactPerson entity 51384A for a TaxOperatorParty entity 51368A. TheContactPerson entity 51384A includes an Address entity 51392A at thefifth level 51310. The Address entity 51392A is of a type GDT 51396A“Address” 51398A. There is one 51394A Address entity 51392A for aContactPerson entity 51384A.

Variations of the subject matter described herein and all of thefunctional operations described in this specification can be implementedin digital electronic circuitry, or in computer software, firmware, orhardware, including the structures disclosed in this specification andtheir structural equivalents, or in combinations of one or more of them.Variations of the subject matter described herein can be implemented asone or more computer program products, i.e., one or more modules ofcomputer program instructions encoded on a computer-readable medium forexecution by, or to control the operation of, data processing apparatus.The computer-readable medium can be a machine-readable storage device, amachine-readable storage substrate, a memory device, a composition ofmatter effecting a machine-readable propagated signal, or a combinationof one or more them. The term “data processing apparatus” encompassesall apparatus, devices, and machines for processing data, including byway of example a programmable processor, a computer, or multipleprocessors or computers. The apparatus can include, in addition tohardware, code that creates an execution environment for the computerprogram in question, e.g., code that constitutes processor firmware, aprotocol stack, a database management system, an operating system, or acombination of one or more of them. A propagated signal is anartificially generated signal, e.g., a machine-generated electrical,optical, or electromagnetic signal, that is generated to encodeinformation for transmission to suitable receiver apparatus.

A computer program (also known as a program, software, softwareapplication, script, or code) can be written in any form of programminglanguage, including compiled or interpreted languages, and it can bedeployed in any form, including as a stand-alone program or as a module,component, subroutine, or other unit suitable for use in a computingenvironment. A computer program does not necessarily correspond to afile in a file system. A program can be stored in a portion of a filethat holds other programs or data (e.g., one or more scripts stored in amarkup language document), in a single file dedicated to the program inquestion, or in multiple coordinated files (e.g., files that store oneor more modules, sub-programs, or portions of code). A computer programcan be deployed to be executed on one computer or on multiple computersthat are located at one site or distributed across multiple sites andinterconnected by a communication network.

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application-specific integrated circuit).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read-only memory ora random access memory or both. The essential elements of a computer area processor for performing instructions and one or more memory devicesfor storing instructions and data. Generally, a computer will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,magnetic, magneto-optical disks, or optical disks. However, a computerneed not have such devices. Moreover, a computer can be embedded inanother device, e.g., a mobile telephone, a personal digital assistant(PDA), a mobile audio player, a Global Positioning System (GPS)receiver, to name just a few. Computer-readable media suitable forstoring computer program instructions and data include all forms ofnon-volatile memory, media and memory devices, including by way ofexample semiconductor memory devices, e.g., EPROM, EEPROM, and flashmemory devices; magnetic disks, e.g., internal hard disks or removabledisks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Theprocessor and the memory can be supplemented by, or incorporated in,special purpose logic circuitry.

To provide for interaction with a user, variations of the subject matterdescribed herein can be implemented on a computer having a displaydevice, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display)monitor, for displaying information to the user and a keyboard and apointing device, e.g., a mouse or a trackball, by which the user canprovide input to the computer. Other kinds of devices can be used toprovide for interaction with a user as well; for example, feedbackprovided to the user can be any form of sensory feedback, e.g., visualfeedback, auditory feedback, or tactile feedback; and input from theuser can be received in any form, including acoustic, speech, or tactileinput.

Variations of the subject matter described herein can be implemented ina computing system that includes a back-end component, e.g., as a dataserver, or that includes a middleware component, e.g., an applicationserver, or that includes a front-end component, e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the subject matter describedherein, or any combination of one or more such back-end, middleware, orfront-end components. The components of the system can be interconnectedby any form or medium of digital data communication, e.g., acommunication network. Examples of communication networks include alocal area network (“LAN”) and a wide area network (“WAN”), e.g., theInternet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

Although a few variations have been described in detail above, othermodifications are possible. For example, the logic flow depicted in theaccompanying figures and described herein do not require the particularorder shown, or sequential order, to achieve desirable results. Otherembodiments may be within the scope of the following claims.

1. A computer-implemented method of generating a request forcancellation of an accounting, the method comprising: generating anelectronic message by a first application, the first applicationexecuting in a landscape of computer systems providing message-basedservices, wherein the message comprises an accounting cancellationpackage containing: an accounting cancellation entity identifying afirst document that characterizes cancellation of an accounting, andidentifying a type of a second document characterizing postinginformation previously sent and to be canceled; and a businesstransaction document reference package containing a reference entityidentifying the second document; and initiating transmission of themessage to a second application to request cancellation of theaccounting.
 2. A method as in claim 1, wherein the accountingcancellation package further contains: a note entity characterizing areason for the cancellation, and a date entity characterizing a date onwhich the cancellation is to be entered.
 3. A computer-implementedmethod of responding to a request to cancel an accounting, the methodcomprising: receiving an electronic message including an accountingcancellation package in a landscape of computer systems providingmessage-based services, wherein the message comprises the accountingcancellation package containing: an accounting cancellation entityidentifying a first document that characterizes cancellation of anaccounting, and identifying a type of a second document characterizingposting information previously sent and to be canceled; and a businesstransaction document reference package containing a reference entityidentifying the second document; and initiating cancellation of theaccounting of the posting information identified by the referenceentity.
 4. A computer-implemented method of generating a request for abank account statement, the method comprising: generating an electronicmessage by a first application, the first application executing in alandscape of computer systems providing message-based services, whereinthe message comprises: a bank account statement package containing: abank account statement entity characterizing a statement of a bankregarding turnovers on a customer bank account; a bank account packagecontaining information characterizing a bank account: a bank accountstatement item package containing: an item entity characterizing asingle turnover on a bank account; a payment explanation packagecontaining information characterizing payments in a bank accountstatement and containing: a payment difference explanation packagecontaining information characterizing documents relating to payments ina bank account statement; and initiating transmission of the message toa second application to generate a request for a bank account statement5. A method as in claim 4, wherein the bank account statement packagefurther contains: a party package containing: a payment transactioninitiator party entity characterizing a party that initiated a payment;a payment transaction destination party entity characterizing a partythat receives payment in case of a bank transfer or whose account isdebited in case of a direct debit; an original payment transactioninitiator party entity characterizing a party executing a paymenttransaction; and a final payment transaction destination party entitycharacterizing a party to receive a payment or to be debited; a bankaccount statement bank account package containing: a payment transactioninitiator bank account entity characterizing a bank account of a partyinitiating a payment transaction; and a payment transaction destinationbank account characterizing a bank account of a party receiving apayment or to be debited; a business transaction document referencepackage containing: a payment reference entity characterizing a documentfrom a payment transaction initiator; a payment order reference entitycharacterizing a payment order by a payment transaction initiator; acheck reference entity characterizing a check number; and a bill ofexchange reference entity characterizing a bill of exchange number;wherein the payment explanation package contains: a payment explanationitem characterizing a payment amount; a payment explanation partypackage containing: an original payment transaction initiator partyentity characterizing an original party on behalf of which a paymenttransaction is executed; and a final payment transaction destinationparty characterizing a party on behalf of which a payment is received ordebited; and a business document object reference package containing: apayment explanation payment transaction initiator invoice referenceentity characterizing an invoice of a transaction initiator; a paymentexplanation payment transaction destination invoice reference entitycharacterizing an invoice of a party receiving a payment or beingdebited; a payment explanation payment transaction initiator contractreference entity characterizing a contract of a transaction initiator; apayment explanation payment transaction destination contract referenceentity characterizing a contract of a party receiving a payment or beingdebited; a payment explanation payment transaction initiator purchaseorder reference entity characterizing a purchase order of a transactioninitiator; and a payment explanation payment transaction destinationpurchase order reference entity characterizing a reference to a purchaseorder of a party receiving a payment or being debited; and wherein thepayment difference explanation package contains: a payment differenceexplanation item entity characterizing differences between expected andactual payment amounts; and a business document object reference packagecontaining: a payment difference explanation payment transactioninitiator invoice reference entity characterizing an invoice of atransaction initiator; a payment difference explanation paymenttransaction destination invoice reference entity characterizing aninvoice of a party receiving a payment or being debited; a paymentdifference explanation payment transaction initiator contract referenceentity characterizing a contract of a transaction initiator; a paymentdifference explanation payment transaction destination contractreference entity characterizing a contract of a party receiving apayment or being debited; a payment difference explanation paymenttransaction initiator purchase order reference entity characterizing apurchase order of a transaction initiator; and a payment differenceexplanation payment transaction destination purchase order referenceentity characterizing a reference to a purchase order of a partyreceiving a payment or being debited.
 6. A computer-implemented methodof generating a request for a bank account statement, the methodcomprising: receiving an electronic message in a landscape of computersystems providing message-based services, wherein the message comprises:a bank account statement package containing: a bank account statemententity characterizing a statement of a bank regarding turnovers on acustomer bank account; a bank account package containing informationcharacterizing a bank account: a bank account statement item packagecontaining: an item entity characterizing a single turnover on a bankaccount; a payment explanation package containing informationcharacterizing payments in a bank account statement and containing: apayment difference explanation package containing informationcharacterizing documents relating to payments in a bank accountstatement; and initiating generation of a request for a bank accountstatement.
 7. A computer-implemented method of generating a request forbank account balances for a time period for a group of bank accounts,the method comprising: generating an electronic message by a firstapplication, the first application executing in a landscape of computersystems providing message-based services, wherein the message comprisesa bank account balance report query package containing: a bank accountbalance report query entity characterizing a request for balanceinformation for a bank account; a bank account package containinginformation characterizing a bank account for which requests are to bemade, wherein the bank account package contains a bank account entitycharacterizing the bank account for which balance information is to beascertained; and an item package containing information characterizingcriteria that are relevant for determining bank account balances,wherein the item package contains: a bank account balance report queryitem entity characterizing criteria for determining bank accountbalances, wherein the bank account balance report query item entitycontains: a bank account balance type code characterizing a type of abank account balance; and a date period entity identifying a period forwhich the bank account balances are to be taken into consideration; andinitiating transmission of the message to a second application torequest bank account balances for a time period.
 8. A method as in claim7, wherein the bank account package further contains: a bank accountdifferentiator entity characterizing a difference between accounts thatare managed under a single account number, wherein the bank accountdifferentiator entity contains a bank account differentiator IDcharacterizing a unique identifier to differentiate between bankaccounts.
 9. A computer-implemented method of responding to a requestfor bank account balances for a time period for a group of bankaccounts, the method comprising: receiving an electronic messageincluding a bank account balance report query package in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises a bank account balance report query package containing: a bankaccount balance report query entity characterizing a request for balanceinformation for a bank account; a bank account package containinginformation characterizing the bank account for which requests are to bemade, wherein the bank account package contains a bank account entitycharacterizing a bank account for which balance information is to beascertained; and an item package containing information characterizingcriteria that are relevant for determining bank account balances,wherein the item package contains: a bank account balance report queryitem entity characterizing criteria for determining bank accountbalances, wherein the bank account balance report query item entitycontains: a bank account balance type code characterizing a type of abank account balance; and a date period entity identifying a period forwhich the bank account balances are to be taken into consideration; andinitiating a request for bank account balances for a time period.
 10. Acomputer-implemented method of generating a response to a request forbank account balances for a time period for a group of bank accounts,the method comprising: generating an electronic message by a firstapplication, the first application executing in a landscape of computersystems providing message-based services, wherein the message comprisesa bank account balance report package containing a bank account balancereport entity containing information about balances of a bank account;and initiating transmission of the message to a second application torequest bank account balances.
 11. A method as in claim 10, wherein thebank account balance report package further contains: a log packagecontaining information characterizing log messages that are issued whenbank account balances are determined wherein the log package contains alog entity characterizing a sequence of log messages issued by anapplication while executing a task; a bank account package containinginformation characterizing information about a bank account for whichrequests are made, wherein the bank account package contains: a bankaccount entity characterizing a bank account to which balanceinformation belongs, a bank account differentiator entity characterizingthe difference between accounts that are managed under one accountnumber, wherein the bank account differentiator entity contains a bankaccount differentiator ID characterizing a unique identifier todifferentiate between bank accounts; and a bank account balance packagecontaining information characterizing bank account balances, wherein thebank account balance package contains a bank account balance entitycontaining bank account balances.
 12. A computer-implemented method ofresponding to a request for bank account balances for a time period fora group of bank accounts, the method comprising: receiving an electronicmessage including a bank account balance report package in a landscapeof computer systems providing message-based services, wherein themessage comprises a bank account balance report package containing abank account balance report entity containing information about balancesof a bank account; and initiating transmission of the requested bankaccount balances.
 13. A computer-implemented method of generating arequest to recognize a business document, the method comprising:generating an electronic message by a first application, the firstapplication executing in a landscape of computer systems providingmessage-based services, wherein the message comprises a businesstransaction document image recognition package containing: a businesstransaction document image recognition request entity characterizing arequest for a digitized business document to be recognized; anattachment package containing an attachment entity identifying thedigitized business document; and initiating transmission of the messageto a second application to request the recognition of business documentdata in the digitized business document.
 14. A computer-implementedmethod of responding to a request to recognize a business document, themethod comprising: receiving an electronic message including a businesstransaction document image recognition package in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises the business transaction document image recognition packagecontaining: a business transaction document image recognition requestentity characterizing a request for a digitized business document to berecognized; an attachment package containing an attachment entityidentifying the digitized business document; and initiating recognitionof business document data in the digitized business document.
 15. Acomputer-implemented method of generating a request to change, create,or delete items in a catalogue, the method comprising: generating anelectronic message by a first application, the first applicationexecuting in a landscape of computer systems providing message-basedservices, wherein the message comprises: a catalogue publicationtransmission package, the catalogue publication transmission packagecontaining: a catalogue entity characterizing a structured directory ofcatalogue items; and initiating transmission of the message to a secondapplication to generate a request to change, create, or delete items ina catalogue.
 16. A method as in claim 15, wherein the cataloguepublication transmission package further contains: a content packagecontaining: a content entity characterizing a list of items to bechanged, created, or read; a catalogue item package containing: acatalogue item entity characterizing information about a catalogue itemrequired to change, create, or delete it; a catalogue item descriptionentity characterizing an item in various locales; a catalogueclassification entity characterizing a classification of a catalogueitem; a property valuation entity characterizing a value of a propertyassociated with a catalogue item; and a catalogue item relationshipentity characterizing a relationship between two catalogue items; and acatalogue view package containing: a catalogue view entitycharacterizing a restricted subset of a catalogue; and a catalogue viewitem entity characterizing a catalogue item to be included in acatalogue view; and wherein the message further comprises: atransmission information package containing information characterizing atransmission of an object contained in the message.
 17. Acomputer-implemented method of generating a request to change, create,or delete items in a catalogue, the method comprising: receiving anelectronic message in a landscape of computer systems providingmessage-based services, wherein the message comprises: a cataloguepublication transmission package, the catalogue publication transmissionpackage containing: a catalogue entity characterizing a structureddirectory of catalogue items; and initiating a generation of a requestto change, create, or delete items in a catalogue.
 18. Acomputer-implemented method of generating a confirmation to a request tochange, create, or delete items in a catalogue, the method comprising:generating an electronic message by a first application, the firstapplication executing in a landscape of computer systems providingmessage-based services, wherein the message comprises: a cataloguepublication transmission package, the catalogue publication transmissionpackage containing: a catalogue publication transmission entitycharacterizing information required to confirm whether items in acatalogue request can be changed, created, or deleted; and a cataloguepackage containing: a catalogue entity characterizing a catalogue ofitems which can be changed, created, or deleted; and initiatingtransmission of the message to a second application to generate aconfirmation to a request to change, create, or delete items in acatalogue.
 19. A computer-implemented method of generating aconfirmation to a request to change, create, or delete items in acatalogue, the method comprising: receiving an electronic message in alandscape of computer systems providing message-based services, whereinthe message comprises: a catalogue publication transmission package, thecatalogue publication transmission package containing: a cataloguepublication transmission entity characterizing information required toconfirm whether items in a catalogue request can be changed, created, ordeleted; and a catalogue package containing: a catalogue entitycharacterizing a catalogue of items which can be changed, created, ordeleted; and initiating a generation of a confirmation to a request tochange, create, or delete items in a catalog.
 20. A computer-implementedmethod of generating a request to carry out one or more paymenttransactions, the method comprising: generating an electronic message bya first application, the first application executing in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises a collective payment order package containing: a collectivepayment order entity characterizing an instruction to a creditinstitution to carry out one or more payment transactions; and a paymentorder package containing a payment order entity characterizing one ormore instructions to a credit institution to carry out a paymenttransaction, and a net amount entity identifying a payment amountassociated with the payment order entity; and initiating transmission ofthe message to a second application to carry out the one or more paymenttransactions.
 21. A method as in claim 20, wherein the collectivepayment order package further contains: a party package containinginformation characterizing information concerning parties involved inthe payment transaction; and wherein the party package further contains:a payment transaction initiator party entity characterizing a party thatinitiated the payment; and a bank account package containing informationcharacterizing information concerning banking details of a paymenttransaction initiator; and wherein the bank account package furthercontains: a payment transaction initiator bank account entitycharacterizing a bank account of the payment transaction initiator, anda bank charges bank account entity characterizing a bank account to bedebited with bank charges for a collective payment order; and whereinthe payment order package further contains: a party package containinginformation characterizing a destination party, wherein the partypackage further contains: a payment transaction destination party entitycharacterizing a party that receives the payment or a party that has anaccount debited, an original payment transaction initiator party entitycharacterizing the party for which a payment order is executed, a finalpayment transaction destination party entity characterizing the partythat receives the payment or the party that has an account debited; anda bank account package containing information characterizing bankingdetails for the destination party of the payment transaction, whereinthe bank account package further contains a destination bank accountentity characterizing a bank account of the destination party for thepayment transaction; and a payment instruction package containinginformation characterizing information for participating banksconcerning payment transaction execution, wherein the paymentinstruction package further contains: a payment instruction entitycharacterizing an instruction to the executing bank related to thepayment order, a correspondence bank details entity characterizingdetails from a bank of a correspondence bank to be used for forwardingthe payment order, wherein the correspondence bank details entityfurther contains: a correspondence bank type element characterizing atype of correspondence bank, a bank element characterizing an identifierfor the correspondence bank, a bank account element characterizing acorrespondence bank account; and a central bank report packagecontaining information characterizing legal reporting information andrequirements, wherein the state central bank report package furthercontains a central bank report item entity characterizing information tosatisfy the legal reporting to the state central bank and a requirementfor payments to foreign payees; and a business transaction documentreference package containing information characterizing references todifferent documents involved in the payment transaction, wherein thebusiness transaction document reference package further contains: apayment reference entity characterizing a reference to a paymentdocument of a payer representing an actual payment, a check referenceentity characterizing a reference to a check used for the payment, abill of exchange reference entity characterizing a reference to a billof exchange used for the payment; and a payment explanation packagecontaining information characterizing an explanation for the purpose andthe amount of the payment, wherein the payment explanation packagefurther contains a payment explanation item entity characterizing apayment amount for a payee.
 22. A computer-implemented method ofresponding to a request to carry out one or more payment transactions,the method comprising: receiving an electronic message including acollective payment order package in a landscape of computer systemsproviding message-based services, wherein the message comprises thecollective payment order package containing: a collective payment orderentity characterizing an instruction to a credit institution to carryout one or more payment transactions; and a payment order packagecontaining a payment order entity characterizing one or moreinstructions to a credit institution to carry out a payment transaction,and a net amount entity identifying a payment amount associated with thepayment order entity; and initiating recording of the result of thepayment transactions to the payment transaction initiator's account. 23.A computer-implemented method of generating a notification regardingpayment behavior of a business partner, the method comprising:generating an electronic message by a first application, the firstapplication executing in a landscape of computer systems providingmessage-based services, wherein the message contains: a credit paymentbehavior summary package, the credit payment behavior summary packagecontaining: a credit payment behavior summary message entitycharacterizing key figures regarding payment behavior of a businesspartner; and a party package containing information characterizinginformation about parties relevant to the payment behavior of thebusiness party; and initiating transmission of the message to a secondapplication to provide notification of the payment behavior of thebusiness partner.
 24. A method as in claim 23, wherein the party packagecontains: a debtor party entity characterizing a debtor party having apayment obligation; a creditor party entity characterizing a party thatowns a receivable due from the debtor party; and a seller party entitycharacterizing a party that has sold a product to the debtor party; andwherein the message further contains: a product information packagecontaining information characterizing information about the product soldto the debtor party, the product information package containing: apayment information package containing information characterizinginformation about the payment behavior of the debtor party, the paymentinformation package containing: a last payment entity characterizing alast payment received from the debtor party; an oldest open item entitycharacterizing an oldest open item of the debtor party; and a maximumlevel dunned open item entity characterizing an open item of the debtorparty having a highest dunning level.
 25. A computer-implemented methodof responding to a notification of payment behavior of a businesspartner, the method comprising: receiving an electronic message in alandscape of computer systems providing message-based services, whereinthe message comprises: a credit payment behavior summary package, thecredit payment behavior summary package containing: a credit paymentbehavior summary message entity characterizing key figures regardingpayment behavior of a business partner; and a party package containinginformation characterizing information about parties relevant to thepayment behavior of the business party; and initiating a notification ofthe payment behavior of the business partner.
 26. A computer-implementedmethod of generating a query regarding creditworthiness of a party, themethod comprising: generating an electronic message by a firstapplication, the first application executing in a landscape of computersystems providing message-based services, wherein the message comprises:a credit worthiness query package containing: a credit worthiness entitycharacterizing a query regarding creditworthiness of a party; and aparty package containing: a debtor party entity characterizing a partyfor whom creditworthiness information is to be provided; and initiatingtransmission of the message to a second application to generate a queryregarding creditworthiness of a party.
 27. A method as in claim 26,wherein the party package further contains: a creditor party entitycharacterizing a party that owns a receivable due from a debtor; and aseller party entity characterizing a party that sells or plans to sell aproduct to a debtor; and wherein the credit worthiness query packagefurther contains: a product information package containing informationcharacterizing a product category of a product sold or to be sold to adebtor.
 28. A computer-implemented method of generating a queryregarding creditworthiness of a party, the method comprising: receivingan electronic message in a landscape of computer systems providingmessage-based services, wherein the message comprises: a creditworthiness query package containing: a credit worthiness entitycharacterizing a query regarding creditworthiness of a party; and aparty package containing: a debtor party entity characterizing a partyfor whom creditworthiness information is to be provided; and initiatinga query regarding creditworthiness of a party.
 29. Acomputer-implemented method of generating a response to a queryregarding creditworthiness of a party, the method comprising: generatingan electronic message by a first application, the first applicationexecuting in a landscape of computer systems providing message-basedservices, wherein the message comprises: a credit worthiness querypackage containing: a credit worthiness entity characterizing a queryregarding creditworthiness of a party; a party package containing: adebtor party entity characterizing a party for whom creditworthinessinformation is to be provided; and an information package containing: acredit rating entity characterizing a credit rating for a debtor party;and initiating transmission of the message to a second application togenerate a response to a query regarding creditworthiness of a party.30. A method as in claim 29, wherein the party package further contains:a creditor party entity characterizing a party that owns a receivabledue from a debtor; and a seller party entity characterizing a party thatsells or plans to sell a product to a debtor; and wherein the creditworthiness query package further contains: a product information packagecontaining information characterizing a product category of a productsold or to be sold to a debtor; and wherein the information packagefurther contains: a credit risk class entity characterizing a risk ofnon-payment by a debtor party; a credit limit entity characterizing acredit limit for a debtor party; and a credit exposure entitycharacterizing a level of a credit limit that has been consumed.
 31. Acomputer-implemented method of generating a response to a queryregarding creditworthiness of a party, the method comprising: receivingan electronic message in a landscape of computer systems providingmessage-based services, wherein the message comprises: a creditworthiness query package containing: a credit worthiness entitycharacterizing a query regarding creditworthiness of a party; a partypackage containing: a debtor party entity characterizing a party forwhom creditworthiness information is to be provided; and an informationpackage containing: a credit rating entity characterizing a creditrating for a debtor party; and initiating a response to a queryregarding creditworthiness of a party.
 32. A computer-implemented methodof exchanging information relating to a vendor declaration, the methodcomprising: generating an electronic message by a first application, thefirst application executing in a landscape of computer systems providingmessage-based services, wherein the message comprises: a customs vendordeclaration package containing information characterizing a declarationof products to be delivered, the customs vendor declaration packagecontaining: a customs vendor declaration entity characterizingspecifications made by a vendor associated with a product to bedelivered; and a party package containing information characterizingparties of a vendor declaration, the party package containing: a vendorparty entity characterizing a party that issues a vendor declaration fora product to be delivered; and a buyer party entity characterizing aparty that requires a vendor declaration for a product to be purchased;and initiating transmission of the message to a second application toexchange information relating to the vendor declaration.
 33. A method asin claim 32, wherein the customs vendor declaration package furthercontains: an attachment package containing information characterizing adocument referring to the customs vendor declaration entity; and acustoms vendor declaration item package containing informationcharacterizing a product to be delivered, wherein the customs vendordeclaration item package contains: an item entity characterizingspecifications provided by a vendor associated with a product to bedelivered; a product information package characterizes informationassociated with a product; and a customs information packagecharacterizes information associated customs information associated witha product.
 34. A computer-implemented method of exchanging informationrelating to a vendor declaration, the method comprising: receiving anelectronic message in a landscape of computer systems providingmessage-based services, wherein the message comprises: a customs vendordeclaration package containing information characterizing a declarationof products to be delivered, the customs vendor declaration packagecontaining: a customs vendor declaration entity characterizingspecifications made by a vendor associated with a product to bedelivered; and a party package containing information characterizingparties of a vendor declaration, the party package containing: a vendorparty entity characterizing a party that issues a vendor declaration fora product to be delivered; and a buyer party entity characterizing aparty that requires a vendor declaration for a product to be purchased;and initiating an exchange of information relating to a vendordeclaration.
 35. A computer-implemented method of generating deliveryquantity and scheduling information, the method comprising: generatingan electronic message by a first application, the first applicationexecuting in a landscape of computer systems providing message-basedservices, wherein the message comprises: a delivery schedule packagecontaining: a delivery schedule entity characterizing delivery dates,products, quantities, and delivery locations; a delivery schedule partypackage containing: a vendor party entity characterizing a party todeliver goods described in a delivery schedule; an item packagecontaining: a business transaction document reference package containinginformation characterizing references to business documents relevant fora delivery schedule: a release package containing: a release entitycharacterizing an identification and validity of a release instancetransferred in a delivery schedule item; and a product informationpackage containing information characterizing goods to be delivered; andinitiating transmission of the message to a second application togenerate delivery quantity and scheduling information.
 36. A method asin claim 35, wherein the party package further contains: a buyer partyentity characterizing a party that buys goods or services; and a bill toparty entity characterizing a party that is billed for goods orservices; wherein the item package further contains: a deliveryinformation package containing: a previous delivery entitycharacterizing identification and validity of a last release instancepreviously transferred in a delivery schedule; and a cumulative deliveryentity characterizing identification and validity of instancespreviously transferred in a delivery schedule; a delivery schedule itemparty package containing: a buyer party entity characterizing a partythat buys the goods to be delivered; and a product recipient partyentity characterizing a party that receives a goods delivery; a locationpackage containing: a ship from location entity characterizing a placefrom which ordered goods are delivered; a trans-shipment location entitycharacterizing a location to which ordered products are trans-shipped enroute to a recipient; a ship to location entity characterizing a placeto which ordered goods are delivered; and a schedule line packagecontaining: a schedule line entity characterizing a statement aboutgoods to be delivered; and a confirmed schedule line entitycharacterizing a confirmation from a vendor party as terms of a deliveryof goods from a scheduling agreement.
 37. A computer-implemented methodof generating delivery quantity and scheduling information, the methodcomprising: receiving an electronic message in a landscape of computersystems providing message-based services, wherein the message comprises:a purchase request package containing: a purchase request entitycharacterizing requisition requirements; and a purchase request itempackage containing: a schedule line package characterizing quantity anddate information associated with a requisition; and initiating ageneration of delivery quantity and scheduling information.
 38. Acomputer-implemented method of generating delivery quantity andscheduling information, the method comprising: generating an electronicmessage by a first application, the first application executing in alandscape of computer systems providing message-based services, whereinthe message comprises: a delivery schedule package containing: adelivery schedule entity characterizing delivery dates, products,quantities, and delivery locations; a delivery schedule party packagecontaining: a vendor party entity characterizing a party to delivergoods described in a delivery schedule; an item package containing: abusiness transaction document reference package containing informationcharacterizing references to business documents relevant for a deliveryschedule: a release package containing: a release entity characterizingan identification and validity of a release instance transferred in adelivery schedule item; and a product information package containinginformation characterizing goods to be delivered; and initiatingtransmission of the message to a second application to generate deliveryquantity and scheduling information.
 39. A method as in claim 38,wherein the party package further contains: a buyer party entitycharacterizing a party that buys goods or services; and a bill to partyentity characterizing a party that is billed for goods or services;wherein the item package further contains: a delivery informationpackage containing: a previous delivery entity characterizingidentification and validity of a last release instance previouslytransferred in a delivery schedule; and a cumulative delivery entitycharacterizing identification and validity of instances previouslytransferred in a delivery schedule; a delivery schedule item partypackage containing: a buyer party entity characterizing a party thatbuys the goods to be delivered; and a product recipient party entitycharacterizing a party that receives a goods delivery; a locationpackage containing: a ship from location entity characterizing a placefrom which ordered goods are delivered; a trans-shipment location entitycharacterizing a location to which ordered products are trans-shipped enroute to a recipient; a ship to location entity characterizing a placeto which ordered goods are delivered; and a schedule line packagecontaining: a schedule line entity characterizing a statement aboutgoods to be delivered; and a confirmed schedule line entitycharacterizing a confirmation from a vendor party as terms of a deliveryof goods from a scheduling agreement.
 40. A computer-implemented methodof generating delivery quantity and scheduling information, the methodcomprising: receiving an electronic message in a landscape of computersystems providing message-based services, wherein the message comprises:a purchase request package containing: a purchase request entitycharacterizing requisition requirements; and a purchase request itempackage containing: a schedule line package characterizing quantity anddate information associated with a requisition; and initiating ageneration of delivery quantity and scheduling information.
 41. Acomputer-implemented method of generating a notification regarding ashipment event associated with a delivery of goods, the methodcomprising: generating an electronic message by a first application, thefirst application executing in a landscape of computer systems providingmessage-based services, wherein the message comprises: a deliverypackage containing: a delivery entity characterizing goods or acombination of goods to be made available for transportation; a locationpackage containing: a ship to location entity characterizing a place towhich goods are shipped; and an item package containing: an item entitycharacterizing a quantity of goods in a delivery; and a productinformation package containing information characterizing a product in adelivery item; and initiating transmission of the message to a secondapplication to generate a shipment notification regarding an eventassociated with a delivery of goods.
 42. A method as in claim 41,wherein the delivery package further contains: a handling unitcontaining information characterizing units of packaging materials andpackaged products; a delivery party package containing: a buyer partyentity characterizing a party that purchased goods specified in adelivery; a vendor party entity characterizing is a party that deliversgoods; a product recipient party characterizing is party to whom goodsare delivered; a carrier party entity characterizing a party thattransports goods; and a bill to party entity characterizing a party towhom an invoice for delivered goods is sent; a transport informationpackage containing: a transport means entity characterizing a transportmechanism for a delivery; and a transport tracking entity characterizinginformation tracking a status of a transport of a delivery; a deliveryinformation package containing information characterizing deliveryconditions related to a shipping notification; wherein the locationpackage further contains: a ship from location entity characterizing aplace from which goods are shipped; and a trans-shipment location entitycharacterizing a location at which goods are to be trans-shipped ontheir way to a recipient; and wherein the item package further contains:a business transaction document reference package containing: a purchaseorder reference entity characterizing a reference to a purchase order oran item in a purchase order; an origin purchase order reference entitycharacterizing a reference to an original purchase order or an itemwithin an original purchase order; a scheduling agreement referenceentity characterizing an outline agreement item; and a sales orderreference entity characterizing a reference to an item in a sales order;and a batch package containing information characterizing a batch in adelivery item.
 43. A computer-implemented method of generating anotification regarding a shipment event associated with a delivery ofgoods, the method comprising: receiving an electronic message in alandscape of computer systems providing message-based services, whereinthe message comprises: a delivery package containing: a delivery entitycharacterizing goods or a combination of goods to be made available fortransportation; a location package containing: a ship to location entitycharacterizing a place to which goods are shipped; and an item packagecontaining: an item entity characterizing a quantity of goods in adelivery; and a product information package containing informationcharacterizing a product in a delivery item; and initiating anotification regarding a shipment event associated with a delivery ofgoods.
 44. A computer-implemented method of generating a notificationregarding a receipt of a delivery of goods, the method comprising:generating an electronic message by a first application, the firstapplication executing in a landscape of computer systems providingmessage-based services, wherein the message comprises: a deliverypackage containing: a delivery entity characterizing a confirmation of areceipt of a delivery of goods; a party package containing: a vendorparty entity characterizing party that delivered goods or on whosebehalf goods were delivered; a location package containing informationcharacterizing a place to which goods were delivered; and an itempackage containing: an item entity characterizing a quantity of goodsthat were delivered; and a product information package containinginformation characterizing a delivered; and initiating transmission ofthe message to a second application to generate a notification regardinga receipt of a delivery of goods.
 45. A method as in claim 44, whereinthe party package further contains: a product recipient party entitycharacterizing a party that took delivery of goods; and wherein the itempackage further contains: a delivery information package containinginformation characterizing a delivery information for a delivery ofgoods.
 46. A computer-implemented method of generating a notificationregarding a receipt of a delivery of goods, the method comprising:receiving an electronic message in a landscape of computer systemsproviding message-based services, wherein the message comprises: adelivery package containing: a delivery entity characterizing goods or acombination of goods to be made available for transportation; a locationpackage containing: a ship to location entity characterizing a place towhich goods are shipped; and an item package containing: an item entitycharacterizing a quantity of goods in a delivery; and a productinformation package containing information characterizing a product in adelivery item; and initiating generation of a notification regarding areceipt of a delivery of goods.
 47. A computer-implemented method ofgenerating invoicing information associated with a business transaction,the method comprising: generating an electronic message by a firstapplication, the first application executing in a landscape of computersystems providing message-based services, wherein the message comprises:an invoice package containing: an invoice entity characterizing payablesand receivables for delivered goods and rendered services; an invoiceparty package containing: a bill to party entity characterizing a partyto which an invoice for deliveries received or services rendered issent; and a bill from party entity characterizing a party initiating anexecution of an invoice; and initiating transmission of the message to asecond application to generate invoicing information associated with abusiness transaction.
 48. A method as in claim 47, wherein the invoiceparty package further contains: an invoice buyer party entitycharacterizing a party authorizing deliveries or services; an invoiceseller party entity characterizing a party that sells goods or services;an invoice product recipient party entity characterizing a party to whomgoods are delivered or services are provided; an invoice vendor partyentity characterizing a party that delivers goods or provides services;an invoice manufacturer party entity characterizing a party thatproduces goods being invoiced; an invoice payer party entitycharacterizing a party that pays for goods or services; an invoice payeeparty entity characterizing a party that receives payment for goods orservices; and an invoice carrier party entity characterizing a partythat transports goods to be invoiced; wherein the invoice due packagefurther contains: a location package containing: a ship to locationentity characterizing a place to which goods are shipped or whereservices are provided; and a ship from location entity characterizing aplace from which goods are shipped; an invoice delivery informationpackage containing information characterizing delivery information forgoods being invoiced; an invoice payment information package containing:a cash discount terms entity characterizing terms of payment; and apayment form entity characterizing a payment form and required data forthe payment form; an invoice price information package containinginformation characterizing a total price to be settled for goods orservices to be invoiced; an invoice tax package containing informationcharacterizing tax price components in an invoice; an invoice attachmentpackage containing information characterizing attachment informationassociated with an invoice; an invoice description package containinginformation characterizing texts associated with an invoice; and aninvoice item package containing: an item entity characterizing pricinginformation and taxes for a quantity of product that has been deliveredor for a service that has been rendered; an item hierarchy relationshipentity characterizing hierarchical relationships between items; an itemproduct information package containing: a product entity characterizinga product in an invoice item; and a product category entitycharacterizing a category of a good or service that is being invoiced;an item price information package containing information characterizingan amount invoiced for goods delivered or services rendered; an item taxpackage containing information characterizing tax components in a totalamount invoiced for goods delivered or services rendered; an itempackage containing: an item buyer party entity characterizing a partyauthorizing deliveries or services; an item seller party entitycharacterizing a party that sells goods or services; an item productrecipient party entity characterizing a party to whom goods aredelivered or services are provided; an item vendor party entitycharacterizing a party that delivers goods or provides services; an itemmanufacturer party characterizing a party that produces goods beinginvoiced; and a carrier party entity characterizing a party thattransports goods to be invoiced; a business transaction documentreference package containing: a purchase order reference entitycharacterizing a purchase order or an item within a purchase order; asales order reference entity characterizing a sales order or an itemwithin a sales order; a delivery reference entity characterizing adelivery or an item within a delivery; a service acknowledgementreference entity characterizing a confirmation by a seller that aservice has been provided; an origin invoice reference entitycharacterizing a reference to an invoice previously sent; a purchasecontract reference entity characterizing a purchase contract or an itemwithin a purchase contract; a sales contract reference entitycharacterizing a sales contract or an item within a sales contract; abuyer product catalogue reference entity characterizing a productcatalogue of a buyer or an item within the catalogue; and a sellerproduct catalogue reference entity characterizing a product catalogue ofa seller or an item within the catalogue; an item attachment packagecontaining information characterizing attachment information associatedwith an invoice; an item description package containing informationcharacterizing texts associated with an invoice; and an item deliveryinformation package characterizing delivery information associated withan invoice.
 49. A method as in claim 48, wherein the item packagefurther contains: an accounting package containing informationcharacterizing an assignment of an invoice item net amount or partialamount to a set of account assignment objects.
 50. Acomputer-implemented method of generating invoicing informationassociated with a business transaction, the method comprising: receivingan electronic message in a landscape of computer systems providingmessage-based services, wherein the message comprises: an invoicepackage containing: an invoice entity characterizing payables andreceivables for delivered goods and rendered services; an invoice partypackage containing: a bill to party entity characterizing a party towhich an invoice for deliveries received or services rendered is sent;and a bill from party entity characterizing a party initiating anexecution of an invoice; and initiating a generation of invoicinginformation associated with a business transaction.
 51. Acomputer-implemented method of generating business transactioninformation, the method comprising: generating an electronic message bya first application, the first application executing in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises: an invoice due package containing: an invoice due entitycharacterizing details of a business transaction relevant for settlingthe business transaction; an invoice due party package containinginformation characterizing parties to a business transaction; an invoicedue location package containing information characterizing localesassociated with a business transaction; an invoice due deliveryinformation package containing information characterizing a delivery ofgoods associated with a business transaction; an invoice due paymentinformation package containing information characterizing payment termsfor a business transaction; an invoice due price information packagecontaining information characterizing a total price to be settled forgoods or services provided under a business transaction; an invoice dueaccount assignment package containing information characterizing accountassignment information associated with a business transaction; aninvoice due attachment package containing information characterizingattachment information associated with a settlement of a businesstransaction; an invoice due description package containing informationcharacterizing texts associated with a settlement of a businesstransaction; and an invoice due item package containing informationcharacterizing item information for a settlement of a businesstransaction; and initiating transmission of the message to a secondapplication to generate business transaction information.
 52. A methodas in claim 51, wherein the invoice due party package further contains:a buyer party entity characterizing a party that purchases goods orservices; a seller party entity characterizing a party that sells goodsor services; a product recipient party entity characterizing a party towhom goods are delivered or services are provided; a vendor party entitycharacterizing a party that delivers goods or provides services; a billto party entity characterizing a party to which an invoice for goods orservices is sent; a bill from party entity characterizing a party thatdraws up an invoice for goods or services; a payer party entitycharacterizing a party that pays for goods or services; and a payeeparty entity characterizing a party that receives payment for goods orservices; wherein the invoice due location package further contains: aship to location entity characterizing a place to which goods areshipped or where services are provided; and a ship from locationcharacterizing a place from which goods are shipped; and wherein theinvoice due payment information package further contains: a cashdiscount terms entity characterizing terms of payment; and a paymentform entity characterizing a payment form and required data for thepayment form.
 53. A method as in claim 51, wherein the item packagefurther contains: an item entity characterizing information from abusiness document item that is to be taken into account for a settlementof a business transaction; an item hierarchy relationship entitycharacterizing hierarchical relationships between items; an item productinformation package containing: a product entity characterizing aproduct for which an invoice is due; and a product category entitycharacterizing a category of a product or service that is beinginvoiced; an item price information package containing: a price entitycharacterizing an amount to be settled for a product or service; and aprocurement cost upper limit entity characterizing a quantity orvalue-based restriction placed on a product or service to be settled; abusiness transaction document reference package containing: a purchaseorder reference entity characterizing a purchase order or an item withina purchase order; a sales order reference entity characterizing a salesorder or an item within a sales order; a delivery reference entitycharacterizing a delivery or an item within a delivery; a purchasecontract reference entity characterizing a purchase contract or an itemwithin a purchase contract; a sales contract reference entitycharacterizing a sales contract or an item within a sales contract; abuyer product catalogue reference entity characterizing a productcatalogue of a buyer or an item within the catalogue; and a vendorproduct catalogue reference entity characterizing a product catalogue ofa vendor or an item within the catalogue; an item attachment packagecontaining information characterizing attachment information associatedwith a settlement of a business transaction; an item due descriptionpackage containing information characterizing texts associated with asettlement of a business transaction; and a delivery information packagecharacterizing delivery information associated with a businesstransaction.
 54. A computer-implemented method of generating businesstransaction information, the method comprising: receiving an electronicmessage in a landscape of computer systems providing message-basedservices, wherein the message comprises: an invoice due packagecontaining: an invoice due entity characterizing details of a businesstransaction relevant for settling the business transaction; an invoicedue party package containing information characterizing parties to abusiness transaction; an invoice due location package containinginformation characterizing locales associated with a businesstransaction; an invoice due delivery information package containinginformation characterizing delivery of goods associated with a businesstransaction; an invoice due payment information package containinginformation characterizing payment terms for a business transaction; aninvoice due price information package containing informationcharacterizing a total price to be settled for goods or servicesprovided under a business transaction; an invoice due account assignmentpackage containing information characterizing account assignmentinformation associated with a business transaction; an invoice dueattachment package containing information characterizing attachmentinformation associated with a settlement of a business transaction; aninvoice due description package containing information characterizingtexts associated with a settlement of a business transaction; and aninvoice due item package containing information characterizing iteminformation for a settlement of a business transaction; and initiating ageneration of business transaction information.
 55. Acomputer-implemented method of requesting a generation of a loancontract, the method comprising: generating an electronic message by afirst application, the first application executing in a landscape ofcomputer systems providing message-based services, wherein the messagecontains: a loan contract package, wherein the loan contract packagecontains: a loan contract entity characterizing information required togenerate a loan contract; a party package containing informationcharacterizing parties to a loan contract; a product information packagecontaining information characterizing a product upon which a loancontract is based; a payment information package containing informationcharacterizing information associated with payment processing; an itempackage containing information characterizing conditions of a loancontract; and initiating transmission of the message to a secondapplication to generate a loan contract.
 56. A method as in claim 55,wherein the party package contains: a lender party entity characterizinga party that grants a loan; a borrower party entity characterizing aparty that is issued a loan; a payer party entity characterizing a partyresponsible for repayment of a loan; a broker party entitycharacterizing an agent for issuance of a loan; and a bailsman partyentity characterizing a party responsible for guaranteeing a loan; andwherein the product information package contains: a product categoryentity characterizing a product category of a loan; and a product entitycharacterizing a product; wherein the payment information packagecontains: a payment form entity characterizing a form of payment; and abank account entity characterizing a bank account; wherein the loancontract package further contains: a loan contract attachment packagecontaining information characterizing documents relevant for a loan; aloan contract item package, wherein the loan contract item packagecontains: a loan condition information entity characterizing terms andconditions of a loan containing: a loan interest condition entitycharacterizing an interest condition for a loan; a loan amortizementcondition entity characterizing a repayment condition for a loan; and aloan fee condition entity characterizing a fee condition for a loan; anda loan contract item party package containing information characterizingall parties to a loan contract.
 57. A computer-implemented method ofrequesting a generation of a loan contract, the method comprising:receiving an electronic message in a landscape of computer systemsproviding message-based services, wherein the message contains: a loancontract package, wherein the loan contract package contains: a loancontract entity characterizing information required to generate a loancontract; a party package containing information characterizing partiesto a loan contract; a product information package containing informationcharacterizing a product upon which a loan contract is based; a paymentinformation package containing information characterizing informationassociated with payment processing; an item package containinginformation characterizing conditions of a loan contract; and initiatinggeneration of a loan contract.
 58. A computer-implemented method ofgenerating a confirmation of a creation of a loan contract, the methodcomprising: generating an electronic message by a first application, thefirst application executing in a landscape of computer systems providingmessage-based services, wherein the message contains: a loan contractpackage, wherein the loan contract package comprises: a loan contractentity characterizing information regarding a creation of a loancontract; a log package containing information characterizing logmessages associated with a creation of al loan contract; and a paymentinformation package, wherein the payment information package contains: abank account entity characterizing information about a bank account tobe used to repay a loan; and initiating transmission of the message to asecond application to generate a confirmation of a creation of a loancontract.
 59. A computer-implemented method of generating a confirmationof a creation of a loan contract, the method comprising: receiving anelectronic message in a landscape of computer systems providingmessage-based services, wherein the message contains: a loan contractpackage, wherein the loan contract package comprises: a loan contractentity characterizing information regarding a creation of a loancontract; a log package containing information characterizing logmessages associated with a creation of al loan contract; a paymentinformation package, wherein the payment information package contains: abank account entity characterizing information about a bank account tobe used to repay a loan; and initiating a generation of a confirmationof a creation of a loan contract.
 60. A computer-implemented method ofgenerating a notice from a buyer to a vendor relating to productactivities, the method comprising: generating an electronic message by afirst application, the first application executing in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises: a product activity package containing: a product activityentity characterizing activities associated with goods of a buyer at aship to location; and an item package containing: an item entitycharacterizing activities associated with goods of a buyer at a ship tolocation; and a location package containing:  a ship to location entitycharacterizing a location to which goods are to be delivered; and aproduct information package containing information characterizing goodsto be delivered; and initiating transmission of the message to a secondapplication to generate a notice from a buyer to a vendor relating toproduct activities.
 61. A method as in claim 60, wherein the productactivity message further contains: a party package containing: a buyerparty entity characterizing a party that purchases goods; a vendor partyentity characterizing a party that delivers goods; and a productrecipient party entity characterizing a party that receives a deliveryof goods; a business transaction document reference package containinginformation characterizing references to business documents associatedwith a product activity notice; wherein the location package furthercontains: a ship from location entity characterizing a location fromwhich goods are to be shipped for delivery; and wherein the item packagefurther contains an inventory package containing: an inventory entitycharacterizing stock of a good at a buyer; and a consignment inventoryentity characterizing goods in possession of a buyer that are owned by avendor until purchased.
 62. A computer-implemented method of generatinga notice from a buyer to a vendor relating to product activities, themethod comprising: receiving an electronic message in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises a product activity package containing: a product activityentity characterizing activities associated with goods of a buyer at aship to location; and an item package containing: an item entitycharacterizing activities associated with goods of a buyer at a ship tolocation; and a location package containing: a ship to location entitycharacterizing a location to which goods are to be delivered; and aproduct information package containing information characterizing goodsto be delivered; and initiating a generation of a notice from a buyer toa vendor relating to product activities.
 63. A computer-implementedmethod of generating a notice of an event affecting product demand, themethod comprising: generating an electronic message by a firstapplication, the first application executing in a landscape of computersystems providing message-based services, wherein the message comprises:a product demand influencing event package containing: a product demandinfluencing event entity characterizing a product demand influencingevent; a party package containing: a buyer party entity characterizing aparty that purchases goods; and a vendor party entity characterizing aparty that delivers goods; an item package containing: an item entitycharacterizing activities associated with goods of a buyer at a ship tolocation; and a location package containing:  a ship to location entitycharacterizing a location to which goods are to be delivered; and aproduct information package containing information characterizing goodsto be delivered; and initiating transmission of the message to a secondapplication to generate a notice of an event affecting product demand.64. A method as in claim 63, wherein the product demand influencingevent package further contains: a scheduling package containinginformation characterizing time orders utilized to define a schedule forlogistics associated with goods affected by a product demand influencingevent; wherein the location package further contains: a ship fromlocation entity characterizing a location from which goods are to beshipped for delivery; and wherein the item package further contains aproduct information package containing information characterizing goodsaffected by a product demand influencing event.
 65. Acomputer-implemented method of generating a notice of an event affectingproduct demand, the method comprising: receiving an electronic messagein a landscape of computer systems providing message-based services,wherein the message comprises a product demand influencing event packagecontaining: a product demand influencing event package containing: aproduct demand influencing event entity characterizing a product demandinfluencing event; a party package containing: a buyer party entitycharacterizing a party that purchases goods; and a vendor party entitycharacterizing a party that delivers goods; an item package containing:an item entity characterizing activities associated with goods of abuyer at a ship to location; and a location package containing:  a shipto location entity characterizing a location to which goods are to bedelivered; and a product information package containing informationcharacterizing goods to be delivered; and initiating a generation of anotice of an event affecting product demand.
 66. A computer-implementedmethod of generating information associated with a purchase order, themethod comprising: generating an electronic message by a firstapplication, the first application executing in a landscape of computersystems providing message-based services, wherein the message comprises:a purchase order package containing: a purchase order entitycharacterizing a request by a buyer to a seller to provide certainquantities of products or services; a purchase order party packagecontaining information characterizing parties to a purchase order; apurchase order location package containing information characterizinglocations associated with a purchase order; a purchase order deliveryinformation package containing information characterizing a delivery ofgoods associated with a purchase order; a purchase order paymentinformation package containing information characterizing payment termsassociated with a purchase order; a price order price informationpackage containing pricing information associated with a purchase order;a purchase order attachment package containing informationcharacterizing attachments relevant to a purchase order; a purchaseorder description package containing information characterizing textsassociated with a purchase order; a purchase order follow up messagepackage containing information characterizing messages associated with apurchase order and occurring subsequent to an issuance of such purchaseorder; and a purchase order item package containing informationcharacterizing an item associated with a purchase order; initiatingtransmission of the message to a second application to generateinformation associated with a purchase order.
 67. A method as in claim66, wherein the purchase order party package further contains: a buyerparty entity characterizing a party that buys goods or services; aseller party entity characterizing a party that sells goods or services;a product recipient party entity characterizing a party to which goodsare to be delivered or to whom services are to be provided; a vendorparty entity characterizing a party that delivers goods or services; amanufacturer party entity characterizing a party that manufacturesgoods; a bill to party entity characterizing a party to which an invoicefor goods or services is sent; a payer party entity characterizing aparty that pays for goods or services; and a carrier party entitycharacterizing a party that transports goods; wherein the purchase orderlocation package further contains: a ship to location entitycharacterizing a location to which goods are to be delivered or whereservices are to be provided; and a ship from location entitycharacterizing a location from where goods are to be shipped; whereinthe purchase order payment information package further contains: a cashdiscount terms entity characterizing terms of payment in an orderingprocess; a payment form entity characterizing a payment form andassociated payment information; and a payment card entity characterizinga credit card or a customer payment card; wherein the purchase orderdescription package further contains: a description entitycharacterizing text associated with a purchase order; and a confirmationdescription entity characterizing text associated with an orderconfirmation; and wherein the follow up message package furthercontains: a follow up purchase confirmation entity characterizinginformation associated with a confirmation to be received by a buyerfrom a seller in connection with a purchase order; a follow updispatched delivery notification entity characterizing notificationpreferences of a buyer relating to outbound deliveries by a seller; afollow up service acknowledgement request entity characterizingnotification preferences of a buyer relating to services provided by aseller; and a follow up invoice request entity characterizing whether abuyer expects to receive an invoice from a seller.
 68. A method as inclaim 67, wherein the purchase order item package further contains: apurchase order item entity characterizing a product ordered in apurchase order; a hierarchy relationship entity characterizing ahierarchical relationship between items; a product information packagecontaining: a product entity characterizing a commercial description ofa product; and a product category entity characterizing a commercialcategorization of a product; a price information package containing: aprice entity characterizing a purchase order price specified by a buyer;and a confirmed price entity characterizing a purchase order pricespecified by a seller; a purchase order item party package containing:an item buyer party entity characterizing a party that buys goods orservices; an item seller party entity characterizing a party that sellsgoods or services; an item product recipient party entity characterizinga party to which goods are to be delivered or to whom services are to beprovided; an item vendor party entity characterizing a party thatdelivers goods or services; an item manufacturer party entitycharacterizing a party that manufactures goods; an item bill to partyentity characterizing a party to which an invoice for goods or servicesis sent; an item payer party entity characterizing a party that pays forgoods or services; and an item carrier party entity characterizing aparty that transports goods; a purchase order location packagecontaining: a ship to location entity characterizing a location to whichgoods are to be delivered or where services are to be provided; and aship from location entity characterizing a location from where goods areto be shipped; a purchase order item delivery information packagecontaining information characterizing a delivery of goods associatedwith a purchase order; a purchase order item business transactiondocument reference package containing: a quote reference entitycharacterizing a reference to a quotation or an item within a quotation;a purchase contract reference entity characterizing a purchase contractor an item in a purchase contract; a sales contract reference entitycharacterizing a sales contract or an item in a sales contract; anorigin purchase order reference entity characterizing an origin purchaseorder to an item within an origin purchase order; a buyer productcatalogue reference entity characterizing a product catalogue of a buyeror an item within such catalogue; and a seller product cataloguereference entity characterizing a product catalogue of a seller or anitem within such catalogue; a purchase order item attachment packagecontaining information characterizing attachments relevant to a purchaseorder; a purchase order item description package containing: adescription entity characterizing texts associated with a purchase orderitem; and a confirmation description entity characterizing textsregarding a purchase order item confirmation; and a schedule linepackage containing: a schedule line entity characterizing a linecontaining a quantity and date of a performance schedule required by abuyer for a purchase order; and a confirmed schedule line entitycharacterizing a quantity and date of a confirmed by a seller for apurchase order.
 69. A computer-implemented method of generatinginformation associated with a purchase order, the method comprising:receiving an electronic message in a landscape of computer systemsproviding message-based services, wherein the message comprises: apurchase order package containing: a purchase order entitycharacterizing a request by a buyer to a seller to provide certainquantities of products or services; a purchase order party packagecontaining information characterizing parties to a purchase order; apurchase order location package containing information characterizinglocations associated with a purchase order; a purchase order deliveryinformation package containing information characterizing a delivery ofgoods associated with a purchase order; a purchase order paymentinformation package containing information characterizing payment termsassociated with a purchase order; a price order price informationpackage containing pricing information associated with a purchase order;a purchase order attachment package containing informationcharacterizing attachments relevant to a purchase order; a purchaseorder description package containing information characterizing textsassociated with a purchase order; a purchase order follow up messagepackage containing information characterizing messages associated with apurchase order and occurring subsequent to an issuance of such purchaseorder; and a purchase order item package containing informationcharacterizing an item associated with a purchase order; initiating ageneration of information associated with a purchase order.
 70. Acomputer-implemented method of generating status information associatedwith a purchase order, the method comprising: generating an electronicmessage by a first application, the first application executing in alandscape of computer systems providing message-based services, whereinthe message comprises: a purchase order information package containing:a purchase order information entity characterizing a request by a buyerto a seller to provide certain quantities of products or services; apurchase order information party package containing informationcharacterizing parties to a purchase order; a purchase order informationlocation package containing information characterizing locationsassociated with a purchase order; a purchase order information deliveryinformation package containing information characterizing a delivery ofgoods associated with a purchase order; a purchase order informationpayment information package containing information characterizingpayment information associated with a purchase order; a price orderprice information package containing pricing information associated witha purchase order; a purchase order information attachment packagecontaining information characterizing attachments relevant to a purchaseorder; a purchase order information description package containinginformation characterizing texts associated with a purchase order; apurchase order information follow up message package containinginformation characterizing messages to be sent subsequent to issuance ofa purchase order; and a purchase order information item packagecontaining information characterizing an item; initiating transmissionof the message to a second application to generate status informationassociated with a purchase order.
 71. A method as in claim 70, whereinthe purchase order information party package further contains: a buyerparty entity characterizing a party that buys goods or services; aseller party entity characterizing a party that sells goods or services;a product recipient party entity characterizing a party to which goodsare to be delivered or to whom services are to be provided; a vendorparty entity characterizing a party that delivers goods or services; amanufacturer party entity characterizing a party that manufacturesgoods; a bill to party entity characterizing a party to which an invoicefor goods or services is sent; a payer party entity characterizing aparty that pays for goods or services; and a carrier party entitycharacterizing a party that transports goods; wherein the purchase orderinformation location package further contains: a ship to location entitycharacterizing a location to which goods are to be delivered or whereservices are to be provided; and a ship from location entitycharacterizing a location from where goods are to be shipped; whereinthe purchase order information payment information package furthercontains: a cash discount terms entity characterizing terms of paymentin an ordering process; a payment form entity characterizing a paymentform and associated payment information; and a payment card entitycharacterizing a credit card or a customer payment card; wherein thepurchase order information description package further contains: adescription entity characterizing text associated with a purchase order;and a confirmation description entity characterizing text associatedwith an order confirmation; and wherein the follow up message packagefurther contains: a follow up purchase confirmation entitycharacterizing information associated with a confirmation to be receivedby a buyer from a seller in connection with a purchase order; a followup dispatched delivery notification entity characterizing notificationpreferences of a buyer relating to outbound deliveries by a seller; afollow up service acknowledgement request entity characterizingnotification preferences of a buyer relating to services provided by aseller; and a follow up invoice request entity characterizing whether abuyer expects to receive an invoice from a seller.
 72. A method as inclaim 71, wherein the purchase order information item package furthercontains: a purchase order information item entity characterizing aproduct ordered in a purchase order; a hierarchy relationship entitycharacterizing a hierarchical relationship between items; a productinformation package containing: a product entity characterizing acommercial description of a product; and a product categorycharacterizing a commercial categorization of a product; a priceinformation package containing: a price entity characterizing a purchaseorder price specified by a buyer; a confirmed price entitycharacterizing a purchase order price specified by a seller; and aprocurement cost upper limit entity characterizing a cost upper limitfor one or more types of procurement costs; a purchase order informationitem party package containing: an item buyer party entity characterizinga party that buys goods or services; an item seller party entitycharacterizing a party that sells goods or services; an item productrecipient party entity characterizing a party to which goods are to bedelivered or to whom services are to be provided; an item vendor partyentity characterizing a party that delivers goods or services; an itemmanufacturer party entity characterizing a party that manufacturesgoods; an item bill to party entity characterizing a party to which aninvoice for goods or services is sent; an item payer party entitycharacterizing a party that pays for goods or services; and an itemcarrier party entity characterizing a party that transports goods; apurchase order information location package containing: a ship tolocation entity characterizing a location to which goods are to bedelivered or where services are to be provided; and a ship from locationentity characterizing a location from where goods are to be shipped; apurchase order information item delivery information package containinginformation characterizing a delivery of goods associated with apurchase order; a purchase order information item business transactiondocument reference package containing: a quote reference entitycharacterizing a reference to a quotation or an item within a quotation;a purchase contract reference entity characterizing a purchase contractor an item in a purchase contract; a sales contract reference entitycharacterizing a sales contract or an item in a sales contract; anorigin purchase order reference entity characterizing an origin purchaseorder to an item within an origin purchase order; a buyer productcatalogue reference entity characterizing a product catalogue of a buyeror an item within such catalogue; and a seller product cataloguereference entity characterizing a product catalogue of a seller or anitem within such catalogue; a purchase order information item attachmentpackage containing information characterizing attachments relevant to apurchase order; and a purchase order information item descriptionpackage containing: a description entity characterizing texts associatedwith a purchase order item; and a confirmation description entitycharacterizing texts regarding a purchase order item confirmation.
 73. Acomputer-implemented method of generating status information associatedwith a purchase order, the method comprising: receiving an electronicmessage in a landscape of computer systems providing message-basedservices, wherein the message comprises: a purchase order informationpackage containing: a purchase order information entity characterizing arequest by a buyer to a seller to provide certain quantities of productsor services; a purchase order information party package containinginformation characterizing parties to a purchase order; a purchase orderinformation location package containing information characterizinglocations associated with a purchase order; a purchase order informationdelivery information package containing information characterizing adelivery of goods associated with a purchase order; a purchase orderinformation payment information package containing informationcharacterizing payment information associated with a purchase order; aprice order price information package containing pricing informationassociated with a purchase order; a purchase order informationattachment package containing information characterizing attachmentsrelevant to a purchase order; a purchase order information descriptionpackage containing information characterizing texts associated with apurchase order; a purchase order information follow up message packagecontaining information characterizing messages to be sent subsequent toissuance of a purchase order; and a purchase order information itempackage containing information characterizing an item; and initiating ageneration of status information associated with a purchase order.
 74. Acomputer-implemented method of generating a request querying a buyer toprocure products or services, the method comprising: generating anelectronic message by a first application, the first applicationexecuting in a landscape of computer systems providing message-basedservices, wherein the message comprises: a purchase request packagecontaining: a purchase request entity characterizing requisitionrequirements; and a purchase request item package containing: a scheduleline package containing information characterizing quantity and dateinformation associated with a requisition; initiating transmission ofthe message to a second application to generate a request querying abuyer to procure products or services.
 75. A method as in claim 74,wherein the purchase request party package further contains: a buyerparty entity characterizing a party that buys goods or services; aseller party entity characterizing a party that sells goods or services;a proposed seller party entity characterizing a preferred party forselling goods or services; a requestor party entity characterizing aparty that requests procurement of goods or services; a productrecipient party entity characterizing a party to which goods are to bedelivered or to whom services are to be provided; a manufacturer partyentity characterizing a party that manufactures goods; wherein themessage further contains: a purchase request location package groupinginformation associated with locations relevant for a requisition,wherein the purchase request location package comprises: a ship tolocation entity characterizing a location to which goods are to bedelivered or where services are to be provided; a ship from locationentity characterizing a location from where goods are to be shipped;wherein the purchase request item package further contains: a purchaserequest entity characterizing a requested product; a hierarchyrelationship entity characterizing relationship between items in an itemhierarchy; a product information package containing: a product entitycharacterizing a product; and a product category entity characterizing aproduct category; a price information package containing: a price entitycharacterizing a specified purchase order price; and a procurement costupper limit entity characterizing upper procurement limits; an itemparty package containing information characterizing parties to arequisition; a location package containing information characterizinglocation information associated with a requisition; an object referencepackage containing information characterizing business documentsrelevant for a requisition, wherein the object reference packagecontains: a purchase contract reference entity characterizing a purchasecontract or an item in a purchase contract; a purchase order referenceentity characterizing a purchase order or an item in a purchase order; aproject reference entity characterizing a project or an element within aproject associated with a requisition; and a project element assignmententity characterizing an assignment between two elements of a projectassociated with a requisition; and an accounting object set assignmentpackage containing information characterizing accounting informationassociated with a requisition; an attachment package containinginformation characterizing attachments relevant to a requisition; and adescription package containing information characterizing texts relatingto a requisition; wherein the schedule line package further contains: aschedule line entity characterizing quantity and dates of a performanceperiod associated with a requisition; a delivery period entitycharacterizing a delivery period for a requisition; and a quantityentity characterizing a quantity specified by a requisition.
 76. Acomputer-implemented method of generating a request querying a buyer toprocure products or services, the method comprising: receiving anelectronic message in a landscape of computer systems providingmessage-based services, wherein the message comprises: a purchaserequest package containing: a purchase request entity characterizingrequisition requirements; and a purchase request item packagecontaining: a schedule line package containing informationcharacterizing quantity and date information associated with arequisition; and initiating a generation of a request querying a buyerto procure products or services.
 77. A computer-implemented method ofgenerating a confirmation of a fulfillment of a requisition, the methodcomprising: generating an electronic message by a first application, thefirst application executing in a landscape of computer systems providingmessage-based services, wherein the message comprises: a purchaserequest package containing: a purchase request entity characterizing aconfirmation of requirements associated with a procurement of productsor services; and an item package containing: an item entitycharacterizing a product; and a purchase order package containinginformation characterizing a level of fulfillment of a requirement by apurchase order; initiating transmission of the message to a secondapplication to generate a confirmation of a fulfillment of arequisition.
 78. A computer-implemented method of generating aconfirmation of a fulfillment of a requisition, the method comprising:receiving an electronic message in a landscape of computer systemsproviding message-based services, wherein the message comprises: apurchase request package containing: a purchase request entitycharacterizes a confirmation of requirements associated with aprocurement of products or services; and an item package containing: anitem entity characterizing a product; and a purchase order packagecontaining information characterizing a level of fulfillment of arequirement by a purchase order; initiating a generation of aconfirmation of a fulfillment of a requisition.
 79. Acomputer-implemented method of generating purchasing contractinformation, the method comprising: <ContactPerson> <InternalIDschemeID=“ContactPersonID” schemeAgencyID=“BPL_300”>737</InternalID><Address>... </Address> </ContactPerson>

generating an electronic message by a first application, the firstapplication executing in a landscape of computer systems providingmessage-based services, wherein the message comprises: a purchasingcontract package containing: a purchasing contract entity characterizingan agreement to order products or provide services within a certainperiod of time; a purchasing contract party package containinginformation characterizing parties to a purchasing contract parties to apurchasing contract; a purchasing contract location package containinginformation characterizing locations associated with a purchasingcontract; a purchasing contract delivery information package containinginformation characterizing a delivery requested in a purchasingcontract; a purchasing contract payment information package containinginformation characterizing payment terms for a purchasing contract; apurchasing contract price information package containing informationcharacterizing pricing of goods or services identified in a purchasingcontract; a purchasing contract attachment package containinginformation characterizing documents referring to a purchasing contract;a purchasing contract description package containing informationcharacterizing texts associated with a purchasing contract; and apurchasing contract item package containing information characterizing aproduct or service in a purchasing contract; and initiating transmissionof the message to a second application to generate purchasing contractinformation.
 80. A method as in claim 79, wherein the purchasingcontract party package further contains: a buyer party entitycharacterizing a party that buys goods or services; a seller partyentity characterizing a party that sells goods or services; a productrecipient party entity characterizing a party to which goods are to bedelivered or to whom services are to be provided; and a contract releaseauthorized party entity characterizing a party that is authorized toeffect releases from a purchasing contract; wherein the purchasingcontract attachment package further contains: an attachment web addressentity characterizing a location of documents referring to a purchasingcontract; an internal attachment web address entity characterizing alocation of internal documents referring to a purchasing contract; and alegal document attachment entity characterizing legal text of apurchasing contract; and wherein the purchasing contract descriptionpackage further contains: a description entity characterizing textassociated with a purchasing contract; and an internal descriptionentity characterizing internal text associated with a purchasingcontract.
 81. A method as in claim 79, wherein the purchasing contractitem package further contains: a purchasing contract item entitycharacterizing a product or service in a purchasing contract; apurchasing contract item product information package containing: aproduct entity characterizing a product or service; and a productcategory entity characterizing a category for a product or service; apurchasing contract item price information package containinginformation characterizing pricing of goods or services identified in apurchasing contract; a purchasing contract item location packagecontaining information characterizing locations associated with apurchasing contract; a purchasing contract item party package containinginformation characterizing parties to a purchasing contract parties to apurchasing contract; a purchasing contract item delivery informationpackage containing information characterizing a delivery requested in apurchasing contract; a purchasing contract business document objectreference package containing: a quote reference entity characterizing abid of a purchaser or a bid to an item within a bid of a purchaser; anoperational purchasing contract reference entity characterizing anoperational purchasing contract or an item in an operational purchasingcontract; and a buyer product catalogue reference entity characterizinga product catalogue of a purchaser or to an item within such acatalogue; a purchasing contract item attachment package containinginformation characterizing documents referring to a purchasing contract;and a purchasing contract item description package containinginformation characterizing texts associated with a purchasing contract.82. A computer-implemented method of generating purchasing contractinformation, the method comprising: receiving an electronic message in alandscape of computer systems providing message-based services, whereinthe message comprises: a purchasing contract package containing: apurchasing contract entity characterizing an agreement to order productsor provide services within a certain period of time; a purchasingcontract party package containing information characterizing parties toa purchasing contract parties to a purchasing contract; a purchasingcontract location package containing information characterizinglocations associated with a purchasing contract; a purchasing contractdelivery information package containing information characterizing adelivery requested in a purchasing contract; a purchasing contractpayment information package containing information characterizingpayment terms for a purchasing contract; a purchasing contract priceinformation package containing information characterizing pricing ofgoods or services identified in a purchasing contract; a purchasingcontract attachment package containing information characterizingdocuments referring to a purchasing contract; a purchasing contractdescription package containing information characterizing textsassociated with a purchasing contract; and a purchasing contract itempackage containing information characterizing a product or service in apurchasing contract; and initiating a generation of purchasing contractinformation.
 83. A computer-implemented method of generating anotification of a purchasing contract release, the method comprising:generating an electronic message by a first application, the firstapplication executing in a landscape of computer systems providingmessage-based services, wherein the message comprises: a purchasingcontract release package containing: a purchasing contract releaseentity characterizing a notification regarding a performed release withreference to a purchasing contract; a purchasing contract release partypackage containing information characterizing a release of a purchasingcontract; a purchasing contract release location package containinginformation characterizing locations associated with a release of apurchasing contract; and a purchasing contract release item packagecontaining: purchasing contract release item entity characterizing anitem in a purchasing contract release; a purchasing contract releaseitem location package containing information characterizing locationsassociated with a contract release item; and a purchasing contractrelease item business document object package containing informationcharacterizing references to business documents relevant to an item in apurchasing contract release; and initiating transmission of the messageto a second application to generate a notification of a purchasingcontract release.
 84. A computer-implemented method of generating anotification of a purchasing contract release, the method comprising:receiving an electronic message in a landscape of computer systemsproviding message-based services, wherein the message comprises: apurchasing contract release package containing: a purchasing contractrelease entity characterizing a notification regarding a performedrelease with reference to a purchasing contract; a purchasing contractrelease party package containing information characterizing a release ofa purchasing contract; a purchasing contract release location packagecontaining information characterizing locations associated with arelease of a purchasing contract; and a purchasing contract release itempackage containing: purchasing contract release item entitycharacterizing an item in a purchasing contract release; a purchasingcontract release item location package containing informationcharacterizing locations associated with a contract release item; and apurchasing contract release item business document object packagecontaining information characterizing references to business documentsrelevant to an item in a purchasing contract release; and initiating ageneration of a notification of a purchasing contract release.
 85. Acomputer-implemented method of generating replenishment orderinformation, the method comprising: generating an electronic message bya first application, the first application executing in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises: a replenishment order package containing: a replenishmentorder entity characterizing a replenishment order executed by a vendorfor a customer; and a replenishment order item package containing: areplenishment order item entity characterizing an item in areplenishment order; a replenishment order item location packagecontaining: a ship from location entity characterizing a location fromwhich products listed in a replenishment order are to be delivered; anda ship to location entity characterizing a location from which productslisted in a replenishment order are to be delivered; and a replenishmentorder item product information package containing informationcharacterizing a product associated with a replenishment order; andinitiating transmission of the message to a second application togenerate replenishment order information.
 86. A method as in claim 85,wherein the replenishment order package further contains: areplenishment order party package containing: a buyer party entitycharacterizing a party that purchases goods associated with areplenishment order; a seller party entity characterizing a party thatsells goods associated with a replenishment order; and a vendor partyentity characterizing a party to provide a replenishment delivery; areplenishment order delivery information package containing informationcharacterizing a requested delivery for a replenishment order; areplenishment order payment information package containing informationcharacterizing payment information for a replenishment order; and areplenishment order handling unit package containing informationcharacterizing packing requirements for product associated with areplenishment order.
 87. A method as in claim 85, wherein thereplenishment order item package further contains: a businesstransaction documents reference package containing: a purchase contractreference entity characterizing a purchase contract or an item in apurchase contract; a scheduling agreement reference entitycharacterizing a scheduling agreement or an item in a schedulingagreement; a purchase order reference entity characterizing a purchaseorder of a buyer or a purchase order item created by a vendor; an originpurchase order reference entity characterizing an original purchaseorder or to an item within an original purchase order; a sales orderreference entity characterizing a sales order or an item in a salesorder; and an origin sales order reference entity characterizing anoriginal sales order or an item within an original sales order; areplenishment order item party package containing: a replenishment orderitem buyer party entity characterizing a party that purchases goodsassociated with a replenishment order; a replenishment order itemproduct recipient party entity characterizing a party to receive goodsassociated with a replenishment order; and a replenishment order itembill to party entity characterizing a party to receive an invoiceassociated with a replenishment order; a replenishment order itemproduct information package containing information characterizing aproduct listed in a replenishment order; a replenishment order itembatch package containing information characterizing a batch to bedelivered; a replenishment order item promotion package containinginformation characterizing marketing promotions associated with areplenishment order; a replenishment order item price informationpackage containing pricing information of an item in a replenishmentorder; and a replenishment order item schedule line package containing:a schedule line entity characterizing quantity and scheduling associatedwith a replenishment order; and a confirmed schedule line entitycharacterizing a confirmation of quantity and scheduling associated witha replenishment order; and wherein the replenishment order locationpackage further contains: a trans-shipment location entitycharacterizing a location at product in a replenishment order istransferred from a first transportation mechanism to a secondtransportation mechanism.
 88. A computer-implemented method ofgenerating replenishment order information, the method comprising:receiving an electronic message in a landscape of computer systemsproviding message-based services, wherein the message comprises: areplenishment order package containing: a replenishment order entitycharacterizing a replenishment order executed by a vendor for acustomer; and a replenishment order item package containing: areplenishment order item entity characterizing an item in areplenishment order; a replenishment order item location packagecontaining: a ship from location entity characterizing a location fromwhich products listed in a replenishment order are to be delivered; anda ship to location entity characterizing a location from which productslisted in a replenishment order are to be delivered; and a replenishmentorder item product information package containing informationcharacterizing a product associated with a replenishment order; andinitiating a generation of replenishment order information.
 89. Acomputer-implemented method of generating replenishment order proposalinformation, the method comprising: generating an electronic message bya first application, the first application 10 executing in a landscapeof computer systems providing message-based services, wherein themessage comprises: a replenishment order proposal package containing: areplenishment order proposal entity characterizing a proposal for anorder to replenish product supply; and a replenishment order proposalitem entity characterizing an item in a replenishment order proposal; areplenishment order proposal item location package containing: a shipfrom location entity characterizing a location from which productslisted in a replenishment order proposal are to be delivered; and a shipto location entity characterizing a location from which products listedin a replenishment order proposal are to be delivered; and areplenishment order proposal item product information package containinginformation characterizing a product associated with a replenishmentorder proposal; and initiating transmission of the message to a secondapplication to generate replenishment order proposal information.
 90. Amethod as in claim 89, wherein the replenishment order proposal packagefurther contains: a replenishment order proposal party packagecontaining: a buyer party entity characterizing a party that buys goodsassociated with a replenishment order; a vendor party entitycharacterizing a party that delivers goods associated with areplenishment order; and a product recipient party entity characterizinga party to which goods associated with a replenishment order aredelivered; and a replenishment order proposal business document objectreference package containing information characterizing businessdocuments relating to a replenishment order.
 91. A method as in claim90, wherein the replenishment order proposal item package furthercontains: a replenishment order proposal item price information packagecontaining information characterizing pricing of a proposedreplenishment order: a replenishment order proposal item party packagecontaining information characterizing parties associated with a proposedreplenishment order: a replenishment order proposal item locationpackage containing: a ship from location entity characterizing alocation from which products listed in a replenishment order proposalare to be delivered; and a ship to location entity characterizing alocation from which products listed in a replenishment order proposalare to be delivered; a replenishment order proposal item businessdocument object reference package containing information characterizingbusiness documents relating to a replenishment order; a schedule linepackage containing: a schedule line entity characterizing quantity andscheduling associated with a replenishment order proposal; and aconfirmed schedule line entity characterizing a confirmation of quantityand scheduling associated with a replenishment order proposal; andwherein the product information package further contains: a productcategory entity characterizing a category of a product associated with areplenishment order proposal; and a vendor product category entitycharacterizing a vendor category of a product associated with areplenishment order proposal.
 92. A computer-implemented method ofgenerating replenishment order proposal information, the methodcomprising: receiving an electronic message in a landscape of computersystems providing message-based services, wherein the message comprises:a replenishment order proposal package containing: a replenishment orderproposal entity characterizing a proposal for an order to replenishproduct supply; and a replenishment order proposal item packagecontaining: a replenishment order proposal item entity characterizing anitem in a replenishment order proposal; and a replenishment orderproposal item location package containing: a ship from location entitycharacterizing a location from which products listed in a replenishmentorder proposal are to be delivered; and a ship to location entitycharacterizing a location from which products listed in a replenishmentorder proposal are to be delivered; and a replenishment order proposalitem product information package containing information characterizing aproduct associated with a replenishment order proposal; and initiating ageneration of replenishment order proposal information.
 93. Acomputer-implemented method of generating a notification associated witha return delivery, the method comprising: generating an electronicmessage by a first application, the first application executing in alandscape of computer systems providing message-based services, whereinthe message comprises: a return delivery instruction package containing:a return delivery instruction entity characterizing logisticalinstructions to a vendor for a future return delivery; and a returndelivery instruction item package containing a product informationpackage containing information characterizing characterizing a returnquantities and scheduling for a return delivery; initiating transmissionof the message to a second application to generate a notificationassociated with a return delivery.
 94. A method as in claim 93, whereinthe return delivery instruction package further comprises: a partypackage containing: a buyer party entity characterizing a party that haspurchased goods being returned or has reordered a repurchase of goods; avendor entity characterizing a party that sends backs goods to bereturned; and a product recipient entity characterizing a company towhich goods are returned; and a location package containing: a ship toentity characterizing a location from which goods for return are sentback; and a ship to location characterizing a location to which goodsfor return are sent back; wherein the return delivery instructionpackage further contains: a return delivery item package containing: areturn delivery instruction item entity characterizing a quantity ofproduct to be returned and an associated delivery period; a deliveryitem business transaction document reference package characterizingbusiness document references relevant to a product to be returned; aparty package containing information characterizing business partnersrelevant to a product to be returned; a batch package containinginformation characterizing a batch of product to be returned; and adelivery handling unit package containing information characterizinghandling requirements for a product to be returned.
 95. Acomputer-implemented method of generating a notification associated witha return delivery, the method comprising: receiving an electronicmessage in a landscape of computer systems providing message-basedservices, wherein the message comprises: a return delivery instructionpackage containing: a return delivery instruction entity characterizinglogistical instructions to a vendor for a future return delivery; and areturn delivery instruction item package containing a productinformation package containing information characterizing a returnquantities and scheduling for a return delivery; and initiating ageneration of a notification associated with a return delivery.
 96. Acomputer-implemented method of exchanging information associated with arequest for quotation, the method comprising: generating an electronicmessage by a first application, the first application executing in alandscape of computer systems providing message-based services, whereinthe message comprises: a package containing: a party package containinginformation characterizing parties associated with a request forquotation; a location package containing information characterizinglocations associated with a request for quotation; a first deliveryinformation package containing information characterizing a requireddelivery associated with a request for quotation; a payment informationpackage containing information characterizing payment informationassociated with a request for quotation; a product information packagecontaining information characterizing a product category associated witha request for quotation; a business transaction document referencepackage containing information characterizing business documentreferences associated with a request for quotation; a follow up businesstransaction document reference package containing informationcharacterizing business transaction documents expected by a buying partyassociated with a request for quotation; an attachment packagecontaining information characterizing documents referring to a requestfor quotation; a description package containing informationcharacterizing text visible to parties to a request for quotation; anitem package containing: a product information package containinginformation characterizing a product tendered by a request forquotation; a party package containing information characterizing partiesassociated with a request for quotation; a second delivery informationpackage containing information characterizing delivery of a productassociated with a request for quotation; a business transaction documentreference package containing information characterizing a requireddelivery associated with a request for quotation; an attachment packagecontaining information characterizing documents referring to a requestfor quotation; a description package containing informationcharacterizing text visible to parties to a request for quotation; and aschedule line package containing information characterizing quantity anddate information associated with a request for quotation; and initiatingtransmission of the message to a second application to exchangeinformation associated with a request for quotation.
 97. A method as inclaim 96, wherein the information is selected from a group comprising: arequest from a buyer to a bidder to start a request for quotationprocess, a request from a buyer to a bidder to modify a request forquotation during a request for quotation process, a cancellation of arequest for quotation, a notification from a bidder to a buyercontaining a response by the bidder to an invitation to respond to arequest for quotation, a notification of an acceptance of a bid inresponse to a request for quotation, a notification of a declination ofa bid in response to a request for quotation, a confirmation from abidder to a buyer indicating that the bidder intends to submit a bid inresponse to a request for quotation, a confirmation from a bidder to abuyer indicating an acceptance or rejection of a quotation accepted bythe buyer, a request to generate a legal text document in response to aninvitation to bid for quotation, and a notification of a generation of alegal text document in response to an invitation to bid on a request forquotation.
 98. A computer-implemented method of exchanging informationassociated with a request for quotation, the method comprising:receiving an electronic message in a landscape of computer systemsproviding message-based services, wherein the message comprises: apackage containing: a party package containing informationcharacterizing parties associated with a request for quotation; alocation package containing information characterizing locationsassociated with a request for quotation; a first delivery informationpackage containing information characterizing a required deliveryassociated with a request for quotation; a payment information packagecontaining information characterizing payment information associatedwith a request for quotation; a product information package containinginformation characterizing a product category associated with a requestfor quotation; a business transaction document reference packagecontaining information characterizing business document referencesassociated with a request for quotation; a follow up businesstransaction document reference package containing informationcharacterizing business transaction documents expected by a buying partyassociated with a request for quotation; an attachment packagecontaining information characterizing documents referring to a requestfor quotation; a description package containing informationcharacterizing text visible to parties to a request for quotation; anitem package containing: a product information package containinginformation characterizing a product tendered by a request forquotation; a party package containing information characterizing partiesassociated with a request for quotation; a second delivery informationpackage containing information characterizing delivery of a product; abusiness transaction document reference package containing informationcharacterizing a required delivery associated with a request forquotation; an attachment package containing information characterizingdocuments referring to a request for quotation; a description packagecontaining information characterizing text visible to parties to arequest for quotation; and a schedule line package containinginformation characterizing quantity and date information associated witha request for quotation; and initiating an exchange of informationassociated with a request for quotation.
 99. A computer-implementedmethod of exchanging information associated with services that have beenentered, the method comprising: generating an electronic message by afirst application, the first application executing in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises: a service acknowledgement package containing: a serviceacknowledgement entity characterizing information about a confirmationby a purchase of an entered service; and a party package containing: abuyer party entity characterizing a party that purchases goods orservices; and initiating transmission of the message to a secondapplication to exchange information associated with services that havebeen entered.
 100. A method as in claim 99, wherein the party packagefurther contains: a seller party entity characterizing a party sellinggoods or services; a product recipient party entity characterizing aparty to which goods are delivered or for whom services are provided; avendor party entity characterizing a party that delivers goods orprovides services; a manufacturer party entity characterizing a partythat manufactures goods; wherein the service acknowledgement packagefurther contains: a location package containing informationcharacterizing a location at which products have been delivered or aservice provided; an attachment package containing informationcharacterizing a document referring to a service acknowledgement; adescription package containing information characterizing text regardinga service acknowledgement; and an item package containing: an itementity characterizing an entered service or service product; a hierarchyrelationship entity characterizing a relationship between items in ahierarchy; a product information package containing: a product entitycharacterizing a product; and a product category entity characterizing acategory for a product; a price information package containinginformation characterizing price information for a serviceacknowledgement item; a party package containing informationcharacterizing parties associated with a service acknowledgement; alocation package containing information characterizing a location atwhich a products have been delivered or services provided; a businessdocument object reference package containing: a purchase order referenceentity characterizing a purchase order or an item within a purchaseorder; a service acknowledgement reference entity characterizing apreviously sent service acknowledgement; a purchase contract referenceentity characterizing a reference to a purchase contract or an itemwithin a purchase contract; a sales contract reference entitycharacterizing a reference to a sales contract or an item within a salescontract; a buyer product catalogue reference entity characterizing areference to a product catalogue of a buyer or an item within a productcatalogue of a buyer; a seller product catalogue reference entitycharacterizing a reference to a product catalogue of a seller or an itemwithin a product catalogue of a seller; an attachment package containinginformation characterizing a document referring to a serviceacknowledgement; and a description package containing informationcharacterizing text regarding a service acknowledgement.
 101. A methodas in claim 100, wherein the business document object reference packagefurther contains: a project reference entity characterizing a referenceto a project or an element within a project; and a project elementassignment entity characterizing an assignment of two elements within aproject that is referenced by an item of a service acknowledgment; andwherein the item package further contains: an accounting packagecontaining information characterizing account assignment information.102. A computer-implemented method of exchanging information associatedwith services that have been entered, the method comprising: receivingan electronic message in a landscape of computer systems providingmessage-based services, wherein the message comprises: a serviceacknowledgement package containing: a service acknowledgement entitycharacterizing information about a confirmation by a purchase of anentered service; and a party package containing: a buyer party entitycharacterizing a party that purchases goods or services; and initiatingan exchange of information associated with services that have beenentered.
 103. A computer-implemented method of generating a supply chainexception notification, the method comprising: generating an electronicmessage by a first application, the first application executing in alandscape of computer systems providing message-based services, whereinthe message comprises: a supply chain exception package containing: asupply chain exception report entity characterizing an exception thatoccurred in a supply chain; a business transaction document referencepackage containing: a purchaser order entity characterizing a referenceto a purchase order or an item within a purchase order for which anexception in a supply chain has occurred; a location package containing:a ship from location characterizing a location from which orderedproducts are delivered; a product information package characterizing aproduct associated with a supply chain exception; and initiatingtransmission of the message to a second application to generate a supplychain exception notification.
 104. A method as in claim 103, wherein themessage further contains: a party package containing: a buyer partyentity characterizing a buyer of goods or services; a vendor partyentity characterizing a vendor of goods or services; and a productrecipient entity characterizing a recipient of goods or services;wherein the business transaction document reference contains: ascheduling agreement reference entity characterizing a reference to anitem in a scheduling agreement; a sales order reference entitycharacterizing a reference to a sales order or to an item in a salesorder; and an inbound delivery reference entity characterizing aninbound delivery or an item of an inbound delivery; wherein the supplychain exception package further contains: a batch package containing: abatch entity characterizing a batch of products; a property valuationpackage characterizing properties of a characteristic of a supply chainexception; a log package containing: a validation log entitycharacterizing a logistics planning or logistics execution check log;and an item entity; and wherein the location package further contains: aship to location entity characterizing a location where ordered productsare delivered.
 105. A computer-implemented method of generating a supplychain exception notification, the method comprising: receiving anelectronic message in a landscape of computer systems providingmessage-based services, wherein the message comprises: a supply chainexception package containing: a supply chain exception report entitycharacterizing an exception that occurred in a supply chain; a businesstransaction document reference package containing: a purchaser orderentity characterizing a reference to a purchase order or an item withina purchase order for which an exception in a supply chain has occurred;a location package containing: a ship from location characterizing alocation from which are ordered products are delivered; a productinformation package characterizing a product associated with a supplychain exception; and initiating generation of a supply chain exceptionnotification.
 106. A computer-implemented method of generating a taxdeclaration, the method comprising: generating an electronic message bya first application, the first application executing in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises: a declaration package containing: a declaration entitycharacterizing a tax return based on a purchase; a log packagecontaining: a validation log entity characterizing log messages from atax authority associated with a receipt and validation of a tax returnbased on a purchase; a party package containing: a tax payer partyentity characterizing a party liable for tax on a purchase; and a taxauthority party entity characterizing a tax authority that receives atax declaration; and initiating transmission of the message to a secondapplication to generate a tax declaration.
 107. A method as in claim106, wherein the log package further contains: an item entitycharacterizing a log of a receipt and validation of a tax refund basedon a purchase; wherein the party package further contains: a taxoperator entity characterizing a party that creates and sends a taxreturn for tax on purchases; and wherein the declaration package furthercontains: an item package containing information characterizing reportedtaxes on purchases.
 108. A computer-implemented method of generating ofgenerating a tax declaration, the method comprising: receiving anelectronic message in a landscape of computer systems providingmessage-based services, wherein the message comprises: a declarationpackage containing: a declaration entity characterizing a tax returnbased on a purchase; a log package containing: a validation log entitycharacterizing log messages from a tax authority associated with areceipt and validation of a tax return based on a purchase; a partypackage containing: a tax payer party entity characterizing a partyliable for tax on a purchase; and a tax authority party entitycharacterizing a tax authority that receives a tax declaration; andinitiating a generation of a tax declaration.
 109. Acomputer-implemented method of generating information associated with avendor initiated purchase order, the method comprising: generating anelectronic message by a first application, the first applicationexecuting in a landscape of computer systems providing message-basedservices, wherein the message comprises: a vendor generated orderpackage containing: a vendor generated order entity characterizing apurchaser order that is initiated by a vendor for a customer; a partypackage containing: a buyer party entity characterizing a party toreceive a goods replenishment delivery; and a vendor party entitycharacterizing a party to provide a goods replenishment delivery; alocation package containing: a ship from location entity characterizinga location from which goods associated with a purchase order is to bedelivered; and a ship to location entity characterizing a location atwhich goods associated with a purchase order is to be delivered; and avendor generated order item package containing: a vendor generated orderitem entity characterizing quantities of goods and associated deliveryand location conditions for goods in a purchase order; and a productinformation package containing information characterizing goodsassociated with a purchase order; and initiating transmission of themessage to a second application to generate information associated witha vendor initiated purchase order.
 110. A method as in claim 109,wherein the vendor generated order item package further contains: abusiness transaction document reference package containing: a purchasingcontract reference entity characterizing a purchase contract or an itemin a purchase contract; and a sales order reference entitycharacterizing a sales order or an item in a sales order; a promotionpackage containing information characterizing marketing promotionsrelevant to goods associated with a purchase order; and a schedule linepackage containing: a schedule line entity characterizing quantity andscheduling dates for replen ishment deliveries of goods associated witha purchase order; and a confirmed schedule line entity characterizingconfirmed quantity and scheduling dates for replenishment deliveries ofgoods associated with a purchase order; wherein the location packagefurther contains: a trans-shipment location entity characterizing alocation at which delivery of products using a first transport mechanismchanges to second transport mechanism; and wherein the vendor generatedorder package further contains: a handling unit containing informationcharacterizing packing requirements for goods associated with areplenishment order.
 111. A computer-implemented method of generatinginformation associated with a vendor initiated purchase order, themethod comprising: receiving an electronic message in a landscape ofcomputer systems providing message-based services, wherein the messagecomprises: a vendor generated order package containing: a vendorgenerated order entity characterizing a purchaser order that isinitiated by a vendor for a customer; a party package containing: abuyer party entity characterizing a party to receive a goodsreplenishment delivery; and a vendor party entity characterizing a partyto provide a goods replenishment delivery; a location packagecontaining: a ship from location entity characterizing a location fromwhich goods associated with a purchase order is to be delivered; and aship to location entity characterizing a location at which goodsassociated with a purchase order is to be delivered; and a vendorgenerated order item package containing: a vendor generated order itementity characterizing quantities of goods and associated delivery andlocation conditions for goods in a purchase order; and a productinformation package containing information characterizing goodsassociated with a purchase order; and initiating generation ofinformation associated with a vendor initiated purchase order.